My interest in the 68000 family of MPUs stems from two things: it’s use in my all time favourite computer, the Amiga. And the fact that it’s generally considered a very clean design compared to its then main competition. Not that this is a high bar; anything prior to the 386 is dreadful and the later CPUs are not much better either, bar the obvious: performance and near complete market dominance.

For background: although I was a rabid fanatic of the Amiga and did a lot of programming with it – in C (I learned what I consider my “at home” language with the Dice compiler on my A1200), Perl (I first experienced this language on my A1200 as well) and AMOS – I was always intimidated looking at 68000 assembly listings and never tackled writing any asm. This will soon change. Also whilst many folks have designed and built 68K systems eg. the incredible 68008 based Kiwi, the design of this board is based almost entirely on reading contemporary books on the subject, reading datasheets, and using what I’ve learned from my 6809 projects.

If I was sensible I would be breadboarding up the simplest member of the family, the 8 bit databus 68008, as used in the Sinclair QL, in order to familiarise myself with the 68000 architecture, assembly language, and the required glue logic. But because I’m not sensible I have decided to skip forward to the 68020. This processor in the 68000 family was the first one to have full 32 bit data and address busses. It also has some Instruction Set improvements including bitfield operations and supports an external FPU.

All this power comes at a cost: more pins and an even more complex signalling arrangement for the asynchronous bus, relative to the 68000 which is in turn much more complicated then the synchronous 6809 bus I’m used to. The 68020 has 114 pins. Quad Flat Package and Pin Grid Array packaging versions are available; there are far too many pins for even PLCC yet alone DIP. I’m using PGA in a socket as I do not want to solder an expensive, and very special, part to a board that may not work.

Specifications for my 68020 board are as follows:

• 16 MHz 68020
• 2MB Static RAM on a 32 bit databus, implemented by four AS6C4008 (as used in MAXI09)
• 64KB EEPROM on a 16 bit databus implemented by two AT28C256 (ditto)
• Quad UART implemented by a SC16C654 (same as used in the MAXI09)
• 8 bit expansion connector for trying out stuff on breadboard

And that’s pretty much it! Glue logic will be implemented in a CPLD. Because of preferring the Altera tools to the Xilinx tools I previously used with the XC95108 which I incorporated in my earlier 6809 SBC, this board will use a member of the Altera MAX7000 family (PDF), an EPM7128S in PLCC84. As a diagnostic tool the CPLD will have an LED and a buzzer attached.

I’ve not used this particular CPLD before and I’m taking a further risk using it without trying it out on breadboard, but I’m quietly confident.

I’m calling this board the MINI020, as a silly pun on the 6809 based MAXI09 board.

One of the nice things about the 68020 is that the databus can be attached to memory and peripherals that are 8, 16, or 32 bits wide. It even deals with misaligned accesses although the downside is this greatly complicated the glue logic.

Here’s the MPU, CPLD and expansion portion of the schematic:

You can see the sheer number of pins on the 68020 is almost three times as many as on the 6809. In an earlier version, I had nearly all the pins linked between the MPU, a larger expansion connector and the CPLD. But after trying to route the PCB I had to reduce the number of connections almost down to the minimum shown here.

The CPLD is connected to the databus, well 8 bits of it, so it can expose registers for the LED, buzzer, and other things like interrupt routing.

The memory map for the computer, determined by the as yet unwritten VHDL, omits usage of the high byte on the address bus; only bit 0 to 23 are used:

000000-00ffff : ROM (64K)
010000-01ffff : CPLD
020000-02ffff : Quad UART
030000-03ffff : Expansion (example)
e00000-ffffff : RAM (2MB)

The 68000 family wants its reset (and other) vectors at the base of memory (unlike most 8bits) so the ROM will reside there.

As mentioned, some MPU pins aren’t available at the CPLD which is disappointing. This includes the Function Code pins and the bus mastering control pins. I may yet try to squeeze them onto the expansion connector so I can, if I want, route them to the CPLD via the USERx pins for experiments.

The /RESET signal is provided by a DS1813 (PDF) as previously used in my first proper 6809 SBC. Note that the 68K family’s reset pin is also an output for when the RESET instruction is issued. This is Ok as the DS1813 has an open collector output.

Here is the memory section:

Each memory IC has its own chip select signal – needed because although accesses are generally 32 bits wide accesses down to 8 bits are also possible. The four 512KB SRAMs are also attached to the MPU’s byte addressing address bus shifted up two places: a 32 bit access will select all four ICs at the same time.

