Gregory's Serverlol, this is the active high CHRESET! i was wondering why that line seemed to be missing.
|
150 comments
 @fozztexx it's because DBA-ESDI is also inherently 16-bit. weird, but i must say that 256-word sectors is actually kinda satisfying. got the Teensy interface up and running. i'm using direct IO port access on the Teensy 4.1. take a look at core_pins.h in the Teensy header files. basically you can read from GPIOx_PSR and write to GPIOx_DR. i also had to add a short delay to create some setup time for the FPGA--the Teensy 4.1 is a hair too fast lol bidirectional registers now work! i can write a command from the PC to the Teensy, and i can write a response from the Teensy and read it from the PC. there are also status flags showing when new data is available. it may not seem like much, but this is huge progress. excellent progress today. I've been able to implement the "Get Diagnostic Status" command. it transfers the command block and handles the returning status block as well as the flags and interrupts. best of all, it works on real hardware using my diagnostic program!  Great progress! But help out simpleton me, I've lost track of what you are doing. Is this still part of reverse engineering things to get a SnarkBarker to work on the expansion port?? Or an entirely different project? @darryl_ramm it is a solid state replacement HDD that works with the weird IBM DBA-ESDI protocol (similar in concept to IDE) @tubetime Cool, I would love to get a 701 butterfly. Had one for years at work. OK why does pin 1 start halfway down the edge of this chip??? my best guess is that the die is rotated to a 45 degree angle. anyway i want to dump the contents so i can analyze the drive firmware.  @tubetime I’ve always wondered about that. I think your intuition is accurate since that would allow a smaller package size from less area outside the die needed to route to the external pads.   now i'm knee deep in Ghidra listings. this code probably runs the entire hard drive, not just the host interface. Meme image: good news bad news.jpg I have mainly reverse engineered things with user interfaces, so there’s always strings I can work backwards from. Doing something like a hard drive controller is playing the game on extra hard mode. this sort of reverse engineering is very much like solving a challenging puzzle. you push and push until you can deduce something based on what you already know, then you pivot, taking that new knowledge and pushing on that until you learn even more. so last night I identified the power on self test routines by inspection. it's not too hard to identify a checksum routine or a memory test routine. this helped me fill in the memory map. also, the POR test function stores the results at a particular memory location, and the codes match up with the POR error codes in the DBA-ESDI spec! the next step is to search the whole ROM for any instructions that read this memory location--this should identify the functions that generate the status block. drive firmware is turning into a bit of a slog so i switched over to the IBM BIOS. having a spec is nice, but the code will cover a bunch of corner cases. @tubetime Out of curiosity, does the newer IBM BIOS have any similarity to the original IBM PC AT BIOS that they published in the AT Tech Reference from March 1984? Wondering if they ever did a full rewrite at some point. http://bitsavers.trailing-edge.com/pdf/ibm/pc/at/1502494_PC_AT_Technical_Reference_Mar84.pdf managed to reverse engineer enough that I was able to read the defect map out of one of the original hard drives. sounds easy but the process uses DMA.  @tubetime I've lost count of the things I've done that "sounds easy but the process uses DMA." working through a nasty timing hazard with the mailbox flags on the command port. sometimes you write data and the "data available" flag never gets set. so now i am digging through the logic that yosys generated to see if it even makes sense. having good test programs is important. here's the status interface register dropping values. the Teensy program is just writing an incrementing number, and the diagnostics program is checking for gaps.  @tubetime got that all sorted out. it was a synchronization issue with the flags between the two interfaces. this is the "seek" command successfully completing! this is a *major* step since it requires 4 working mailboxes and interrupts. another important step today--i got the data port and data port mailbox flags working. it can also detect 8-bit vs 16-bit transfers. getting very close to working PIO transfers. nice! I managed to get PIO data transfers working well enough for the buffer test routine to pass. ok this is fantastic--I've managed to transfer my first actual sector! it's just using PIO and the data is not from a real filesystem, but this is another big step forward! @tubetime Almost makes you want to lovingly caress it's slightly sticky chemically degraded surface. 😉 DMA on Micro Channel is really hard. i'm running a bunch of simulations first, making adjustments to the logic as needed. so many moving parts. @tubetime I wonder if IBM expected you to use a special chip that did a lot of that for you. wow, got four bytes to transfer successfully over DMA! not sure why it got stuck after that. just ran the same test again and it transferred the whole sector over DMA!! so at least read transfers are working partially. writes just hang the machine after transferring half a sector. it's probably time for the logic analyzer. not sure why I always end up in front of a logic analyzer, but here we are.  The logic analyzer from the perspective of the PCB: https://www.youtube.com/watch?v=nYPX-QQR9Tg several issues. this first issue, during a host to device write, holds the arbitration bus too long. it should release immediately after the second arb/gnt pulse had a theory and it reproduces in simulation. the transfer request flag isn't getting cleared soon enough. la_dma_selected is what can clear this flag and it is changed on the falling edge of cmd, which is too late to catch the ARB/GNT pulse. yes, that solves the crashing problem. but data isn't getting transferred correctly, so I've got more work to do. weirdly enough, it works the second try!!! something on the host was prematurely turning off DMA. maybe a bug in difdiag. @tubetime @Netux it's a solid state hard drive replacement that I'm designing. EE but I do some digital stuff too  @tubetime It's at least so common that the Altium footprint generator has an option for it, although I have never seen it in the wild on any chip sp far.  @tubetime A lot of early quad SMD packages numbered starting in the middle of the "top" side, and that was purely a (dumb) thing done by package vendors, and dice were always still mounted orthogonally. (or perhaps _almost_ always) |
moving on to the Teensy interface. i had to choose the IO pins carefully so i can make a 16-bit parallel IO port.