BMOW title
Floppy Emu banner

Hardware Simplification

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.


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.


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.


Read 5 comments and join the conversation 

5 Comments so far

  1. Steve - September 13th, 2011 3:22 pm

    Oops, I was wrong about the reduction to 58 I/O pins. Even with a soft-CPU inside the FPGA, I still need to support the CPU making a ROM access at the same time the video module makes a RAM access. So I need two independent address and data busses hanging off the FPGA. That’s 80-ish pins right there, depending on how many address lines are actually connected.

  2. Steve - September 13th, 2011 3:26 pm

    OK, I think I can get away with a single address+data bus that’s used for both, and share between ROM and video access temporally instead. This will involve some changes to the /DTACK generation circuit, and possibly alter the CPU memory throughput relative to a stock Mac Plus.

  3. Mark VandeWettering (K6HX) - September 14th, 2011 7:33 am

    I’m currently toying with the possibility of making an old-school Z-80 or 8080 system “from scratch”, and am facing a similar situation: it appears that using an FPGA to create a “soft-cpu” can vastly simplify the design (it’s not hard to get essentially the entire system on a chip, and in this case running much faster than the original target hardware). I haven’t decided if I am going to go that route for sure (I originally conceived this project to learn something about old-school hardware design, not software so much) but it’s an intriguing notion.

  4. Steve - September 14th, 2011 5:21 pm

    Mark, I think it depends on your goals. For something like a Z-80 or 8080, I’d probably go with the real CPU myself, since they’re pretty small and easy to work with. I feel like I *should* go the same way with the 68000 for my project, but it’s hard to justify the added complexity and part count when I’ve already got the soft-68000 working nicely. I guess we’ll see…

  5. Peter Lund - September 19th, 2011 3:23 am

    Mark, go with the Z80 as it is easier than the 8080. It has built-in automatic DRAM refresh, just needs +5V, and is smarter when it comes to interrupts. The Z80 didn’t just win because it had a bigger (and somewhat better) instruction set or because it was faster but also because more people could figure out how to build a machine around it. And I think it was cheaper, too 🙂

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.