Hackaday 68k: Blinking An LED


Time for another update for the Hackaday 68k, the 16-bit retrocomputer developed on Hackaday to show off both our love for vintage hardware and our new project hosting site. There’s still invites to be had, people. Get ’em while they’re hot.

This post is going to cover exactly how complex a simple 68000 system is. The answer is, “not very.” A simple 68k system is at least as simple to design than some other homebrew systems we’ve seen around here. Yes, a 16-bit data bus means there’s more wires going everywhere, but like she said, just because it’s bigger doesn’t mean it’s harder.

There is some progress to report on the construction of the Hackaday 68k. The processor has been verified as working with a blinking LED. It’s the ‘Hello World’ of computer design, and it’s at least as complex as blinking a LED with an Arduino.

You’re gonna want to click that ‘Read more’ link.

The Journal Of Simple 68000 Systems

At least half of the purpose for this project is to demonstrate the 68000 is well suited – simple, even – for a homebrew computer project. The homebrew systems that infrequently hit the Hackaday tip line are usually based around the 6502 CPU, or at the very least something in that family. Now, how do we compare a simple 6502 and 68000 system? How about describing a simple system with both chips?

Building a simple 6502 system

For a simple 6502 system, you’ll want the 6502 itself, some RAM, and an EEPROM. Let’s just say we’ll use a 62256 SRAM for the RAM, and a 28256 EEPROM for the ROM. Wire up the RAM starting at $0000 and make sure you have some of the EEPROM at $FFFF. A few NAND gates will do for the logic glue. Ground the A14 pin of the RAM, and you’ll have a basic system with 16k RAM, 32k ROM, and a lot of space to put in any peripherals.

Throw in a 6551 ACIA and you have a serial port. With a little bit of glue logic and a MAX232 chip, you can make a simple 6502 system that’ll run BASIC. Put a pin header on the 16 address and 8 data lines and you have an extensible system using seven chips:

  • 6502 CPU
  • 28256 EEPROM
  • 62256 SRAM
  • 6551 ACIA
  • MAX232 serial thingy
  • 74HC04 and 74HC00 logic ‘glue’

Wiring these up involves using the address lines for decoding, the R/W and Phi2 lines for memory control, and shoving a clock signal and reset circuit in there somewhere. You’ll need a crystal, some caps , a few resistors, and a reset button, but there you have it: a simple 6502 system. You can build this on a breadboard in a weekend. No. Big. Deal.

Building a simple 68000 system
The pinout for the 68k. You don't even need most of these pins.
The pinout for the 68k. You don’t even need most of these pins.

“But the 68000 is so much more complex!”, you cry, “There’s more pins! Sixteen of them, and that’s just the data lines! What the hell is BGACK?” I’m not saying you’re wrong, but I do choose to ignore you. It’s actually very easy to construct a simple 68000 system, if you know what pins to ignore:


DTACK is a product of very small and slow memories available in the late 70s. The idea behind DTACK was to have the RAM (or ROM, or whatever) acknowledge it got the required data off the data bus. If the RAM (or whatever) didn’t put this pin low in time, the CPU would enter a ‘wait state'; basically the 68000 would just sit there until the RAM caught up.

Now, with fast, huge SRAMs and modern components, you don’t have to worry about this. Ground DTACK and you’ll be fine. Do your calculations for the timings, but you’ll be fine.

BERR is the Bus Error pin, telling the CPU something is wrong with a MMU, there’s a “non-responding device”, or something else sufficiently complex that it shouldn’t be included in a minimal system. Tie this pin to +5 V.

  • Bus Arbitration Control; /BR/BG, & /BGACK

These pins are for DMA. We’re doing a simple system here, so no DMA. Tie BGACK and BR to +5 V, and ignore BG. Done.

  • Interrupt Control; /IPL0, /IPL1, & /IPL2

Interrupts? Again, we’re doing a simple system with some RAM, ROM, and a serial port. Tie these to +5.

  • M6800 Peripheral Control; E, /VPA, & /VMA

The old Moto engineers that designed the 68000 were extremely cool and gave 68000 system designers a way to interface the old 6800-series parts – ACIAs, display processors, the RIOT, PIAs, floppy disk controllers – to the 68000. These pins are how you do it. Are we using any of these parts? No? Good. Tie /VPA to +5 and ignore /VMA and E.

  • Processor Status Pins; FC0, FC1, & FC2

These pins tell the rest of the system if the CPU is currently in user or supervisor mode, the kind of stuff that would be handy for an MMU to have. Are we using an MMU? Then ignore these pins.

