#homebrew computer

So Many Tiny Wires

I've just finished the wiring to add an S3 ViRGE video chip to PikaPC, my PowerPC homebrew computer project. It required hundreds of 30 gauge wires wrapped around hundreds of tiny square posts.

It looks like an absolute mess. I didn't spend as much time as I normally do with making sure each wire is carefully routed in straight lines that follow along rows of pins. Instead, I put more effort into making sure certain bus wires were approximately the same length. Others signals I wanted to make sure were as short as possible and took a direct path that cuts across the board. Wires on top of wires on top of wires.

I'm back at that point I mentioned before: I have sunk so much time into all this wiring with no idea if it will even work. It's intimidating. There is very little chance that this will all just work the first time I throw the switch. I'm going to have to take the time to comb through my schematics, my wiring diagrams, my actual wiring, etc. to figure out what mistakes I've made before this thing will run. It's a lot of hard work.

Preparing the mind for the disappointment of it not just working, for the effort of tracing down problems, for all the thinking and problem solving … it's a tough hurdle. This is the stage where so many of my projects have ended — done with all the manual labor, but too scared and intimidated to even see if it works.

But, I've come all this way and I really want to see this thing run. There's only one path forward — I have to actually throw the switch and see what happens.

… but perhaps not today.

Bill Buzbee's Magic-1 Homebrew CPU

A one of a kind homebrew computer made from 7400 series logic. This was my favorite exhibit at the show, because this machine was one of the big inspirational homebrew projects of note that I aspire to match. This thing is wirewrapped by hand, and programmed with an impressive operating system, also by hand. This machine is a beast!

sidenote. I absolutely love the SAM9x75 SoC so far, its insanely simple and cheap yet quite capable in terms of IO, without going overboard on processing power. Perfect for making a low-spec computer.

Also has some really neat features like XIP which will save a lot on RAM usage. and they provide source code for pretty much everything and documentation is amazing.

only issue is that the CPU is an 800MHz ARM9 core with 64MB of onboard RAM but that's not that bad for a simple desktop with most everything running with XIP. Plus, I can easily extend it. Which I might do later on idk.

PikaPC Runs First Code

I've finished wiring the essentials on my PikaPC homebrew computer project. As it sits currently, it has the PowerPC 403GA CPU clocked at 24MHz, 512kB of flash ROM on an 8-bit bus, 1MB of SRAM on a 16-bit bus, and one serial port. I'm using an ATX power supply because it has the standard +3.3V, +5V, +12V, and -12V rails that I need. That should be everything necessary to start testing and running some simple software.

I just need to get it working.

I have been procrastinating on this project. Sometimes when I start something new I get excited and a little carried away. Instead of stopping and testing each piece as I go along, I'll blow through and wire the whole thing in one go. This means that by the time I get around to testing, I've already put in a lot of effort and there is far more to go wrong. It can be really intimidating and hard to know where to start when there is a problem.

I wired the whole thing. And it's really intimidating. It is Schrodinger's project — until I throw the switch and observe, it is both working and not working. But the only way to move forward is to push past the anxiety and throw the switch.

Here goes …

It didn't immediately blow up, that's a good first step. Nothing is getting hot, so probably no direct shorts. Clock is running just fine, and reset signal is behaving as expected. Only thing left is to throw some code onto a ROM and see what happens.

I've decided to try running PPCForth, a Forth environment targeting the PPC403 family with special features for loading code over serial and even re-flashing its own ROM. It's just the thing for a project like this! The author was targeting the PPC403GC, whereas I have the PPC403GA, so there were a few minor adjustments I had to make to get it to compile.

I burned it to ROM, connected serial port to a terminal, and … nothing.

Pulled out the oscilloscope. No movement on the serial Tx pin. Reset & clock are still working, the boot option pins are strapped to the right values. But there is no activity on any of the address, data, or control wires.

Or so I thought. My oscilloscope is an older style analog scope that some wonderful person gifted me at VCF Southwest 2023. It is a great tool for repeating signals, but is not a capture scope so it's easy to miss very fast transient signals. Some things just need a logic analyzer.

It's doing something. It toggles the data read strobe and the ROM chip select signal for about 6 milliseconds before stopping. Much too quick for me to be able to see reliably on my scope. But the CPU is not indicating that it is halting. I need to capture more to see what is happening.

The data bus looks interesting. It starts out moving slowly and then speeds up.

Which is exactly what it is supposed to do.

