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.
This is the chip the Palm pilot used.
It is indeed. I wonder what other form factors it travels in. And where the debugging tool is found as that wasn’t indicated on the site.
I’ve got Palm Zire with some other DragonBall CPU and I’m interested if it is possible to boot it in this mode?
Yes. Check out http://www.uclinux.org it’s a little old, But it should still be compatible.
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.
make super hacking terminal once you’ve added a serial port (I have my dads Palm T2 so ideas please?
Spectre and Meltdown free.
Also MMU free! ;P
Only until the 68030
“Manhattan islands” PCB style in action.
This style of prototyping seems so odd to me… It feels messy for some reason.
Probably has advantages though….
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.
how do you cut the copper to isolate pads/traces of it?
You don’t, all the wiring is done point to point above the copper. You just glue stuff on and use it as a ground plane, usually.
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.
See https://hackaday.com/2012/07/20/cutting-islands-into-copper-clad-pcbs-with-a-drill/
or buy a Vector P138A pad cutter.
Good trick!
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
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 .
I’ve got on of Pete’s 68K boards sitting right in front of me. With OSK (OS9 for the 68K from Microware).
are there scans of schematics anywhere?
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
Nop was 0x4e71. 0x0000 should cause an unimplemented instruction exception.
http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf
0x0000 0x0000 (yes that’s two words) is ORI.B #0, D0
Would still function the same as a NOP as the addresses increases a word at a time.
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
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.
That is a cool hack – I guess a Z80 couldn’t be halted. I like these old tricks. Thanks for sharing that.
By adding flash and RAM you can run uClinux.
http://www.uclinux.org/ports/
http://www.uclinux.org/ucsimm/
“If you were alive during the 16-bit era”. What are these 16 bit devices you speak of?
80286 for a true 16 bit system.
68000 was a 32bit CPU with a 16 bit databus :)
And 16 bit ALU and datapaths.
16 bit implementation of a 32 bit ISA.
PIC24 and MSP430? ;)
Anybody know the link to the “DOS” UART monitor discussed in the very thin project log?
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.
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.