In order to bring this project to the 21st century and make it as easy as possible to interface to modern data standards, we need to design a new data card.
When i made the schematic for the original data card, i yeeted the audio circuitry because honestly I did not care as I didn't need as sophisticated of a circuit for the audio stages.
At this point in time, the audio and warning circuits weren't even in my mind. The most important thing is how do I interface with the bus, and how/what do I use to get data into the system?
The venerable Raspberry Pi has entered the chat...
Yeah, that's right. yet another raspberry pi project. BUT... it is the most convenient tool to interface with the data card, and act as a host. downloading the system binaries, graphics assets, and data on the fly in one swoop during startup. It makes the most sense to me logically.
So with our control host chosen, we need to design the data card around this concept.
First thing I need to do is pick the design. Physically, it will be just like the original one as far as shape/size. But the electronics for interfacing to the bus are going to be interesting.
However, i figured why not use the original stuff they already had? Thing is... unlike the I/O card dumpster fire, the data card must have been designed by a different engineer. it actually uses gated logic to interface to the 68K bus and its cycles, reading and writing out of latches and a FIFO. so CPU intervention isn't necessary.
So, to start off the new design, lets just "copy and paste" the original bus logic.
I kept the bus logic so original, that i even kept the original PALs! So you can just move the PALs over from the old data card onto the new prototype card.
As you can see, I simply kept the same logic design as they had, I even pay this as a tribute to the original data card kind of as a nice send-off.
We do need to make some modifications. First, I replaced the old FIFO with a much bigger one. I can load up to 4K chunks and then have the 68K read out that entire FIFO. This allows me to send data across the bus faster when i break large binary files up into 4K chunks versus 512byte chunks. alot less bus activity and back/forth negotiation.
Also, the key here was to figure out how to interface this logic to the Pi. My thought process here was to eliminate the old 8044 MCS51 CPU and replace it with the Pi instead.
However, anyone that has worked with a Pi, knows the GPIO is 3.3V. this is a 5V card so we need to design in some logic shifting circuitry:
Which we have done here. Then, we just wire up the Pi's GPIO header into the logic level shifters which then wires up to the same spots the old 8051 used to be.
Presto! we have now successfully wired up a raspberry pi GPIO into the old bus interface logic borrowed from the original card. In theory, this should work...
This offers many benefits as in I dont have to design new logic circuitry from the ground up, but also it can allow a pi in direct control with the main CPU card via interrupts. This logic cannot access the bus directly, it can only load up the registers or FIFO and then issue a manually vectored interrupt back to the main 68K CPU. so the 68K itself has to handle whats going on with the data card, and its logic.
So even with this, we still need some minimal bootstrap code on the 68K ROM itself to handle whats going on with the data card.
With the data/control side out of the way, that leaves just the audio part. For the prototype data card, I did not design any of the audio circuitry on the card since I did not quite know yet exactly how to approach it as I wanted to simplify the original audio circuit into a single audio path plus warning alert path. All the extras the system did originally, did not matter here.
I did wire up the original latch logic they had, but I left them unconnected here.
So for now, I will forgo the audio circuitry for now.
Still, the original logic had one design flaw. There is no return FIFO. so the 68K CPU from the main CPU card can only read block transfers from the data card, and not the other way around. the CPU can only write one byte at a time to a register on the data card, which raises an interrupt flip-flop back to the 8051 which is now the Raspberry Pi. Trouble is if the Pi doesn't catch the byte and read it quickly enough, the 68K CPU can overwrite the byte it just sent with a new one, Say during block transfers.
This makes debugging the system difficult because I cannot send stack dumps from crashes back to me for debugging purposes, so I literally have to fly blind. I will have to use the UART on the I/O card as best as I can which comes with its own problems.
Anyways... As a troubleshooting aid knowing the above being a problem, I wired up an LED bargraph to one of the two audio latches and used that as an 8-bit debug port. I can set an LED on or off during the execution of subroutines on the 68K to know if something is good, or bad. Literally the only feedback out of the system is turning an LED on or off.
So, with the preliminary design solidified, it is time to start laying out and designing the card!
Going swimmingly, but routine can be a nightmare. I have EAGLE set to the smallest built-in via size and trace widths on some of this. Im sure there is a way to set it smaller but I dont feel like making the board house angery.
Once I had the layout done, I wanted to print it to scale and to a test fit:
Remember when I decided to forgo the audio circuitry? Well I didn't want to entirely shoot myself in the foot, so i decided to apply a prototyping area to the board. Which turned out to be beneficial when I added the LEDs to one of the audio latches for debugging purposes.
There... that should help with throwing something together for testing once i move past the hurdle of actually making the machine run code again.
With that, we have our final prototype design:
And, a PCBWay order later, we have our final product:
the logic circuit area is identical in design of the original card with the exception of the 8051 and the change on the FIFO size.
Time to build up the card, and then I added the LED readout for debugging purposes. I could have gone 7-segment but I used what I had which was an old radioshack bargraph display. Doing this will prove crucial later.
And there we have it! a method of interfacing a 68K machine to the modern world.