Today I’ve been thinking about ways to simplify the Plus Too hardware. Anything I can do to reduce the part count will make the final board easier to build, and also help with the the inevitable debugging work. The nice thing about some of these ideas is that they dovetail, making further simplifications possible.

Soft-68000

My original plan was to use a real 68EC000 CPU. My motivations were a desire for “design purity”, and a wish to avoid having to learn how to work with a 68000 FPGA core and its possible bugs. After experimenting a bit with the free TG68 core, however, I’ve completely changed my mind. It took me just 30 minutes from downloading the TG68 files to having a working 68000 executing instructions from the Macintosh ROM inside my FPGA. The design is much easier to understand than I’d expected, and my fears of configuration voodoo and weird bugs seem unfounded. Using TG68 will not only allow me to eliminate a chip, but will also make it possible to directly inspect CPU registers and perform other live debugging tricks that wouldn’t be possible with a physical 68000 CPU.

One FPGA

In my earlier Too Many Pins entry, I counted the number of required FPGA I/O pins, and concluded I either needed to use two separate FPGAs, or learn how to solder BGA components. It turns out that most of the I/O pin count was related to connections to the physical 68000 CPU. I recounted the I/O pin requirements assuming the use of TG68, and it’s only 58 pins, plus or minus a few that I probably forgot. That’s well within the user I/O count of a single FPGA in a TQFP package, which I have some hope of hand-soldering. So there’s another chip gone.

Configuration by Microcontroller

Unlike the CPLDs I’ve used before, FPGAs don’t maintain their configuration when the power is turned off. They must be reloaded with the configuration bitstream each time they’re powered up. Although I didn’t call it out specifically, I had assumed the FPGA configuration data would be stored in a standard configuration Flash ROM. These ROMs are programmable through JTAG, and have all the smarts needed to configure the FPGA.

Some reconfigurable computers like Minimig use a different technique, and store the bitstream in an alternate medium, using a microcontroller to read the bitstream data and configure the FPGA. Because Plus Too will already have a microcontroller for floppy disk support, and an SD memory card loaded with floppy disk images, it should be possible to use the microcontroller to load the FPGA configuration bitstream from the SD card. I haven’t investigated the details yet, but with some good examples already out there, I’m hoping that it won’t be too difficult to get working.

ROM image in RAM

Taking this same idea one step further, the Macintosh ROM data could be stored in another medium, and loaded into a section of RAM at initialization time. The transfer of the ROM image could probably be done by the microcontroller, or else by a module in the FPGA that runs before the TG68 soft-CPU module starts. Assuming a large enough RAM, both the “real RAM” and the ROM image could exist side-by-side. The address decoder would direct accesses in the ROM address space into an alternate section of RAM, and ensure that all accesses to this section were read-only.

And Then There Were Three

If you put all these ideas together, only three chips remain: an FPGA, a microcontroller, and a RAM. Three main ICs to solder sounds very manageable. The other components are miscellaneous parts like the clock oscillator, buttons and LEDs, and some discrete components for video and audio output. Of course there will still be quite a few connectors to solder: the SD card holder, PS/2 jacks, VGA port, JTAG connector, serial connector, and maybe some others I’m forgetting.

Three’s a Crowd?

To simplify things still further, it might be possible to eliminate the microcontroller, and implement a microcontroller soft-core in the FPGA instead. Free cores for the ATmega instruction set and other microcontrollers already exist. This raises the question of where the microcontroller program and data are stored, however, as both are too big to be implemented inside the FPGA. Perhaps they could live inside the RAM alongside the CPU’s RAM and Macintosh ROM image, but then the microcontroller would contend with the CPU for memory access. Eliminating the microcontroller would also require reintroducing some other part to configure the FPGA at initialization time, so there would be no net component savings. For all these reasons, it doesn’t seem that eliminating the microcontroller would help.