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.
[MmmmFloorPie] revived an old project to create the retro mashup of a 6845 CRT controller and a modern Arduino Uno. When it comes to chips, the Motorola 6845 is the great granddaddy of Cathode Ray Tube (CRT) interfaces. It was used in the IBM Monochrome display adapter, the Hercules graphics controller, CGA, Apple II terminal cards, and a host of other microcomputer and terminal systems.
Way back in 1989, [MmmmFloorPie] was a senior in college. His capstone project was a 68000 based computer which could record and playback audio, as well as display waveforms on a CRT. The CRT in question was ordered from a classified add in Popular Science magazine. It was a bare tube, so the heavy cardboard box it shipped in was repurposed as a case.
Fast forward to today, and [MmmmFloorPie] wanted to power up his old project. The 68000 board was dead, and he wasn’t up to debugging the hundreds of point to point soldered connections. The CRT interface was a separate board including the 6845 and 32 KByte of RAM. It would only take a bit of hacking to bring that up. But what would replace the microprocessor?
Continue reading “The Modern Retrocomputer: An Arduino Driven 6845 CRT Controller”
[Jeff Tranter] has done a number of retrocomputing projects. But he wanted to tackle something more substantial. So he set out to build a 68000-based single board computer called the TS2 that he found in a textbook. He’s documented it in a series of blog posts (about 30 posts, by our count) and a video that you can see below.
The 68000 had a very rational architecture for its day. A flat memory space was refreshing compared to other similar processors, and the asynchronous bus made hardware design easier, too. While most CPUs of the era assumed bus devices could perform their service in a fixed amount of time, the 68000 used a handshake with devices to allow them to take the time they needed. Most other CPUs had to provide a mechanism for a slow device to stall the bus which was complicated and, in many cases, less efficient.
Continue reading “An Old 68000 SBC is New Again”
If we have to make a list of Projects that are insane and awesome at the same time, this would probably be among the top three right up there. For the past few years, [James Newman] has been busy building Megaprocessor – a huge micro-processor made out of transistors and LED’s, thousands of ’em. “I started by wanting to learn about transistors. Things got out of hand.” And quite appropriately, he’s based out of Cambridge – the “City of perspiring dreams“. The Why part is pretty simple – because he can. We posted about his build as recently as 10 months back, but he’s made a ton of progress since then and an update seemed in order.
How big is it ? For starters, the 8-bit adder module is about 300mm (a foot) long – and he’s using five of them. When fully complete, it will stretch 14m wide and stand 2m tall, filling a 30 sq.m room, consisting of seven individual frames that form the parts of the Megaprocessor.
The original plan was for nine frames but he’s managed to squeeze all parts in to seven, building three last year and adding the other four since then. Assembling the individual boards (gates), putting them together to form modules, then fitting it all on to the frames and putting in almost 10kms of cabling is a slow, painstaking job, but he’s been on fire last few months. He has managed to test and integrate the racks shown here and even run some code.
The Megaprocessor has a 16-bit architecture, seven registers, 256bytes of RAM and a questionable amount of PROM (depending on his soldering endurance, he says). It sips 500W, most of it going to light up all the LED’s. He guesses it weighs about half a ton. The processor uses up 15,300 transistors and 8,500 LED’s, while the RAM has 27,000 transistors and 2,048 LED’s. That puts it somewhere between the 8086 and the 68000 microprocessors in terms of number of transistors. He recently got around to calculating the money he’s spent on this to date, and it is notching up over 40,000 Quid (almost $60,000 USD)! You can read a lot of other interesting statistics on the Cost and Materials page.
Continue reading “Megaprocessor is a Macro Microprocessor”
From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.
The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.
In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.
Continue reading “Winning the Console Wars – An In-Depth Architectural Study”
We’ve been lurking over at Big Mess ‘o Wires as [Steve] geared up for his 68000 computer build. One of his previous posts mentioned a working breadboard version but we figured it would be a ways off. Surprise, he’s got it working and what you see above took just 6 days of “occasional work” to get running.
The chip in use is actually a 68008 but we remember reading that he does plan to migrate to a 68000 because this one lacks the memory pins to address more than 1 MB of RAM. The trick here was just to get the thing running and he made some common choices to get there. For instance, he grounded the /DTACK in much the same way [Brian Benchoff] explained in his own 68k build.
We’re not sure if his address decoding was a time saver or not. If you study [Steve’s] original planning post you’ll learn that he’s going to use programmable logic to handle the address decoding. But above he wired up 74-series logic chips to perform these functions. On the one hand you know your Hardware Description Language isn’t the problem, but did you terminate one of those wires where you ought not?
Additional tripping points include a bouncing reset pin. Looking at that we’d tell [Steve] there’s a problem with his chip, except that this was his first thought as well. He went the extra mile by building and testing a replica of the reset system. This makes our brain spin… shouldn’t the reset be among the most reliable parts of a processor?
At any rate, great work so far. We can’t wait to see where this goes and we hope that it unfolds in a way that is as exciting as watching [Quinn Dunki’s] Veronica project take shape.
[Peter Bjornx] brings classic microprocessors and modern microcontrollers together with his Arduino bootstrapped 68008 computer. The Motorola 68008 is the 8-bit external bus version of the well-known 68000 (or 68k) microprocessor. A friend gave [Peter] one of these chips, so he built a simple computer around it.
This isn’t one of those clean retrocomputers with every connection carefully planned out and wire wrapped. [Peter’s] created a true hack – a working 68k system on a breadboard created with whatever he had on hand at the time. The real gem of this system is the ROM. [Peter] replaced an EPROM chip with an Arduino.
In the not-so-good-old-days, microprocessors (and many microcontrollers) ran from an external ROM chip. This often was a UV-erasable EPROM. Carefully compiled code was burned into the EPROM with a device programmer. If the code wasn’t perfect, the EPROM had to be pulled and placed under a UV lamp for 20 minutes or so to erase it before it was time to try again. EPROM emulators were available, but they were way too expensive for the hobbyist.
Thankfully those days are far behind us now with the advent of EEPROM and then Flash. [Peter] didn’t want to revisit the past either, so he wrote a simple Arduino sketch which allowed it to act as an EPROM emulator, including address logging via the serial port.
The design still caused [Peter] some headaches, though. His major problem was a classic 68k issue, /DTACK timing. /DTACK or Data Transfer Acknowledge is one of several bus control signals used by the 68k. When the 68k performs a read from the data bus, it waits for /DTACK before it transfers data. The Arduino was too slow to release /DTACK in this case, which caused the 68k to think every read was immediately completed. There is a much clearer explanation of the 68k bus cycles on this Big Mess O Wires page. [Peter’s] solution was simple – a D flip-flop connected to the address strobe took care of the timing issues.
It took quite a bit of tinkering, but the system eventually worked. Peter was able to run the 68008 from its reset vector into a simple loop using the Arduino. It’s only fitting that the 68k program loaded by the Arduino was an LED blinker, everyone’s favorite hardware Hello World.