My last post was full of text, and therefore not very approachable. This post will hopefully explain some of my thoughts in a clearer way, with the diagrams and schematics (hopefully) doing most of the talking.
First up here is the current, work in progress, system overview:
(I tried looking for some nice online tools for making these kinds of diagrams, but in the end settled with using the schematic capture program from the gEDA suite, the same one I use for my schematics. All the online tools I found sucked in one way or another.)
Common busses, notably the data bus, run around the edge.
The MuDdy FPGA is the system core, and glues the whole computer together. It generates the physical address (seen by the RAM and EEPROM) and the various chip selects, one for each device. Only key select lines are shown. Likewise most read and write lines are hidden in this diagram. This FPGA is also connected to the HALT line on the CPU, so it can stop it whilst performing DMA operations. MuDdy also receives bus status information from the CPU. A buzzer is also attached, and will be used, as before, principally to indicate boot progress and boot errors.
DISCo is pure peripheral, though it also has the job of routing interrupts. Again, only some interrupt lines are shown. DISCo is also connected to a DAC, and through the DAC to a 3.5mm mono jack. It is also connected to the IDE header.
Moving along, the SPI controller is the 65SPI/B, a variant on the regular 65SPI used previously. It has some advantages, the main one (for me) is that it can route interrupts. This means the DS3234 (PDF) interrupt output, very useful for generating a precise system tick, does not need to be attached to MuDdy, and instead the 65SPI/B can pick up the interrupt and forward it along by generating an interrupt on its own interrupt line. In addition to this, it can also generate its own interrupts at the end of a transferred byte, etc. Also attached to the SPI master is an ADC. This is used for a new addition to the MAXI09 plan: an analogue joystick. Writing pong should be reasonably easy, and is much nicer to play with an analogue joystick.
As a side project I will build my own joystick out of an old X Box controller stick and some push buttons. It won’t be pretty but it should work well. It will connect to the computer using a six pin mini-DIN. This is the same connector as a PS/2 keyboard or mouse, and has the advantage over a DB9 because it is smaller, saving precious board space.
A VIA will be used for a single 9 pin Atari joystick port. It will handle the six digital joystick inputs, plus two buttons from the analogue joystick. The other half of the VIA will be useable for general IO, but won’t be bought out into an external connector.
Video will be provided by a V9958, equipped with 128+64KB of RAM. Unlike the old IO board, RGB video will be amplified by an AD8073 (PDF) IC, which should provide a better quality picture. Composite and S-VIDEO will be provided by appropriate connectors, driven from an AD724 (PDF).
The keyboard and controller will be similar to the one used previously, expect it will be attached to a UART channel instead of a VIA port. This will allow bidirectional communications between the MPU and the keyboard controller, allowing things like key repeat rate to be set. The keyboard MCU will also have an RGB LED attached, that will be used to show keyboard and system health. For instance, if the MPU does not acknowledge scan code bytes in a reasonable time, it will enter an error mode and flash the LED. For fun, it will be possible to change the colour of the LED from the MPU. This LED will be attached using a flying lead and a header, such that it will be visible outside the computer’s case, when one is eventually made. In this way it will double up as the systems power indicator.
Below is a draft schematic for the keyboard controller portion:
I have chosen to continue using the PLCC44 version of the ATMega8 on the MAXI09, even though a version in DIP28 has just enough IO pins now that the UART is used instead of a full 8 bit port with handshake lines to talk to the MPU. But I have chosen to stick with the PLCC44 footprint with four 8 bit ports since it will be easier to program as it won’t require port accesses to be spliced together when scanning the keyboard.
This takes us on to the UART. Or rather QUART, since this computer will have four UART channels. Perhaps it is excessive, but they could all be used one day. As mentioned, one will be used for the keyboard. A further two will be presented at EIA-232 signal levels, but to save board space RJ45 connectors will be used instead of DB9s. Unlike in the previous board hardware handshaking lines, RTS and CTS will be available. An eight line driver, in the form of the MAX238 (PDF), will be used as a level shifter for the two externally presented UART channels. The final channel will be headered out on a simple 3 pin header and will be useable via a USB FTDI lead.
Here is the preliminary schematic for the UART section:
The QUART used is a Philips/NXP SC16C654 (PDF) in PLCC68. I have not used this part before but it appears fairly similar the the XR88C681 (PDF), used in my previous micro. Slightly irritatingly, this UART does not have a timer. Therefore the main system timer will have to come from another source. Luckily there are still several others to choose from.
The main reason this schematic is a draft is because I have not figured out which pinout to use for the RJ45s. Unlike with DB9s, there is no standard pinout. Each equipment vendor (Cisco, etc) have their own standards. Therefore I will base the pinout on the RJ45 to DB9 leads I already have access to, but I have yet to determine the pinout they use. (I do appreciate that I am using the wrong terms here. The DB9 used on serial ports is correctly referred to as the DE9; the RJ45 used on Ethernet (and some serial console ports) is actually an 8P8C connector. I choose to use the terms that most people know these things as, even if they are wrong.)
This pretty much finishes up the current thinking behind the hardware. There’s a few details related to the PCB which I have also decided.
As I mentioned in my previous post it will be a four layer board. Vcc and ground will be on internal layers, with the outer layers used for signals. This should hopefully simplify the laying out process, at the expense of a more costly board. Power will be presented on a 5V barrel connector instead of my usual USB-B socket. This will mean an ordinary wall-wart type PSU could be used. Alternatively, USB-A to barrel leads are available. The one disadvantage with this idea is that it’s possible someone might plug a higher Voltage barrel plug into the computer by accident, blowing up components. This generally wouldn’t happen with a USB socket since all USB devices are rated at 5V. This makes it a bit of dilemma, but I think the advantages of a barrel connector outweigh the disadvantages.
I have yet to figure out how, precisely, to utilise a single configuration flash to store the design for two FPGAs. The data sheets (PDF) explain how to wire up the parts to achieve this; what is not clear is how to construct the “program file” which needs to be loaded into the Flash such that it will then program multiple FPGAs at startup. This is quite frustrating, since I really don’t want to use a configuration flash with each FPGA. If I cannot figure it out soon I will have to consult the experts on the Altera forums.