That's a good suggestion, Bryce... since I am using PLDs for the address decoding, it is quite easy to let it listen to DKtronics and SSA-1 ports as well, without increasing the chip count. Maybe I can also add a little DIP switch for IO port selection.
With regard to compatibility - as far as the Atmel 328 programming is concerened, it should be possible to implement some kind of "byte to allophone" tables that could come close to what SSA-1 and Dktronics are doing (I actually own both). However, a bigger problem is timing and synchronization between the CPC and the 328. So far, proper communication requires a special "protocol" between the CPC and the 328. Basically, it needs Bit 8 from the databus to "clock" the data connection. I.e., to send the characters "AB" (65 66) to the 328 (which sends it to the Emic over serial), I am currently sending the bytes "193 (= 65+128) 0 194 (= 66 + 128)"; otherwise, the 328 was no able to reliably read the bytes with its IO ports (I got bitflips and all kinds of synchronization problems...) THe original idea was to simply use the chip select / address detected signal from the PLD's, and feed it into the 328 which would use it as an interrupt, and then read the byte from the databus. Didn't work. I am wondering if anybody else has encountered this problem, and has a potential better solution. The schema above is working quite reliably, but is also timing sensitive, since the data connection is "self clocked" in that way, and the 328 is, honestly, not the fastest, even though I am clocking it with 16 Mhz. So there needs to be some delay between sending the bytes, as well as zero byte in between payload bytes, for some reason. It turns out that the 328's INT0 interrupts was completely useless for implementing this "receiver", so I am currently just polling the IO ports of the 328 in a tight loop, buffering bytes as I am receiving them. At first I was just hoping the 328 could listen to the data bus directly, but these dreams were shattered early on in the project :-) Hence, I even had to add the flip flop to latch the data bus; something which I had though would not be necessary.
Bryce, if you have any ideas / experience on how to read bytes fastly and directly from the databus, without requiring the above "protocol" trick, please let me know! A bus driver or similar would probably also not make a diference; the flip flop that I have should be good enough for this.
So, to answer your question - it might be possible, but it's not too straightforward with the current design
I would first need to figure out how be able to directly buffer bytes from the data bus without requiring the "8th bit must be set" and "zero byte" protocol. If that should be possible with the 328, then it is also possible to emulate SSA-1 and DKtronics.
