i'll need to figure out what is up with the MADE24 line. could be that the pin doesn't actually do that. the HDD pinout is one that i reverse engineered a while back, so it might be a mistake.

this could also explain the damage to the PC, perhaps the card tried to write to the data bus when it was not supposed to and damaged the output drivers of some other chip.

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

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.

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.

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.

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.

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.

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.

so i don't know how this flag is getting set. my hack is to preemptively clear the flag right before starting DMA, and so far, it seems to be working.

i think this code was "working" with the real ESDI drive because that one uses burst mode DMA and it finishes up very quickly, before the irq14wait routine can exit early.

the BIOS runs faster than the DIFDIAG utility, and so it seems like it is hitting a timing problem that i didn't hit before.

my drive code seems to randomly hang up and not respond correctly.

it's occasionally getting a spurious end-of-interrupt command which is really odd and points to an issue with the mailboxes (again, sigh).

but it's SO DARN CLOSE. it's transferring sectors from the IML region in the disk image.