Does this project spark your interest?

Become a member to follow this project and don't miss any updates

MC68000 Computer

Similar projects worth following
This project is in this list
Browse all lists »

This project was created on 12/20/2013 and last updated a month ago.

The design and construction of a hombrew computer based on the Motorola 68000 CPU

This project is a homebrew computer based on the Motorola 68000 CPU. Design includes four megabytes of RAM, 128kB of ROM, Something for video, two serial ports at 9600 baud, and eventually networking and a hard disk.

The purpose of this computer is two-fold: To show it's really not much harder to build a 16-bit homebrew computer than it is to build an 8-bit homebrew computer, and to build a server for Hackaday's retro site.

  • 2 × 28C256 Content/Electronic Components/Semiconductors and Integrated Circuits/Memory ICs/PROMs, OTP PROMs
  • 8 × AS6C4008 Content/Electronic Components/Semiconductors and Integrated Circuits/Memory ICs/Static RAM (SRAM)
  • 1 × MC68000 Content/Electronic Components/Semiconductors and Integrated Circuits/Microprocessors, Microcontrollers, DSPs/Microprocessors (MPUs)
  • 2 × 6850 ACIA Content/Electronic Components/Passive Components/Inductors, Chokes, Coils and Magnetics/Current, Voltage and Power Transformers
  • 1 × A Much better idea for video

