Just for the benefit of posterity or whatever, I've sent away for two new PCB designs, that are available in the github repo mentioned in prior posts. One (v3.1) is just a rewiring of v3 (the one that sparked this thread discussion) with all of the data lines and the A0 and A1 lines tied to the same Teensy port register (port C). The other one is v4, which is both a rewiring of the data and lower address lines, *and* the addition of a data latch tied to the WR* signal from the TRS-80. In theory this would remedy the race condition that appears to be happening only for the WR* side of the interaction. So I'm covering both bases -- either it'll be solvable just with a simple adjustment of the wiring and the race condition can be managed in software, or adding the latch will make the race situation immaterial, because the latch will hold the data long enough for the Teensy to always be able to strobe it.
While I'm waiting for the new boards, I started working on the software for the emulator, and it actually almost works, even on the dysfunctional v3 board. With really careful coding, I've got the v3 board to be fairly reliable, only screwing up the data or A0-A1 lines about once every 1000 bytes transferred or so, which is enough to get the emulator to feed the first few sectors of a NEWDOS disk image on boot up. The TRS-80 gets part way through the loading of
NEWDOS and then flakes out, but it's pretty awesome watching the data feed back and forth, with the code in the TRS-80's rom thinking that it's talking to an old Western Digital FD1771 chip (except a *lot* faster).
I should also mention *how* I've gotten the software to this point, because it was kind of non-trivial. I started out trying to write the software by reading and interpreting the data sheet for the old FDC chip, but frankly that was a false start. There was way too much that could be left up to interpretation in how that data sheet described things. Plus, as I figured out later,
the data sheet didn't really tell me anything that was unique to how the TRS-80 *used* that chip, which ended up being more important than I realized.
So, I found a copy of the source code for a TRS-80 emulator called
sdltrs. Unfortunately this code hasn't been maintained, so it was a pain to get it compilable again (had to download an old old old copy of Ubuntu... like 10.04, and then figure out how to get it to update itself despite being out of support... then finding a version of SDL that would still run on that old version of Linux... then find a browser that still worked on that old distro...) However, once I got it compiling, I was able to load the emulator up with all kinds of debug code, and from that I could fire up the exact disk image I'm wanting my hardware emulator to host, and just examine what it was doing at boot up time. There was clock involvement that I had no awareness of (an interrupt that fires every 25ms with a data pin pulled high to tell the ROM that it's a clock signal). Also, I realized I was thoroughly confused about how the status register worked in the FDC, and so I had to approach all that differently than I was planning originally.
So, where things stand right now is that I can *almost* boot arbitrary TRS-80 disk images on the Teensy based emulator now, and I'm waiting for the new PCBs to hopefully wrap it all up in a nice bow. Once i get it running, I'm going to add
one of these little screens. and some up/down/select/cancel buttons to make the thing self configurable.
Once that's done, I'll probably merge the HDD emulator with the
video/audio/gaming/communications card, and it'll be a complete expansion system.... for a 40 year old computer... and I'll officially earn my
Old School Neck Beard Badge.
I gotta say, it takes a little getting used to Teensy's quirks, but it's an amazingly versatile board -- very small, very fast, very approachable, lots of pins... Great balance.