So, where does that leave us? We have 16 data pins, 23 address pins,, and a few others: We can tie Reset and Halt together. The asynchronous bus control pins, /AS/UDS/LDS, & R/W are all that’s needed to do a proper memory decoding and control.

How does that compare to a 6502? With the 8-bit chip, you’ll need to use the R/W pin to tell if you’re reading or writing, and the Phi2 pin on the 65xx is analogous to the /AS pin on the 68k. Really, if you design something with a 68000, the only real difference between it and an 8-bit chip are the /UDS, & /LDS pins, and they’re only there for accessing either D0-D7 or D8-D15.

A chip count for the 68000? You’ll need a CPU, two 8-bit RAM chips, two 8-bit EEPROMs, some sort of ACIA, and a bit of glue logic. You can do that in a dozen chips, max. It’s a lot more wires or traces between chips, but that’s neither here nor there.

So there you go. A reasonable case for the 68000 not being overly complex for a homebrew project.

Blinking A LED

The ‘Hello World’ of computer design is freerunning the processor. All this means is to get the CPU cycling around its address space with an instruction hardwired onto the data pins, attaching an LED to one of the higher address pins, and turning it on. The LED will blink depending on the clock speed and what pin the LED is wired up to. Here’s the video:

That’s the 68000 with the all the data pins tied to ground,  the /AS/UDS/LDS, & R/W pins ignored, and a Maxim DS1813 reset chip to handle the power-on and push button reset. I’m running it with a 4MHz oscillator. Anyone care to guess what address pin that LED is tied to?

I would like to note that since the 68000 has 68,000 transistors, it’s still possible I’m using fewer transistors to blink a LED than I would with an Arduino. If anyone from Atmel has a more precise count for the number of transistors on an ATMega, drop a note in the comments.

What’s Next

Unfortunately there’s a rather large gulf between blinking an LED and the next, “look what I did!” post. There’s a lot of thought that goes into address decoding for the RAM, ROM, and peripherals, and a shocking amount of work that goes into wirewrapping these chips together. Here’s the current state of the RAM board:


That’s eight 512k x 8 SRAM chips, with the data and address lines all wired up. Blue is data, green is address. I’m not quite sure how long it took me to wrap all those pins, as I’m measuring the time in units of Deep Space Nine episodes. I can tell you that wirewrapping, DS9, and a six-pack is the closest I’ve come to bliss.

For the next post, I’m going to go over the address decoding and memory control logic for the RAM, ROM, whatever I’ll be using for a serial port, as well as the bus transceivers. Then I’ll actually have to wrap all these circuits up; not a quick job. A little code burned onto an EEPROM, and then I’ll actually have something to show off. It’ll be awesome.

Until then, you can check up on my progress on Hackaday Projects.