Project logs
  • You can refactor hardware, right?

    10/29/2015 at 17:14 2 comments

    I'm in the middle of a few free days right now, and I figured it's time to take a look at this project. Things aren't good. Let's go over what's wrong with it:

    • It's not done
    • It's not even close to being done
    • The 'not being done' is mostly a result of using a backplane design, using discrete logic, and using extremely old and expensive parts.
      • Yes, the way we do things now is better than the way things were done. Imagine that.

    So, how am I going to fix this? Rapid iteration. I'm figuring every month I can dedicate 10-20 hours to this project, and going by how long it takes Seeed studio to ship some boards to me, that's just about right for a single hardware revision. Therefore, this project is getting a complete refactoring. I'm going to design monolithic boards (with *everything* on one board - ram, rom, whatever), and get as much as I can working. Iterate on that until it works, and add more stuff. You never expected me to be done with this, did you?

    Another factor that has led to this project being stuck in quicksand is the use of 5V parts and discrete logic. This was reasonable for 1982, but it ain't the 80s anymore. It isn't even the 90s. CPLDs are the way to do this, and memories are larger and cheaper if you use a 3.3V part. What does that mean?

    The Motorola MC68SEC000.

    The *SEC* part is a very late evolution of the 68k family; it's a static design, so it will work even when the clock doesn't. It works at 3.3V, opening the door to some really great parts and programmable logic. It's not available in a DIP part, though, leading me to this problem:

    That's a 64-pin TQFP. I can solder that, but it will most likely mean boards with more than two layers in the future. I can deal with that.

    With a new part that I created in Eagle, that means I need to verify that part is correct. This means ordering a board with just this package on it, and I think I can do something cool:

    That's a board with the *SEC* package just freerunning, with some LEDs attached to the address lines. It's effectively a binary counter in a very small package. And to indulge the racists on, yes, I can solder CPUs.

    With such a small board, I think it's time to go over the minimal configuration of a 68000 from one of the best resources around.

    Tie to ground:

    • DTACK

    Tie to VCC:

    • /BGACK
    • /BR
    • /VPA
    • /BERR
    • /IPL2
    • /IPL1
    • /IPL0

    Ignore completely:

    • FC0
    • FC1
    • FC2
    • /BG
    • /VMA
    • E

    Tie together

    • Reset & Halt

    The *SEC* part, along with the *EC* parts have two additional pins: /AVEC and MODE. /AVEC is an extension of the IPL... pins, so we can just tie that to VCC. The Mode is a bit different, and something that's incredibly valuable in the new design:

    Mode (MODE):

    The MODE input selects between the 8-bit and 16-bit operating modes. If this input is grounded at reset, the processor will come out of reset in the 8-bit mode. If this input is tied high or floating at reset, the processor will come out of reset in the 16-bit mode.

    With one part I'll be able to test both 8-bit and 16-bit data busses, something I've struggled with in finding a proper development environment for this computer. That's cool, several problems down.

    As for now, the next update will be a blinkey thing that is a complete waste of transistors. That's cool, though: it's just to verify the part.

  • A Long, Long Overdue Update

    04/25/2015 at 06:07 2 comments

    Quick story. I brought this computer to the Vintage Computer Festival 9.1 last year to show Bil, Dave, and all the other cool people at the event. At the time, I was freerunning the processor, watching the blinkenlight count up. Great stuff, and proof that the CPU works.

    A few hours into the show, the CPU board stopped working. It just wouldn't free run. No idea why, as I was able to get the board working by wacking it against a table once I got home.

    Then the Hackaday Prize happened, and then the summer con season happened. I've been working on this off and on in the meantime, but no *real* progress. I made a better RAM card (more on that in a bit), but it's still a bit away from sending characters out over the serial port.

    Since then, I got the wire-wrapped CPU card free running again, and I decided to take it to the Vintage Computer Festival X last weekend. When I pulled it out of the box and turned it on.... nothing. This computer hates VCF for some reason.

    Therefore, I have decided to build a proper CPU PCB. It's just buffers, the CPU, a clock, and some blinkenlights:

    And I have to route that before I leave my house for a month for con season. Great.


    I had a front panel milled out of a big ass piece of aluminum. Here are the videos of the milling:

    And a picture of the front panel:

    That panel was made by the SeeMeCNC guys when I was up there for the Midwest RepRap Festival. I traded a gigantic (5 foot x 8 foot) hackaday flag - made by me - for the CNC work. All the relevant files are up in the Git.

    Front panel not included. I'm moving the reset circuitry to the front panel, btw. Another board to build.

    Four megabytes of RAM

    I hated the wirewrapping on my RAM card. The initial plan for all of these cards was to prototype them with wire wrap, then build a board. I met myself halfway on this one.

    That's the layout for the RAM chips, eight 4-Megabit chips. You'll notice there is no control circuitry on this one; there's a reason for that. I might want to change the control circuitry to a PAL or something down the line. Easiest solution is to make a proper layout for the RAM chips themselves, break out the data, address, and control lines, and leave everything else up to wirewrapping. Easy enough.


    Since I'm doing all of this from scratch, It would be nice to have a development tool.

    That's the Motorola Educational Computer Board, the official 68k trainer from 1981. It works, I have it plugged into a terminal, and it has a great monitor in ROM. I'll be using this heavily once I get a few characters spitting out of the serial port of my project.

    Picked that up on eBay for $40, btw.

    Also on the eBay Front...

    I have most of DTACK Grounded.

    DTACK Grounded. the journal of simple 68000 systems, was a newsletter put out by [Hal Hardenberg] on how to design a simple 68000 system.

    Most of DTACK grounded covers the development of a 68000 add-on card for the Apple II and a BASIC interpreter. It's good writing, and the issue ever 68000 homebrew wants to read - number 6 - tells you exactly what you need to leave out, what you need to leave in, and what pins to connect to where.

    If you want to read these for yourself, here you go.

    I did pick something up at VCF...

    That's a 12MHz 68000. Five dollars. It's an actual Motorola part, so this is what I'll be using from now on. I don't know if I'll be running it at 12MHz; I specced all my decoding logic for 8MHz. I'll try it - it's just changing a crystal - but I don't expect this computer to run at 12MHz.

    That's it for this update.

    I'm leaving for NYC next weekend, and LA a few days after that. I won't be home for a month and for some reason that means no Windows, and no Eagle. Don't read too much into that last sentence.

    I need to get this CPU card done and sent off to fab. It's exactly like the earlier wire-wrapped CPU card, only this one hopefully won't fail all the time.

    So... yeah... it's been embarrasingly long between this update and the last, but hey, I've been busy, and technically, I have...

    Read more »


    03/26/2014 at 23:12 0 comments

    This is something I've written about in a front page Hackaday post, but I think it's time to go over a little more of the theory of what I'm doing here. First, a video:

    This is called freerunning the processor. Basically, it executes one instruction, the program counter is incremented, the address is increased by one, and the CPU just sits there, doing nothing, cycling through its address space. Attach a few LEDs to the address pins, and you have an incredibly complex binary counter, also known as blinkenlights.

    That's the simple explanation. It's a fair bit more complex in practice. I need to tie a few pins to +5 volts, and ground DTACK. Oh, what about the instruction to freerun the processor? NOP, right? NOPe.

    When the 68k first resets, it reads the program counter vector. The program counter vector must be an even address, and the opcode for NOP is $8E71. See that one at the end? That means NOPping the CPU from boot would create an illegal address exception. Then bad things happen.

    So, I need an instruction that does nothing, and is even. Inclusive OR Immediate (ORI) does this. Specifically OR.b #0,d0. Bonus, this instruction in hex is $0000, or all zeros. All I need to do to freerun the processor is ground all the data lines.

    My first go at freerunning the CPU only used one LED. This LED was tied to the A20 line through an inverter. I hate to waste the five extra inverters on that chip for a single LED, so I added another three.

    Now I have status lights for the top four addresses in the computer. Since I'm putting the ROM at $FF0000, the serial port at $FE0000, the video peripherals at $FD0000, the microcontroller at $FB0000, I have a graphic representation of what the CPU is doing with all its peripherals. That's pretty cool. Useful blinkenlights.