The EEPROMs will be reprogrammable in place, with a write protect jumper as used in earlier boards. Unfortunately there will be no boot loader pseudo ROM like in the MAXI09 so the computer will not have a off-EEPROM flash mechanism if the flash routine becomes inoperable for any reason.

And the Quad UART:

Almost nothing to see here. This is identical to the MAXI09 UART section except the databus is exposed to the high order byte on the MPU because this is how 8 bit wide ports need to be attached. MAXI09’s connection its keyboard MCU has been replaced with another header, giving it two ports on RJ45 RS232 levels and two on TTL level headers. I did think about dispensing with the MAX238 and dual RJ45 socket but decided to keep them in as I prefer to use serial over CAT5 as the cables can be longer and in general I find these cables less hassle then using a USB to TTL serial converter.

The power section is not worth reproducing here, suffice to say I’m using the same potted 5V switching regulator as the MAXI09. I did think about powering the board via USB but thought better of it.

After drawing up the schematic the next task was (and remains to be finished) the layout of the PCB.

Looking at the PGA footprint and Pin assignment:

You can see it has three rows of pins on three of its edges. This means to route a pin from the back row to the IC’s edge would need both sides of the PCB, assuming one signal passes between two pins on each side of the board. This obviously requires a 4 layer board to at least eliminate the power pins from needing to be routed, although it would be interesting to see if anyone ever made a 2 layer 68020 board.

In the end it was clear that I’d need to route two signals between two 100mil spaces pins. In all my previous boards I resisted doing this, wanting to keep traces and clearances as wide as possible. I have had to reduce my feature sizes down to the smallest allpcb.com allows: 6 mil, at least without paying a premium. This is very annoying but is a consequence of the PGA socket and the sheer number of connections, even after some trimming. Here is an over-view of the board layout as it currently stands: 

I am sticking with throughhole parts, still. I did think about making the SRAM ICs surface mount; it would greatly reduce the size of that area, but potentially wasting about £20 worth of ICs – I don’t feel confident that I could remove the parts – on a dead board did not seem a risk worth taking.

This layout is not yet final. I am not at all proud of the sheer number of vias. Looking at other people’s boards, I am clearly doing something wrong with my scheme of having largely horizontal trace runs on one side of the board and vertical runs on the other.

Here’s a close-up of the MPU area, showing that in a couple of places I’m currently running no less than 3 traces between two 100 mil spaces pins:

One of the things that does not help my routing is that it does not exploit a very useful aspect of CPLDs: the largely uncommitted pin assignments. What I want to be able to do is route to nearby CPLD pins, instead of always following the assignment made on the schematic. This would reduce the amount of “round the houses” some trace routes are taking. Whilst it is possible to do this with KiCAD it involves going back to the schematic, adjusting it, and then saving and loading the netlist. Not ideal but I will probably go through this exercise if it means reducing the via count and reducing the length of some traces.

I could also do a similar thing with the RAM address and data lines, though the benifits there would be smaller.

One of my motivations for wanting a better layout then I’ve currently achieved is the sheer level of satisfaction a good layout gives you. I can’t find a better example of this then the Amiga 4000 boards, which are a sight to behold: many, many SMT parts, massive 32 bit busses routed everywhere and barely a via in sight.

While on the subject of KiCAD, I have updated my install to Version 5 from 4 which was previously used when working on the MAXI09 project. Simultaneously I have also switched to running it on my desktop machine, a Mac Mini without resorting to running it in a Windows 7 VM. This was done after getting blue screens from Windows when starting to the schematic capture portion of KiCAD. Instead of trying to diagnose the issue, I thought I’d try running the software directly on the macOS host and sure enough it seems the KiCAD developers have fixed most of the problems which made the port unstable.

The main improvement I’ve noticed is in the PCB design module. A fantastic new feature is the ability to drag traces around, which is easier to see then describe but basically traces can now push against each other to move them out of the way in an almost organic like way. It’s a less rigid (which is a pro and a con) way to lay out traces. This ability to drag traces around was a big help for the MPU and CPLD section, where the traces are closely packed.

So right now I am in the final stages of checking and double checking the schematic and board layout. Hopefully in about a week or so I will order the PCB.

In the mean time I’m continuing to print off the parts for my MPCNC. To close this post here is a picture of the parts I’ve printed so far:

I’m just over half way there, I reckon…