46 thoughts on “Hackaday 68k: Blinking An LED

    1. The LED part is only a milestone. It proves that the system can run the code. Next he will start making more and more complex programs, and with enough time and skill he can even create a x86_64 emulator and run Windows 8 on this system. And before crying “impossible”, ask Google about the guy that runs Linux on a ATMega1284p…

      If you want a simple circuit, you don’t even need a 555 to blink a LED. Only a battery and a LED…

    2. Even less, Mr. Smarty Pants… a LM3909, a cap and the LED is all you need. I think that using the 68K might be just a little bit more flexible for doing other tasks though. ;)

      1. NOW you’re talking…ahh the good old LM3909! Back in the day I made a few of these for friends to install in their cars as fake alarm indicators. I see it’s still available too, there are a few for sale on Ebay.

      1. Plus there are LEDs with chips built in to do the blinking (practical for simplifying electronics, but takes the fun out of programming). More importantly, this 68000 project is good to follow to see where it takes us!

  1. _The pinout for the 68k. You don’t even need most of these pins._

    Uh…yeah, you probably *do* want to connect all the pins. You’ll need to decode the upper address pins and there are some fiddly bits to getting the correct bits onto the data bus at startup.

    VPA# = Valid Peripheral Address
    VMA# = Valid Memory Address

    DTACK# = Data Acknowledge, handy if you’re trying to access DRAM during a refresh cycle or shared memory while another device is accessing it.

    The 68K is a very nice processor to work with. Use a small CPLD to make the bus protocol a bit easier to work with (and as a bonus, it can handle putting the right values on the data bus after RESET…I can’t remember the details, but ISTR things work out easier if you temporarily remap the ROM from high address space to page 0)

    1. As things progress? No. A kit would be stupidly expensive in its current form. Just as an example, I have $40 in RAM chips alone. A simple part substitution – going from 8-bit wide SRAMs to 16-bit wide SRAMs – would cut that cost in half. Using 30-pin or 72-pin SIMMs would probably be even cheaper.

      A kit after it’s done (or even close to being done)? Maybe.

      1. I agree; a kit would be silly. The fun part of designing a computer is actually designing the computer. Otherwise you might as well just buy a Raspberry Pi and run a 6502/Z80/68k emulator.

        As for memory, SIMMs use DRAM, not SRAM, so while cheaper, you’d have to design some kind of controller to refresh it; furthermore, they use much slower RAM than what you’re using, so depending on your clock speed, you might have to use /DTACK, complicating things more.

  2. or.b #0,d0 ;)

    Nice so far! Keep that opcode, when it’s time to troubleshot the address decoding.
    Remember the HCF opcode (Halt and Catch Fire) on 6803, probably implemented for troubleshoting. The processor starts counting on the address lines. Then you hanged the oscilloscope on A15 and on the different chip selects. Maked it easy to find faults.
    By the way, there was no problem with fire…

    1. Oh, I know that’s going to be handy in the future. I actually put all the data lines on a pin header with a hacked up female socket adapter for that opcode. Plug it in, free run. Take it off, normal CPU.

        1. $4E71 is indeed NOP, but it’s no good as a free-run opcode. It’s odd (LSB=1), so when the 68000 resets and fetches the vectors for startup, it gets an odd PC and SP. This will immediately cause an Address Error, and we’ll get nowhere. PC on a 68000 is always even, so a free-run opcode must be even (LSB=0).

      1. Or you can wire that using SIP resistor packs as pull-up/pull down so that the undecoded area of memory would have a known opcode value. Want to check those address lines, pull off /AS and the entire memory space is filled with that value.

  3. In the category of keeping it simple, it is possible to simplify the address decoder.

    If you used a MC68010 you could put the ROM permanently at address 0x000000 because it has a vector base register that allows for relocation to RAM.

    Or there are flash memory devices that are pin compatible with the 512K SRAMs and can be programmed in system. Changing the vectors is a bit of a hassle but not too difficult. Jumpers on a couple of pins would allow you to install regular EPROMs for initial code development.

    Either way you can eliminate the remapping of the memory at reset.

  4. Is there going to be a post on every five minutes worth of progress on this?
    Getting a basic system with rom, ram,UART and glue should be about a days work..
    If you haven’t got a working tool chain then getting a hello world running is probably another day.. Point being you should be able to get a hello world running pretty fast and that would make a decent article (from nothing to running code). When you get to messing around with video hardware etc that will take multiple articles to detail. I suspect like most projects of this type work will seriously slow down or totally halt at that point.

    Free Hint: if you use a cpld in there you can control its pins via JTAG to write flash or a bootloader into SRAM.

    1. I’ll second this request. I used to do a lot of wire wrap stuff in college, but that was covered by tuition. Since then, I haven’t done much with it because the supplies are so much more expensive than prototyping with anything else. If anyone knows a good supplier, please let me know.

      The project I did in college was similar to this, but I was using an 8088 processor. As far as I can recall, there were about 1000 or so connections that needed to be made for even the basic system to boot up. I didn’t do any drinking or watching Trek, either – one wrong connection could take hours to track down.

      I’m looking forward to reading more…

  5. I didn’t read all the comments on this project, so forgive me if this has already been mentioned…

    When the 68k was the hottest chip you could find, there was a publication aptly called “DTACK grounded”, which discussed the hardware and software aspects of building simple 68k-based systems. An archive is available at http://www.easy68k.com/paulrsm/dg/dg.htm

    Btw., in order to reduce the number of external memory chips you could use a 68(EC)020, which supports external 8 bit wide memories IIRC.

    1. B.b.but: You need the DTACK to program the old 27xxx EPROMS …. one used to map the EPROM into memory somewhere convenient, then hook a timer to the “CS” so when the EPROM is accessed, DTACK is held low for the 50 ms or so it used to take to write a byte. Then programming an EPROM is basically a very slow block copy.

      That was back when programmers were really expensive …

    1. Some of the larger STM32 microcontrollers (ARM Cortex M4) feature an external memory bus. A cheap starting point would be ST’s STM32F429 Discovery board, which also features 8 MB external SDRAM and a QVGA colour touch screen – all for about 30 Eur. The controller itself is packaged as TQFP144 which requires some advanced soldering skills. I’m not aware of any current DIL RISC CPUs that provide an external memory bus.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s