Designing a 68K Single Board Computer
Hackers of a certain age love the 68000 family of CPUs, and I’ve begun sketching out designs for a 68K-based single board computer. Take a vintage off-the-shelf CPU, add ROM and RAM and an SD card and some type of I/O, and Bob’s your uncle! I plan to start with bare metal programming to test out the hardware and peripherals, then try to get text mode Linux running. I/O will probably be exclusively through a serial port, but I hope to also include a USB controller to see what I can make happen through Linux. For inspiration and direction, I’m drawing heavily from Simon Ferber’s (Kiwi) and Luis Alves’ 68K-based homebrew designs. Here we go!
CPU
I have an old MC68008P8 CPU gathering dust in a drawer that would be perfect. The P8 version is rated for 8 MHz, and the 68008 is essentially a 68000 with an 8-bit data bus instead of the standard 16-bit bus. That means its memory throughput is only half the 68000’s, and since it has no cache and most instructions require a memory access, its performance is only slightly better than half that of a 68000 at the same clock speed. But what it lacks in speed, it makes up in simplicity. The 68000 requires twice as many data lines to be routed, and either twice as many RAM and ROM chips, or physically larger chips with 16-bit interfaces.
Luis Alves’ machine used a regular 68000 at 20 MHz, and got decent performance running ucLinux. An 8 MHz 68008 will only have about 20-25% of the performance of that system, which might be a problem. Maybe I should look into the availability of suitable 16-bit ROM and RAM chips before making a final decision.
ROM and RAM
Speaking of ROM and RAM, there’s not much to say here beyond the question of bus width. Pretty much any Flash ROM and SRAM should be more than fast enough to keep up with this CPU. Something like a few MB of ROM and 4-16 MB of RAM should be OK. Thinking ahead to Linux, if I can store the kernel and other programs in ROM and execute the code from there, I can reduce the amount of RAM I’ll need. As a size reference, the kernel for my Raspberry Pi is just over 3 MB, so that’s not unreasonable to put in a ROM. There’s something called XIP (execute in place) that’s supposed to make this possible, but I have no idea how difficult it might be to get working.
It’s probably safer to assume a bootloader will copy the kernel into RAM and it will execute from there, but in that case I might as well write a slightly smarter bootloader that copies the kernel from SD card to RAM instead. Perhaps ROM only needs to be large enough for a minimal bootloader – a bootloader loader – say 512 KB or less.
I’ve been assuming the RAM will be SRAM, because it’s easy to work with and it’s what I’ve used for all my past projects. I know DRAM isn’t that complicated, but every time I read about RAS and CAS and DRAM refresh, my eyes glaze over and I just pay $2 more to buy SRAM. That’s fine for smaller RAM sizes, but if I end up going as high as 8 or 16 MB, it could become a space and cost problem. Large capacity SRAMs are rare, and fitting 8 or 16 smaller SRAM chips on the board would be painful.
Serial Port
The serial connection could be a simple UART, but something like one of FTDI’s common USB-to-serial converters probably makes more sense. Or a USB-to-serial/parallel converter like the FTDI 245, which has a USB interface to the PC and appears as a virtual serial port, but presents a parallel interface to the 68K CPU. That should be a little easier to work with, and faster when transferring large amounts of data. The ‘245 also has a decent-size buffer and hardware flow control, which an old-school UART might lack.
CPLD or FPGA
Something’s got to decode memory addresses to determine which RAM or ROM or other chip to enable for a particular memory access. If that were the only requirement, address decoding could be hard-wired using a few 7400-series logic chips. But by doing the decoding in a large CPLD or small FPGA instead, other glue logic functions could be consolidated as well. These include things like reset handling, simple timers, interrupts, GPIOs for buttons and LEDs, and SPI/I2C conversion for peripherals.
A CPLD is strongly preferred over an FPGA, because the CPLD’s configuration is held in its internal non-volatile memory. An FPGA’s configuration is RAM-based, so it would require something else to configure it every time the board boots up. And if the FPGA functioned as the CPU’s address decoder, the CPU would be non-functional during this time, and couldn’t do the boot-time FPGA configuration. Some other device like an on-board microcontroller would have to do the job, adding to the system complexity. CPLD’s are much simpler in this respect, but are limited in the amount of logic they can implement. My combined address decoder / reset handler / timer / interrupt controller / GPIO / SPI / I2C monster may be too complex to fit in a CPLD.
SD Card
While external storage isn’t required, especially for experimental bare metal programs stored in ROM, some kind of external storage for Linux is a practical necessity. Fortunately the hardware interface to SD memory cards is very simple, and I’ve done it before as part of my Floppy Emu project. All that’s needed is a few pins to connect an SPI interface, and the rest happens in software. The 68K CPU doesn’t have an SPI interface, of course, but the CPLD/FPGA can easily implement a byte-wide parallel to SPI interface.
Ethernet
Ethernet isn’t really required either, but what fun is a Linux installation without a network connection? The Microchip ENC28J60 is a popular and well-supported chip for creating a wired ethernet connection. It uses an SPI interface for talking to the CPU, and there’s Arduino example code available for it, which I could probably decipher. There’s also driver support in newer versions of the Linux kernel. For ease of use, Sparkfun and other suppliers sell a small module based on the ENC28J60 that also includes the required caps, resistors, and inductors, as well as the ethernet jack.
USB
The Maxim MAX3421E is a USB Host controller chip with an SPI interface. It’s the basis of several Arduino USB Host shields, and I could use the associated Arduino libraries for examples of how to get it working. It looks like Linux kernel support was just recently added, in kernel 3.16. I’m not sure I could actually get this working, but it would be cool if I could directly hook up a USB keyboard or thumb drive or other peripheral.
SPI Performance
It might seem that using SPI-based solutions for external storage, ethernet, and USB would be a performance bottleneck, since SPI data is transferred one bit at a time in serial fashion. If you check the math, however, the 20 MHz SPI speeds of these devices is still enough to keep up with an 8 MHz 68008. A 20 MHz SPI connection can theoretically transfer 20 million bits/second, or 2.5 million bytes/second. An 8 MHz 68008 needs 4 clock cycles for a single byte-wide memory transfer, giving it a theoretical max of 2 million bytes/second – less than the SPI limit. But it’s actually even worse than that, when you consider the two memory transfers (8 clock cycles) needed to load the 16-bit CPU instruction that performs the SPI transfer. So even an unrolled loop writing a constant value to SPI could do no better than one byte sent per 12 clock cycles, or 667Kbps. In practice, the overhead of serializing and unserializing data for SPI will never be a bottleneck on this system.
Level Conversion
With a mix of old and new hardware in the system, 5V to 3.3V level conversion will need to be performed somewhere. The fewer places, the better. The 68008 is a 5V part, and the ROM and RAM can probably be found in either 5V or 3.3V varieties. The CPLD or FPGA will run at 3.3V, but may have 5V tolerant inputs depending on the specific part used. The ethernet and serial chips are 3.3V with 5V tolerant inputs, and I think the USB chip is too. SD cards are 3.3V devices and not 5V tolerant, so conversion will be needed there. If all the 3.3V devices are connected to the CPLD instead of directly to the CPU, and the CPLD is 5V tolerant, then it can serve as the system level converter instead of requiring dedicated level conversion chips. Unfortunately I think few CPLDs are 5V tolerant, and even fewer FPGAs, and the ones that are tend to be old and obsolete.
Misc
How does the Flash ROM get programmed? Once the system is working, I think a bootloader can copy itself from ROM to RAM, then run from RAM while it updates the ROM contents. But for initial board setup, the ROM will need to be initialized with a external programmer hardware.
How does the CPLD get configured? I don’t think there’s any way the CPU can do this, so the board will need a JTAG header and a Xilinx/Altera programming cable to update the CPLD configuration.
A few pushbuttons would be useful: at least one for reset, and one to trigger an interrupt. Maybe a run/stop slide switch too – though I’m not sure how I’d use it. Some status LEDs or a 7 segment LED display would be helpful for debugging initial hardware setup, but probably useless after that.
It’s probably a good idea to include some expansion headers, for things I didn’t consider originally. If the header provides access to the entire data bus, some lower bits of the address bus, the CPU read/write control signals, and a few unused CPLD pins, that should be enough to support some extra external hardware.
Read 24 comments and join the conversation24 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Oops, I forgot the 68008 has fewer external address pins. My DIP 68008 only has enough pins to address 1 MB of total memory, so that’s out. I guess I’ll be using the standard 68000 after all.
At first it looked like larger capacity SRAM’s would be no trouble to find, but then I remembered SRAM capacities are advertised in megaBITS, not megabytes. The largest compatible SRAM I can find is 1 megabyte and costs $6.59 – that would require 8 or 16 chips and cost over $100 just for the RAM. Ugh.
Cypress has 4Mx16bit sRAM: http://www.cypress.com/?mpn=CY62187EV30LL-55BAXI , but it comes in BGA package and costs $50 (there have also 1Mx16 in TSOP package, but that one costs $25…). Looks like dRAM is the way to go.
What an interesting project! I’ll definately be following this one along. Might take over some ideas for my next SBC, even though I haven’t finished the first one yet.
An option for an operating system to match the 68k is one of the original BSDs. The http://retrobsd.org project has a running 2.11BSD running on a MIPS-based Microchip microcontroller (PIC32 with a MIPS 4k core) and there is some work going on to get 4.4BSD-Lite2 + patches to run on a similar platform. 4.4 requires a bit more ram so a bigger PIC32 is required. The PIC32MZ has 512k RAM.
4.4 brings swapping and a full TCP/IP stack and a big set of userland tools to the table so it really should be a full platform to play with.
The discussion on getting 4.4 to work in an MIPS emulator is going on here: http://retrobsd.org/viewtopic.php?t=36782.
I did a similar project with a MC68008, a XC9572XL and a PIC as peripheral controller. I tried to run the 68k at 3.6V, which worked – most of the time 😉 Handcoded asm code worked pretty well, but more complex code by an 68k C compiler worked unreliably and I never found out where the problem was.
If i give my 68k project a second try, i would use a MC68SEC000 which runs at 3.3V at up to 20 MHz. It has a MODE-pin which sets the 68Ks databus to 8 or 16 bits.
Look at the Alliance Semiconductor AS6C4008. 512Kx8, 3.3V-5.0V operation, even comes in a 32-pin 0.600 dip package.
I’m still on the fence as to SRAM or DRAM. Even the standard 68000 only has enough external address pins for 16 MB, which must be shared between RAM, ROM, and memory-mapped devices. I don’t have a good sense of how much RAM I’ll really need to run ucLinux or similar on a system like this – maybe 8 or 16 MB is overkill? Higher density DRAM could reduce the number of RAM chips needed, but would increase the number of glue logic chips needed to mux RAS and CAS addresses, generate the DRAM timing signals, and handle DRAM refresh. That might negate the size and complexity advantages for me. To draw an arbitrary limit, I’d like to keep the total number of RAM chips to 4 or fewer, maybe 8 at the extreme.
Trygve and anyone familiar with other Unix variants – what do you see as the advantages for this project of using something like BSD vs ucLinux? Would it have lower hardware requirements? I’ve been gravitating towards ucLinux because there appears to be a good amount of active use and support available, and I’m already slightly familiar with it. But maybe it’s not the best answer.
@Dirk – Sounds neat, do you have a link? MC68SEC000 could be a good fit – though the old-school 68000’s in giant DIP packages maybe win extra points for retro-recognizability. 🙂
The amount of RAM you need is going to depend on the class of OS you end up with. If you write your own, you probably don’t need much. If want to run an interactive OS with multiple telnet sessions etc you’ll need a lot (as in many megabytes :)).
On ucLinux vs BSD I’m not sure, I don’t know many details of either. I know Serge thinks 512k RAM is enough to boot 4.4BSD. The BSD source code is heavily documented through many old books. It might now be the hippest, but it’s certainly the most retro!
The MC68SEC000 is still produced by Freescale:
http://cache.freescale.com/files/32bit/doc/prod_brief/MC68SEC000.pdf
though not recommended for new designs 😉 Another plus for the MC68SEC000 is that it is a static design, which even allows for stopping the clock (eg. for debugging).
Decision #1: Go with SRAM. http://www.digikey.com/product-detail/en/AS6C3216-55TIN/1450-1026-ND/4234585 is a 4MB (32 megabit) SRAM that will work. It’s $21 each – ouch! But it will really help cut down on complexity elsewhere, as well as PCB area. I can design a board with space for four chips, but only populate one or two of them initially until I have a better idea how much RAM I really need.
Decision #2: Use the 68SEC000. Thanks Dirk for suggesting it. It’s the only member of the low-end 68K family that can run at 3.3V, which will enable me to make a fully 3.3V system. That will make it easier to find a compatible CPLD, and avoid the need to do any level conversion.
Great project!
One thought about bootstrapping: if the CPLD can drive the data lines and low-order address lines, you could set up some logic to tri-state the CPU buses and have the CPLD accept some serial data and put it in RAM or flash. The serial interface could be anything — SPI, async or USB, maybe.
On CPLD vs. FPGA: the Microsemi ProASIC3 is an interesting compromise. It’s a flash FPGA. It powers on instantly, but has the sea of small cells and routing resources of an FPGA. At least some models have 5V tolerant inputs and limited ability to output 5V signals. I’ve used it for a couple of projects and like it.
If you’re a 68000 enthusiast, may I recommend the DTACK Grounded archive:
http://www.easy68k.com/paulrsm/dg/dg.htm
The guy who wrote those articles, all the way back in 1981, thought that the only sensible way to build a 68000 system was to connect DTACK to ground, and make sure all the memory and peripherals could keep up. We don’t need no stinkin’ wait-states!
I am not a hardware design expert of any kind, but maybe something like PSRAM might be useful for the system. PSRAM behaves like SRAM, but internally is implemented as DRAM. There is built in refresh circuitry that refreshes the DRAM, so you should be able to treat the chip as if it were DRAM.
Here’s some info about PSRAM available from Micron:
http://www.micron.com/products/dram/psram-cellularram
The FPGA board I used for my computer used 16MB of PSRAM, but larger sizes are also available.
The MicroSemi Igloo or Igloo Nano lines might be a good FPGA choice, too. Flash-based like the ProAsic3, but smaller and a few dollars cheaper.
I like Stephen Trier’s comment about booting, but if you’re looking for retro you could wire up an old-fashioned front panel with toggle switches routed through the CPLD/FPGA, to initialize a bit of RAM.
I took a look at PSRAM, which would be awesome, except it only comes in BGA packages and has min order quantity of 500. 🙁
Something like the Microsemi ProASIC3 or Igloo might be good. How are the software tools? That’s one thing I’ve always wondered about off-brand FPGA devices from Lattice and others. The Altera and Xilinx tools are bad enough, I can’t imagine what the tools from a small 3rd-party company might be like. What hardware do you use to program the Microsemi devices? Xilnx and Altera have their proprietary programmer modules, do you need another one for this?
If I understand Stephen Trier’s bootstrapping suggestion, wouldn’t that only be useful for the very first system boot? Once I’ve written a 68K bootstrap program and manually burned it to Flash ROM, it can handle bootloading data into RAM, and even updating itself in ROM. The extra hardware and CPLD resources needed to make it into a RAM driver would be unnecessary, then. Although if I were building something to be mass produced and didn’t want to pull the Flash ROM on each one for initial external programming, I could see more benefit in that approach.
Hi, Steve.
Yes, my bootstrapping suggestion was meant for the first boot and for developing your second stage bootloader. I guess most of my designs have had soldered-down flash, so I tend to look for an ISP method right away and forget to consider socketed flash/eprom.
One more thought about bootstrapping is that you could store a little boot ROM in your glue logic. It wouldn’t take a lot to, say, read the first N sectors of an SD card and branch to them, from which you could do as fancy of a boot as you wanted. The advantage is that you could update it just by programming your glue logic, and you’d have one less chip to wire. The disadvantage is that you’d be tied to storing your OS on SD and running it from RAM. Including a linear flash memory would give you more options.
The ProASIC3 and Igloo FPGAs do indeed require a programmer. I don’t remember it as particularly expensive. Also, in theory it should be possible to program them from a Bus Pirate, Arduino, or other-brand JTAG interface using a .XSVF file. I haven’t tried that, though — I bought the programmer.
I don’t have experience with the Xilinix and Alters tools, but have not found the Actel tools hard to use. Maybe Ken can compare them?
I’m a software guy, but the FPGA coders I work with say they like Actel’s compiler better, but the place-and-route tool is slow. That may not be too important on the small devices we’re talking about here.
Nice read, and you remembered me about some board that I salvaged from the university, two of them containing the mighty 64 pin DIP, and tons of SRAM, and half a dozen of boards labelled four port ram.
They still have their EEPROMS covered, and reading this I will try to power those beasts up.
Is it OK to link some pictures of the boards from an image host, or maybe from my dropbox account?
Yes, the mighty 64 pin DIP! Sure, post the picture links. I’m not sure if the comment box will show the pictures inlined.
The photos are a bit blurry, my lab(or cave, its in a basement) is a bit dark, and I only have point sources of light and the flash is not really that good, but here it goes.
Just counted them I have two full 4 port memory boards, two with only half the ram, two full computer modules as they are labelled and one that is lacking the MC68000 and the MC68440, all the pcb’s are four layers, but the inner layers don’t have full pours, just polygon defined traces for power and GND.
There is also a SCN68681 NXP UART, the MC68440 is a DMA controller and there is four PAL’s in each memory module, I also have three sets of EEPROMs, a set must be toast as I already found them with the windows exposed.
Also one of the 68k is labelled just 68000 and the other is a 68000P8, faster version?
I have also some 20 or 30 MT5C1008-25(128k * 8 bits SRAM 25ns access time) that I recovered from the dumpster when I found this boards.
The ram’s used in this boards are the NEC D4364-15, those are 8k*8 bits 150ns access time.
If you want I could send you a couple of SRAM chips, from this boards and the bigger ones, and one MC68000 with the DMA controller and the UART chip, I assume international shipping is not that bad.
The photos are in this dropbox shared folder, you can open them safely, there are no virus or trojans, its easier to just share the folder than do individual uploads that might be blocked.
https://www.dropbox.com/sh/qrjyb7eb6xebkxe/AACquxG9G7TZCrtReuULoyfua?dl=0
Best regards.
Wow, those boards look very nice!
For the bus controller I actually find a small to medium sized FPGA a better idea than a CPLD when DRAM is involved. Most recent FPGA often comes with support for SDRAM, so you can implement the SDRAM controller, a bus matrix, a DMA and maybe a MMU all in that thing. Since the SDRAM can be a few times (orders of magnitude) faster than the CPU, the bus matrix and DMA can be a simple time sharing system.
Just for reference purpose if you want:
http://www.pdp11gy.com/3E.html#3.3
Best regards
Anyone having 68k (assembly)code for the MAX3421? I plan to include an USB host interface in my minimum 68020 system (http://www.pe1jpd.nl/index.php/minimum-68020-system)and some startup with code would speed things really up!