Compared to a modern computer, you can't do a whole lot with with a 68K computer. But the knowledge that comes with it, makes it all worthwhile.

If building your own computer is a rite of passage, then Matt is well on his way. His Homebrew 68K computer is still in progress, but it’s a journey of exploration through the hardware that surrounds us. We had a chat to Matt about this fascinating process.

What made you undertake the process of building your own computer? Was it for understanding, intrigue or something else?

Intrigue would be an excellent word for it. I’ve been programming since my early teens, and for a long time I regarded both assembly language programming and hardware as dark arts: magic best left to wizards! Then sometime around six or seven years ago I tripped over Nisan and Schocken’s book, “The Elements of Computing Systems” (more information on this can now be found here). This takes you on a journey from logic gates through basic CPU design, all the way up to writing your own compiler and assembler. It took away a lot of the mystery, even if it was focused on a virtual computer. That got me far more interested in what was going on below the software level.

It’s an interesting world, and can make you a better coder! How did you get started?

The first thing I did was buy a couple of MC68000P12 chips from eBay, and then didn’t do anything else for a month or two while I worked out where to start. I read about other 68k RetroBrew projects and discovered that the book “68000 Microcomputer Systems: Designing and Troubleshooting” by Alan D. Wilcox is held in high regard, and managed to grab a copy through Amazon. I picked up a copy for around 40USD (although at the time of writing this, the cheapest copy is listed at 146USD). I read the first half of that book a couple of times, and then set about buying more hardware, namely some 7400 series chips, as well some EEPROM and SRAM chips.

That’s a great find. What will be the critical success point for this project?

I think I’ll call it a success when I have a custom PCB running with basic serial IO, allowing it to be used as a computer from a serial terminal on another machine. I’d love to get to the point of it having it’s own video output and connector for a keyboard, but I’m definitely regarding that as a future goal and not something I’m looking to achieve anytime soon. My spare time is extremely limited between work and young children, so I want to have a realistic goal for the time being.

Ah yes... forget work/life balance, it’s the hobby/spare time balance that’s difficult! For those that haven’t been down this path before, can you briefly explain what the end outcome will be? Are you just measuring pins, or do you have a more fancy approach to indicate that you’ve succeeded?

Right now I am measuring pins with a logic analyser in an attempt to add the SRAM to the system. The end outcome will be a machine you connect to from another computer, with a simple command line interface that will allow you to load programs over the serial connection, and then execute them and see the results. I’ve got a background in game development so some simple text-based games may well be on the cards.

That sounds great! Tell us a little about the main processor you’re using.

It’s a Motorola MC68000P12, which is the 12MHz version of the venerable 68000 with a 16-bit data bus. I’ve got a soft spot for the 68000 purely because it powered two of my favourite machines: the Atari ST and the Sega Mega Drive (it also powered the Amiga 500 and Apple Macintosh, as well as some other computers and arcade machines). A few years ago I finally got my hands on an Atari Falcon, which uses the later 68030 processor, and I used that as a good excuse to learn 68k assembly. I thoroughly enjoyed that and it’s hopefully given me the knowledge required to write my own programs for this computer if I don’t use C.

Ah Atari... What was the biggest hair-pulling moment during development? There’s always at least one!

After attempting to create the circuitry for SRAM for the first time (moving from a state where the CPU was correctly running a small loop from EEPROM), everything went haywire. I pulled the SRAM from the breadboard to see if it was contention on the bus but no joy. So I spent a few evenings trying to work out what was going on; my logic analyser was showing anything but what I expected. After a few frustrating nights I finally realised I’d transposed the address lines for the EEPROM while “refactoring” my board layout a little. Somehow I even checked continuity on the address lines one night and failed to notice they were hooked up backwards, because I was too busy making sure there were no breaks in the circuit. I find debugging code is often similar: you never check the simplest thing that could be wrong because you automatically assume there’s no way it could be wrong.

Yes - sometimes the best thing is a walkaway and return manoeuvre, that’s for sure. What have you learned so far about computing hardware that you didn’t expect to?

That everything has remarkable levels of tolerance. I hate to make those more familiar with hardware cringe, but for the most part I’ve ignored timing requirements, skimped on bypass capacitors (I only learned about those during the EEPROM programming), and I’ve generally gone with a “try it and see” attitude. So far, everything has pretty much just worked. One thing that makes complete sense, which I hadn’t anticipated, is that different components are designed to work with each other. My EEPROM chips work in an almost identical manner to the SRAM chips, and only simple glue logic is required to pull everything together. I was originally planning to use a CPLD to handle most of the logic, such as address decoding, but while it was super fun to play with, the cheap Chinese dev board I bought (an eBay special built around the Altera MAX II) has been relegated to providing my 5V power (it in turn being powered by USB) and the clock signal.

It’s true, many of these chips are exceptionally robust. What are you doing now with the computer?

Cursing at it for the most part! I kid, that was just yesterday! Today I’ve gotten back to being able to run code from ROM but with address decoding and the like happening. With some luck by the end of this week the RAM circuits will be working and tested as well.

Awesome - RAM is a critical stage to get working! What knowledge do you now have that would make it easier to approach this project a second time around?

I’m not sure there’s one key piece of knowledge I’ve gained; it’s more an understanding of how a whole (or as whole as it is right now) system fits together. I’ve been tackling a small piece at a time, but that’s meant it’s been more organic than by design for the most part. Perhaps doing a simpler project first, with an 8-bit processor and smaller busses would have prepared me a little more. One trap I definitely fell into was thinking that breadboards make things easy to change - sure, nothing’s soldered or held in place by a wire wrap nest, but when you’ve got so many wired on a board, some get buried, and then if you decide you’d have been better off with a core IC (such as a 64-pin DIP 68k CPU for instance) elsewhere, then you’re probably out of luck.

