#homebrew computing

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.

Like prerequisites, older code, hardware stuff, etc.

The main prerequisites I can think of are being heavily interested in vintage computers, and having the drive to try and fail and then try again.

I started with building Grant Searle's design, borrowing from other working designs as I went. However, for the front panel? That's alot of time designing, learning, simulating in Logisim, and testing with physical logic gates to produce something 100% original and of my own design. I imagine most folks won't want to go to the trouble of designing an entire front panel state machine like I did.

The good news is that there are way more kits that can help teach the necessary skills than ever before! Most notably, Ben Eater's 6502 kit is a really great way to learn many of the things that I've put into practice here. He has a whole youtube video series associated with it, walking through concepts, construction, programming, etc. step by step. Even if you don't build one of his kits, watching them is an informative process. *I* learned alot, even after having built the Cactus.

If you're going the Z80 direction, the RC2014 series of kits can teach you plenty. There's also glitchworks kits in a few processor types, but those tend to be a bit more for the advanced user. There's the 1802 Membership Card but that's small and not really expandable. I could be here all day listing kits that can help teach and build up experience.

I should mention that I have a computer science degree in my back pocket, but learning logic gates or using assembly was only lightly touched on in the course of my studies. Most of the programming I do involved messing around in BASIC anyway.

I really didn't have a game plan for some of it, so alot of my learning process was trial and error. Alot of errors, in fact. Still making them, and learning from them. I also took the harder route to construction, since I didn't know how to use EDA tools for designing PCBs like KiCAD or Altium or Eagle (don't use Fritzing for the love of fuck).

Oh, one other thing I can recommend: reading through contemporary 1970s computing magazines like Byte (check the internet archive for back issues). There are all sorts of cool projects and ideas present that can really guide you. It doesn't hurt to have a copy of Don Lancaster's TTL Cookbook on hand (I think it's in PDF form online).

Finding a community to help you out is also a great idea. Even back in the 1970s, many folks who jump-started the home computer revolution had the Homebrew Computer Club to help them out. Community meetings to bounce ideas off of, and help one another through debugging are essential in my book -- you don't have to work in a vacuum. I've got a few places I've asked for help, most notably the Retrotech Crew discord server. I've had the benefit of friends who also have homebrewed designs like @techav, who have inspired me with their ideas, but helped me out with mine. In turn, as I've learned, I've been able to help out others.

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.

Moving Slowly, but Still Moving

I've not said much about the new modular phase 2 PCBs I made for my PikaPC project since they arrived. Well, that's because they're still not working and I can't figure out why.

I was able to get some signs of life out of the host card. It did appear to be running code at least, but it was never able to boot to the PPC Forth prompt. Such a disappointment after how easily I was able to get it running on the prototype. I ended up setting it aside while I worked out the bugs on the video card, picking it up now and then whenever I learned something new about my bus timing or how to properly terminate bus signals. Nothing seemed to help. But I did find some errors in my design, such as completely omitting necessarily pull-up resistors on shared bus control signals.

Of course I had no idea if it was my host card or the DRAM card that was preventing it from running properly. Too many variables when trying to simultaneously troubleshoot two boards, neither of which have been confirmed to work properly.

I decided to pursue a couple different avenues.

First, I designed a new card that could hold up to 2MB of SRAM. The logic is much simpler for SRAM than for DRAM, and I thought I might be able to use it add memory to my prototype as well.

Second, since I already needed to make some revisions to my host board, I decided to squeeze in a couple 1Mx16 DRAM chips wired to the PPC403's built-in DRAM controller. This memory would be on the CPU's local bus instead of my expansion bus, so it would eliminate some of the variables for troubleshooting.

I got the SRAM board assembled first and tested it with my prototype. It appeared to work first try — I could write values to random memory addresses and read them back without error. Next I tested it with my (now heavily-bodged) first draft host card. Exact same behavior as I was seeing with the DRAM card.

So I assembled the new host card. This time I was met with … the exact same behavior again.

Disheartening.

It is running code up to the point of starting the PPC Forth cold start routine, so I know the CPU, clock, reset, and ROM are functioning well enough. But never gets past that point. I have identified a problem with it enabling machine exceptions during initialization, but even bypassing that step, it still doesn't make it though cold start. It's looking like main memory still isn't working … which is what I was hoping to avoid by adding the on-board RAM to the new host card.

I need to do some more work with the logic analyzer to confirm it is properly addressing main memory and that the DRAM RAS and CAS signals are behaving as expected. It could just be I have misconfigured the PPC403 bank registers that define how it accesses memory.

I was hoping to have the modular system running in time for VCF Southwest. The show is next week, so I'm pretty much out of time. But until then I'll keep probing away at it in the hopes that I'll finally have a breakthrough.