The PPC403GA has an on-board memory controller. It runs the bus slowly on reset for broad compatibility, and then software can configure the memory controller to run at the proper speed for the attached devices. That's what is happening here. It is running code at least long enough to configure the memory controller.

With the logic analyzer capture, I can read through the data it's fetching to see where in the code it is halting. I traced it down to the putch routine, which outputs data over the serial port. It got as far as checking if the UART was ready to send data and then never loaded any more code.

But that is actually expected behavior. The CPU has 2kB on-board cache and is running a tight loop. It doesn't need to fetch any more code until it exits the loop, and it won't exit the loop until the UART is ready to send data.

This actually had me stuck for a while. Best I could get it to do was sometimes output garbage on the terminal. I double- and triple-checked my wiring and serial pinout. And finally, I buzzed out the IDC-to-DE9 adapter I was using. Instead of ground being on pin 5 of the DE9 connector, it was on pin 3?

Ah. There are two different standards for IDC-to-DE9 adapters, and I was using the wrong one. As a result, the CPU never saw the Clear To Send signal it was expecting, so it never signaled to the program that it was ready to send data.

It was running! And then immediately crashing.

It turns out the code still had some references to an LED GPIO pin that the PPC403GA doesn't have. I just needed to comment out a few more lines of code and update my ROM.

And now my little PikaPC boots up to a welcoming Forth prompt.

All in all that was a surprisingly painless bring-up. No major wiring errors; I had just grabbed the wrong adapter. And save for a few minor adjustments, the code just worked too.

PikaPC Homebrew Computer

I've started a new project. I even gave it a proper name this time! I'm calling it PikaPC, named after the adorable screaming lagomorphs.

My last big homebrew project was built around the Motorola 68030, a 32-bit CPU that could do some serious work in its time. That project started out as a wire-wrap prototype on cheap protoboard and ended up as a stack of custom PCBs running my own multi-user Operating System and even current 2025 release of NetBSD (... mostly).

So where do I go next? How can I possibly top that?

In my previous homebrew projects I worked with the 1976 Zilog Z80, the 1979 Motorola 68000, and of course the 1987 Motorola 68030. Along the way I dabbled briefly with the 1978 Motorola 6809, the 1975 MOS 6502 (using the Grant Searle design), and even the 1993 Intel Pentium.

I've explored 18 years of computer history over the last decade and I want to keep pushing forward. I want to try something new; an architecture I've not built with before and which is not common for homebrew machines.

So following a trend from the early 1990s, I'm making the move from Motorola 68k to PowerPC.

I'm starting small. For this PikaPC project I'm using the 1994 IBM PowerPC 403ga embedded processor. This chip was intended for use in purpose-built devices like set-top boxes, rather than general-purpose computers. As a minimal embedded device, it lacks certain features that its more fully-featured brethren had, such as a Floating-Point Unit or Memory Management Unit. What it does have though is some on-board peripherals to make building cheap devices faster and easier, such as serial ports, timers, Direct Memory Access controllers, and memory controllers. This means I can wire the CPU directly up to ROM and RAM without needing any additional glue logic.

And because I have all the parts on-hand already, I've decided to wire-wrap this initial prototype. I can get started right away.

To start with, I just want to get ROM, RAM, and the on-board serial port working. That should be enough for me to get PPCForth running with a terminal as a minimum viable prototype. From there I can start playing with additional peripherals and software. I've never used PowerPC assembly before, so I'm facing a leaning curve there.

On Using the Right Tool for the Job

I've been working on bringing up the video card for my PikaPC project. It has had me quite confused. No attempt to communicate with the device had any effect.

Everything I was sending it looked right. Address decoding asserted the chip enable, the state machine on the video card recognized it was being addressed, the emulated VLB cycle started. There only thing that was missing was some acknowledgement from the video chip itself.

I added debug headers and attached fine wires to even finer chip leads. I did manage to catch a few errors — I was asserting the VLB address strobe on the wrong clock edge, and I had omitted a couple pull-up resistors. My fixes did not change the result.

Recently a good friend sent me an HP 1670E logic analyzer. It is a 136-channel beast of a machine that is currently consuming over a third of my available desk space. I must admit some hesitance in attempting to use it. Frankly, I was intimidated. But I had a problem that surpassed what my 16-channel USB analyzer could easily tell me. To solve this problem, I needed to be able to see all of my 32-bit address/data bus plus another 8 bus control signals.