View all 8 project logs

Enjoy this project?

Adam Vadala-Roth wrote 10/30/2015 at 03:47 point

is this the project you had Steve machine a part for you back in Indiana at MRRF? 

Are you sure? yes | no

netbeard wrote 08/19/2015 at 00:35 point

Brian, I'm curious, does the 68k HAVE to have RAM at $000000 after boot?  Both the Sega Genesis and the Neo Geo (both 68k based systems) have ROM mapped there.  Is it just a matter of being able to rewrite the vectors during runtime?  Why not have the vectors hard-coded stored in ROM, pointing to a location in RAM, and have a JUMP or CALL there in RAM?  The only downside I can see is the increased latency, but it would only be a few cycles.

Are you sure? yes | no

jaromir.sukuba wrote 02/14/2015 at 13:05 point

The last project log is 11 months old now (the time flies, I feel like I signed up the projects page yesterday...). Do you plan any updates on this project? I believe I'm not the only one who likes it.

Are you sure? yes | no

CompuCat wrote 02/15/2015 at 17:16 point

Agreed-I quite enjoy reading about homebrew computers (such as this one and Quinn Dunki's Veronica) and would love to see an update soon. Wasn't this going to be used as the Hackaday Retro Edition server someday?

Are you sure? yes | no

Benchoff wrote 02/15/2015 at 20:14 point

It still will be, and there will be an update "soon". I know I haven't been working on this as much as I should, but <i>holy crap</i> getting switches lined up with a milled front panel is a pain in the ass.

I'm going to look for some way to automate that in the future.

Are you sure? yes | no

ww6l wrote 12/05/2014 at 18:43 point
68020 has cache - is way faster than 68k
68030 has comm + more i/o - could be a better choice

Are you sure? yes | no

Chris Arena wrote 09/29/2014 at 02:53 point
On the RW strobe generation circuit sketch, something looks wrong.

Are you sure? yes | no

Chris Arena wrote 09/29/2014 at 02:29 point
In addition to the reset manager/boot instruction installer, it could provide access to the peripherals (i2c, serial, spi) that it has -- possibly requiring a separate part.

Are you sure? yes | no

Chris Arena wrote 09/29/2014 at 02:23 point
consider using a atmega or pic as your reset handler/boot vector installer. With address lines pulled LOW, while the processor is reset and in HI-Z state, let the atmega328 access the bus to put an instruction there, or a bunch of them. then the atmega gets off the bus, and releases the reset.

How about using IS66WVE4M16BLL for memory? Dense and cheap, but BGA. It looks like it was made for the 68000 bus.

Are you sure? yes | no

Benchoff wrote 09/29/2014 at 02:36 point
Oh, damn. That memory looks great. 3.6V, but that's what level shifters are for. TQFP, too.

I have the reset going to all cards now, so having a micro poke the address lines on reset is a possibility in the future. I might do that when it comes to implementing other devices.

Are you sure? yes | no

Techokami wrote 09/18/2014 at 19:48 point
This is very awesome! I'm actually in the planning and design phase of my own 68k microcomputer project. Though I have to point out, a TON of images in your posts are broken. Can you please fix them up?

Are you sure? yes | no

kurq wrote 04/19/2014 at 04:14 point
It would be interesting if you get a cpu/bus performance like the fastest 68000 computer ever: The Sage.
Just Google it, you will find it was 68000 computer designed for efficient usage of its speed.

Are you sure? yes | no

tomcircuit wrote 03/09/2014 at 20:12 point
The 6850 is so braindead... ugh... I'm happy to donate one or two 68681 and/or 68901 chips to your project. I've got at least a dozen of each scurried away... I'm sure I've got one or two 68230 as well.

As much as these 68xxx chips are convenient to use with the async bus of the 68K, I've come to the conclusion that the only real reason that I, personally, would ever use most of these devices is for software compatibility with some older system. The state logic required to interface a synchronous bus peripheral device (i.e. without DTACK) to the async 68K bus is straightforward and easy enough to implement in a GAL or CPLD.

I think the exception (pun intended) I would make to this statement is that the 68901 in particular makes a fine vectored interrupt controller. I have no desire to re-invent THAT wheel...

Are you sure? yes | no

Benchoff wrote 03/10/2014 at 16:50 point
You're right that the 6850 is dumb. I'd really rather not bother with DTACK and 6800 stuff. I'm kinda in a bind with this project, though: I want to make it as simple as possible, but also give people a chance to replicate it. So far, all the chips can be ordered off jameco (with the exception of the 68000 and V9938/V9958). The other 68XXX chips... they're hard to find.

If you want to donate something, email me at (my last name) Give me your address and I'll send out a T-shirt and some stickers for your trouble. I'll also promise to use the '681... after I've brought the system up with the 6850. Beauty of the backplane, I guess.

Are you sure? yes | no

lennart.lindell wrote 02/20/2014 at 23:16 point
Here is a diagram.

The idea is that the ROM and not the RAM is mapped at addr 0 at reset. When the ROM is addressed at its runtime address the RAM is mapped instead at addr 0.
The ROM is in this picture mapped at $500000-$5FFFFF, it is better to move that to a high address.

Are you sure? yes | no

lennart.lindell wrote 02/20/2014 at 20:03 point
Try to find a 68681 DUART instead of the 6850. And a 68901 that includes UART, timer and an 8-bit port. You need a timer don't you? ;)
Move peripheral and ROM to as high address as possible to get continous RAM from address 0 and up.
And I have some comments how to simplify the ROM/RAM address decoding:
Use a simple flip-flop instead of the counter at reset and see comment in text about RAM.
I had better draw a figure than explain it in text.

Are you sure? yes | no

Benchoff wrote 02/20/2014 at 22:51 point
I was originally planning on using the Motorola 68k educational/dev computer from 1979 as the ROM monitor, thus necessitating the use of the 6850. Guess I'll just roll my own with the 68681.

You're completely right about the RAM /BOOT decoding. I'll get that in my notebook, and eventually on a project log here.

You're always free to put a diagram on imgur and post a link in a comment.

Are you sure? yes | no

wrm wrote 03/12/2014 at 09:34 point
That... is clever. I also used the counter-based system, it comes straight from Motorola AN-897, but I admire this one.

There's Pete Stark's HUMBUG and also TUTOR/TUTORNEW out there in source format, they work with the Quelo assembler (HUMBUG needs a bit of a massage). They both supports the 68681.

With hindsight I would also have mapped my ROM right at 0x00FFxxxx to keep RAM contiguous. It's easier to fill up a 16 M memory space these days than it was back in '87...

Are you sure? yes | no

Similar projects