Are you still primarily focused on the 68k, or have you put it on hold, for something else? If so - give us all the details!

I’m pretty sure I could comfortably fill a 40+ hour week with my hobby projects, but right now this is my focus. Breadboard solutions are ephemeral by their nature so I don’t want to drop this until it’s working on a PCB. If I fail to do that, I just know I’ll have a very hard time picking it up again later down the line. Any software developer will be able to tell you that a five-minute distraction is more like a two-hour distraction: task switching is expensive when it causes you to lose track of your state of mind. This project is similar, just with longer time frames. My other “current” project is one that I’d put on hold for this. It’s a platformer game for the Atari STE, tentatively called “Dave the Dragon”.

Absolutely - i think we've all been guilty of having too many projects going at once, it's an industry hazard! But occasionally you get to circle back to an old project, and you have magically found the problem that caused you to put it on hold anyway!

All About The Eeprom

During the build of your computer, you became sidetracked with an EEPROM programmer project. Was this to directly benefit your 68k project, or intended for something else entirely?

It was for the 68k project. I’d been a little gung-ho in my Ali Express shopping while looking for EEPROM chips to use, and completely failed to check the compatibility of the cheap programmer I bought with the chips I wanted to use. The list on the page was huge so I made the assumption (yeah, I know) that it’d all be fine; naturally it wasn’t.

What are you using as the basis for your EEPROM programmer?

It’s an Arduino UNO that I got in a starter kit some years back. I’d done a few experiments with it but then never really found a real project. Programming the EEPROM chips seemed like a reasonably simple process judging by the data sheet, and I’d seen others do similar things online so I figured I’d just get stuck in and see if I could create a shield to do the job for me. It started life as a single EEPROM chip on a breadboard with a few wires to the Arduino and then rapidly took on a life of it’s own.

It’s fairly easy to find an EEPROM programmer. Was your approach cost-driven, or a quest for knowledge like the 68k?

A little of both. The programmers I could find that were compatible with the chips I bought (Atmel 32KB chips - AT28C256) were surprisingly expensive, compared to the one I’d already purchased. We’re only talking around 60AUD or so, but it seemed like overkill if I could learn something instead, and it seemed like a good excuse to do something that seemed “easy” in comparison to the more daunting 68k project.

What knowledge have you gained that will help you bring EEPROM to your 68k?

A surprisingly large amount. The first issue I hit was not having enough IO pins on the Arduino to be able to use much of the memory on the EEPROM chips. With a few control lines and the 8 IO pins taken care of I wasn’t close to having 15 free pins for the address lines. When you’re dealing with powers of two any missing pins on the top end (high address lines) are going to really hurt. From investigating what others had done (Quinn Dunki was a very valuable source of information), I discovered shift registers and got to know them, which has been handy because I use one of the same registers in the DTACK circuit for the 68k.

Bypass capacitors were also new to me. For those who don’t know, they’re capacitors you put across power pins on an IC to help soak up any voltage fluctuations caused by other ICs that are busy doing their thing. It turns out posting PCB designs online is a great way to get plenty of people pointing such omissions out to you!

That leads me onto the major part of the learning exercise: designing a PCB. I’d never really drawn up anything but simple schematics in my life (and then on paper), so I spent most evenings in a two-week period experimenting with different schematics and PCB design software packages. It seems everyone has their favourite software, and every piece of software has it’s own quirks. Some of the UI decisions completely baffled me, for instance, when looking at KiCad. EAGLE was something else I played with, but the first thing I used which I felt naturally comfortable with was DipTrace. It’s commercial software but with a free offering, subject to some limitations that I was never going to need (“All features and libraries, 300 pins and 2 signal layers, non-profit use only”). This could well become an issue with the larger 68k project, but I’ll deal with that when I get to it.

DipTrace not only seemed to have the smartest wiring tools in the schematic, but it also made it very easy to create a PCB layout from a schematic, as well as update that layout as the schematic changes. It’s got an autorouter but routing was something that had always fascinated me, so after five or six attempts I finally routed everything, and had something to show to the world for feedback. After a few tweaks (bypass capacitors *cough*) I decided it was ready. I should definitely have done more double checking, but I was getting a bit excited and wanted the boards made. DIY solutions seemed a bit messy and fussy, and I found I could get 10 boards created and delivered by PCBWay for 16USD, which seemed too good to be true. I uploaded my Gerber files (something else I learned about) and waited. I received an email a day later to say I hadn’t included a drill file, which is basically a map of all the holes that need to be drilled into a PCB so that you can mount components. After sending that off I eagerly watched the manufacturing progress updates and after around two weeks a package arrived with my boards. I soldered one up that evening, which was another first, and discovered that roughly eye-balling the space required for a ZIF socket on the PCB layout wasn’t the smartest decision; everything fit but to say it’s cosy would be an understatement!

If that’s the worst hiccup then we’d still call it a success! If you started it from scratch, would you still approach it the same way?

That’s hard to say. If I did need another programmer I may just buy one as the overall programming process would be smoother - simply providing a binary file to a prebuilt piece of software is a bit more pleasant than my solution. Right now the binary for the ROM gets built into the Arduino code, and then the “interface” consists of a serial IO based menu, so that you can send commands to the Arduino from a PC. All that aside, if I knew I’d learn as much as I did this time around, then I wouldn’t hesitate to get stuck in. Rabbit holes can be pretty valuable sometimes.

That’s awesome. We wish success as you finish off your project!