The Tiniest Working 68K System

68000 microprocessors appeared in the earliest Apple Macintoshes, the Commodore Amiga and Atari ST, and the Sega Genesis/Mega Drive among other familiar systems. If you were alive during the 16-bit era, there is a good chance that you will have owned a Motorola 68000 or one of its derivatives in a computer or game console. By the end of the 1990s it was clear that the 68K line had had its day on the desktop, but a new life for it at the consumer level was found in the PDA market. The first Motorola Dragonball was a 68000 series system-on-chip, and it was a few of these in a BGA package that [Plasmode] had in stock after ordering them in error believing them to be in a different package.

The Dragonball 68328 has an interesting bootstrap mode allowing it to run with no external ROM or RAM, and with only a serial connection to the outside world. Recognising this as having the potential for the smallest possible 68K system, he proceeded to make it happen with some impressive soldering direct to the solder balls of an upturned BGA package.

On a piece of PCB material are simply the 68328, a 32.768kHz crystal and capacitors, a MAX232 circuit for an RS232 serial connection, a reset button, and a power regulator. Using the Motorola DOS debug software which is still available for download after all these years, he was able to connect to his tiny 68K computer and run code. It’s not entirely useful, but of all the possible 68K configurations it has to be the smallest.

This isn’t the first minimal computer using only a processor chip and serial link, in the past we’ve shown you a PDP-11 in the same vein.

35 thoughts on “The Tiniest Working 68K System

    1. No. The palm pilot was the first plam, and didn’t contain such a chip.
      The DRAGONBALL is why palm had such a low price point. It integrated a processor, synth, serial, i2c, screenbuffer, LCD driver, etc… into a single component.

      1. Back in the late 70’s, DIP sockets often cost more than the chips that went into them. Micro pioneer Preston Jett told me his prototyping secret: Use an un-etched, copper-clad board. Glue the chips legs-up to the board, using heat-conducting cement. Wire the circuit pin-to-pin, using wire-wrap tool. The joint is probably far from gas-free as the sharp corners of true wire-wrap pins, but still not bad.

        The sheet of copper makes a great heat sink and also a ground plane. If you use a double-sided board, you can dedicate one side to ground, the other to +5 or whatever.

          1. The copper foil is quite soft so can be easily cut (or scored) with a box cutter. Once a parallel cuts are made, you can dig up the foil at one corner and pull off the strip of copper foil with a tweezers. For quad flat pack you can bend the ground lead down toward the copper ground foil and either solder directly to the foil or via a very short wire. I would make a parallel scores on the foil which acts as thermal barrier so you can solder wires to the middle of the copper foil. For the power leads, you solder a SMT capacitor standing on one end to ground foil (like a tombstone) and wire the VCC lead to the other end. Connect all VCC leads into a ring. You can create a VCC plane by glue the whole thing to a larger copper foil board and connect VCC to the larger foil board. See my other design (Tiny302) on copper foil board: https://hackaday.io/project/29476-tiny302

            Because it is point-to-point connections, there are very little cross talks. In the old days analog circuits are often prototyped on copper foil board and were very quiet. Put the designs on pc boards and the noise can become unacceptable.

  1. Byte had a book about the 68000, a collection of articles, some had definitely been in the magazine, but others maybe overflow.

    And there was an article about bootstrapping the 68000. Jam the data bus with a “NOP”, so the program counter would keep advancing, and thus you could fill memory directly.

    I’m hazy on the details of the article, because others had some similar things. There had been an article in Byte in 1978 or 80 about similarly bootstrapping the 8085, but it was more detailed, right down to carving up some circuit board to use with a stylus to enter data.

    Of course, one reason the 1802 was popular for building from scratch was that the CPU had a similar function built in, so you didn’t need to build a complicated front panel (legend had it that the Altair 8800 panel board was as complicated as the CPU board) or a monitor ROM.

    So the idea could have been done from day one.

    Don Lancaster used the same idea in his “Cheap Video” books to use the CPU to advance the program counter so RAM could be cycled through to output it to the monitor. He never left a hint of how the idea was more general. Once I saw the other material, I saw the connection, but I still don’t know if one influenced the other.

    Michael

    1. The 68000 was great for DIY because it was a static chip; you could run it at any clock speed, including zero,You didn’t even need a crystal — just hang an RC pair across the clock input.

      And yes: NOP was a 0x0000, so just tie all the data lines low, and the chip would happily run forever, cycling its way through memory.

      Peter Stark of SK*DOS designed a system just that way. He first ran the chip (with crystal) standalone. You could tell it was running by looking at the higher address lines.

      Next, he added the chip enable circuits. Again, scope the lines to verify the waveforms were correct.

      Finally, he added ROM and static RAM and a UART. He put a debugger in the ROM, so from there you could use the computer itself to complete the job. Then the dynamic RAM, disk controller, etc.

      A company in Atlanta called Peripheral Technology built a kit for it. The motherboard was AT-compatible, so you could use PC hardware — case, power supply, keyboard, disk controller — to make a complete system. Later, PT offered 68020 and 68030 upgrades. I still have all three .

          1. Pete Stark had a webpage, I didn’t check now to see if it’s still there. He might have material there.

            It was a long series in Radio Electronics, but I can’t remember when. So perhaps it was after the magazine changed to “Electronics Now”.

            The magazines are archived online, you just need the date.

            Michael

    2. The old DTACK Grounded approch is indeed simpler than even this thing however he’s qualified it with “usable” not sure it’s that useable but at least it talks to a debugger I suppose

    3. Jamming the bus with NOPs, while the PC keeps increasing, is how the ZX-80 and ZX-81 generated their video. When a video line had to be output, an interrupt would fire. The video processing circuit would then on one side start pushing NOPs into the processor, and on the other side steal the bytes that the processor was ‘reading’, and output that data serially (there’s a little bit more complexity to it, but this is the gist). It’s basically a way of doing DMA.

  2. Alpha and and high-end VAX microprocessors boot at reset by loading a serial EPROM into cache and jumping to it. On the VAXen, the serial EPROM pins become available as GPIOs once the EPROM has been loaded.

    For diagnostic purposes, the cache appears as a chunk of memory in I/O space.

    I once built an adapter that would allow me to plug an NV5+ VAX processor into an Alpha workstation. There were some unknowns involved, so I needed a way to test it with few resources. I wrote a FORTH system that lived within the cache and used the serial EPROM pins as a bit-banged console. It allowed access to main memory by predicting which cache line would be hit, moving the contents of that line elsewhere, performing the access, then restoring the cache line. In this manner, it was possible to test the memory interface without first knowing it would work.

    Turned out to be handy, because the NV5+ and Alpha 20164 are, in fact, only *mostly* pin-compatible. I had to do some gymnastics in the hardware to paper over the differences. In the end, I had an Alphastation 255 with a VAX processor that could prove it could touch all important address spaces (PCI, etc.). Sadly, the project was cancelled before it was turned into a product.

    But the upshot was that, like this 68000, I had a single-chip VAX (well, three counting the serial EPROM and RS-232 transceiver) in a nice little package that could do useful work with only power being applied.

  3. This is a great story!

    This is yet another example of why Forth is so useful for these types of tasks.

    Many x86 BIOS systems have had to do the same thing for a long time. I remember the Intel 486 programmers manual describing the tricks necessary to run out of cache. Still, even with a modern BIOS having all that FLASH, they still don’t stick a Forth with a serial console in there.

    It would be nice if all processors had a simple serial console built in (like the PDP-11). It would make debugging much easier.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.