I attached the first 40 probes to my protoboard card, stumbled through the menus to learn how to enable and label each channel & configure the trigger event, and pressed Run. The machine waited. I hit enter on the PikaPC terminal to start a bus cycle addressing the video card.

… and immediately saw the problem.

The first step in initializing VGA is to set an Enable bit on I/O address 0x3c3. But the analyzer captured 0x1c3.

Either I had a short, or a missing address signal. I had already confirmed there were no solder bridges or missing signals on the video card, and I was using my protoboard card anyway. So the problem had to be on my main board.

I captured a few more tests —

0xfc0 captured as 0xfc0 ✅

0x7c0 captured as 0x7c0 ✅

0x5c0 captured as 0x7c0 ❌

0xcc0 captured as 0xec0 ❌

Address bits 9 and 10 were identical in all test results, regardless of input. Probing those address pins on the expansion bus buffer indicated a direct short. The problem did not affect normal operation of the machine, so it was not likely that CPU address pins 9 and 10 were shorted together. I traced the two wires from the buffer back to the CPU and found … both wired to the same CPU pin.

I had finally found my problem. It was a quick fix. Once it was in place, I ran the VGA initialization sequence and my monitor immediately sprang to life.

My video card appears to be working. I still haven't figured out the correct incantation to actually draw anything on screen using these S3 chips. That will be the next hurdle.

An Update I Can Count On

I have the first signs of life from the new bus on my PikaPC prototype!

The logic ended up being quite a bit less complex than I expected, using only 32 macrocells. It's just simple state machine written in verilog.

I did have to rework my plan for bus cycle timing & handshaking to work around more quirks of the PPC403's weird bus interface, but it does work. This took me even further away from NuBus, which I originally started from. But if it works, it works …

I decided what I really needed to make sure things were working was a dead-simple test card. Nothing so complex as my DRAM card (which is what I want to tackle next) or even needing custom logic like my keyboard/mouse controller card.

So I threw together a card with a 74'574 register, a 74'139 decoder, and some LEDs. (So glad I decided to spin up some custom prototyping boards!) The idea being I can write a value to the register and it will show up on the LEDs.

This was a good idea. I was able to find I had miswired one signal and swapped a few more in my CPLD pin assignments. I also got to watch my logic run with a logic analyzer to see that the timing mostly worked as expected, but with still more weird quirks of the PPC403 I hadn't accounted for.

Today, 26 March 2025, is the tenth anniversary of the first time I put power to a Z80 microprocessor in a breadboard and watched it blink some LEDs.

Within a few weeks that Z80 would be completely surrounded by other chips and hundreds of wires to form my first functioning homebrew computer.

Another week and I was already removing a 68000 from a (presumed) dead motherboard, with grand ideas of moving up to the 16-bit era (but absolutely no understanding of what that would entail)

It would be another two years before the first time I put that 68000 in a breadboard and successfully used it to blink an LED.

By the time another year had rolled around that 68000 was living on a soldered breadboard and for the first time on one of my projects, it was running real software — EhBASIC.

Always looking to more challenging projects, while I was building with a 68000, I was already reading through the manual for the 68030 trying to understand how to build with a proper 32-bit microprocessor. Just one more year and I had that 68030 on a wire wrap board, blinking an LED.

The next year I was doing the most ridiculous thing I could think of — free-running a Pentium CPU on a wire wrap breadboard to blink an LED. Because I could.

By the end of the next year that 68030 had moved from its wire wrap board onto a proper printed circuit board — my first ever 4-layer PCB.

The next year saw the towering expansion of the 68030 build, adding new peripherals and functionality.

Another year and I had an all-new 68030 build on a Micro-ATX form-factor motherboard developed in just a couple months ahead of VCF Southwest 2023.

The next year I focused on developing software for my existing 68030 board stack, rather than building something new from scratch. I succeeded in developing a minimal multi-user kernel to run four instances of BASIC simultaneously.

All along in between working on these projects I have done component-level repairs on various computers, developed expansion cards for the Mac SE, built PCs both new and old, burned out hard, developed some smaller homebrew computers, had a lot of false starts, failed projects, and abandoned projects, and completed some massive projects in my day job.

Looking back at everything I've worked on over these past 10 years I am absolutely amazed at how far I have come and what I have been able to accomplish. Much of it I still don't understand how I managed to actually pull it off, and I'm not entirely sure I could duplicate my successes.