#homebrew computing

[techav]

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.

[commodorez]

How would one go about learning how to make something like the cactus?

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.

Hopefully that answers your question. Keep 'em coming!

[techav]

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.

Time for me to start learning Forth and PowerPC assembly.

[techav]

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.

So why PikaPC? Because I had pet rabbits as a child and have always held a fondness for lagomorphs. I'm generally terrible at naming projects, so I thought a lagomorph naming theme could be fun. [YesterGearPC] suggested the name PikaPC403. I like it because it fits as an obvious play on "PowerPC", but also because the American Pika is one lagomorph species found in the North American 403 area code and that's esoteric enough to work for me.

[techav]

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.

I might have eventually found this issue using my small analyzer. I would have had to capture the address bus no more than 8 bits at a time, carefully stepping through multiple captures with different test parameters. It would have taken quite a long time, and there's no guarantee I would have noticed the error no matter how carefully I reviewed at the captures. There just isn't any substitute for using the right tool for the job.

[techav]

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.

For the video at the top of this post I'm running a simple Forth program to count up from 0 to 15 and display the binary equivalent on the LEDs. It's a simple test representing another big milestone for this project. Now that I know my new bus controller works, I can start building more complex peripheral cards to go with it.

[techav]

Looking Back

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.

On Multitasking

Sharing a Computer with Friends The Motorola 68030 was a decently powerful microprocessor for its day. It is a fully 32-bit processor with 1

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.

Here's to the next ten years

[techav]

On Celebrating Errors

Isn't it beautiful? The lovely formatted tables of register and stack contents, the trace of function addresses and parameters, the error message ... it's the most beautiful kernel panic I have ever seen.

Why on earth would I be so excited to see a computer crash? What could possibly be beautiful about a kernel panic?

This kernel panic is well-earned. I fought hard to get it.

This kernel panic came from a current NetBSD kernel, freshly compiled and running on Wrap030, my 68030 homebrew computer. It is the result of hours upon hours of work reading through existing code, scattered documentation and notes, writing and rewriting, and endless compiling.

And it's just the start.

As I've said before, a goal of this project has always been to build something capable of running some kind of Unix-like operating system. Now that I finally have all the necessary pieces of hardware, plus a good bootloader in ROM, it's time to give it a shot. I'm not that great with this type of programming, but I have been getting better. I might just be able to brute force my way through hacking together something functional.

It is hard.

There is some documentation available. The man(9) pages are useful, and NetBSD has a great guide to setting up the build environment for cross-compiling the kernel. There are some published papers on what some people went through to port NetBSD to this system or that. But there's nothing that really explains what all these source code files are, and which parts really need to be modified to run on a different system.

I had a few false starts, but ultimately found an existing 68k architecture, cesfic, which was a bare minimum configuration that could serve well as a foundation for my purposes. I copied the cesfic source directory, changed all instances of the name to wrap030, made sure it still compiled, then set about removing everything that I didn't need. It still compiled, so now it's was time to add in what I did need.

... how ... do I ... ?

This is where things get overwhelming very quickly. There is documentation on the core functions required for a new driver, there's documentation on the autoconf system that attaches drivers to devices in the tree, and there's plenty of drivers already to reference. But where to start?

I started by trying to add the com driver for the 16550 UARTs I'm using. It doesn't compile because I'm missing dependencies. The missing functions are missing because of a breaking change to bus.h at some point; the com driver expects the new format but the cesfic port still uses the old. So I needed to pull in the missing functions from another m68k arch. Which then required more missing functions and headers to be pulled in. Eventually it compiled without error again, but that doesn't mean it will actually run. I still needed to add support for my new programmable timer, customize the startup process, update hardware addresses, make sure it was targeting 68030 instead of 68040 ...

So many parts and pieces that need to be updated. Each one requiring searching for the original function or variable declaration to confirm expected types or implementation, then searching for existing usages to figure out what it needs ... which then requires searching for more functions and variable types.

But I got something that at least appeared to have all the right parts and compiled without error. It was time to throw it on a disk, load it up, and see what happened.

Nothing happened, of course. It crashed immediately.

I have no debugging workflow I can rely on here, and at this stage there isn't even a kernel console yet. All I could do was add little print macros to the locore startup code and see where it failed. Guess, test, and revise.

I spent a week debugging the MMU initialization. If the MMU isn't properly configured, everything comes to an abrupt halt. Ultimately, I replaced the cesfic machine-specific initialization code and pmap bootstrapping code with functions from yet another m68k arch. And spent another day debugging before realizing I had missed a section that had comments suggesting it wasn't for the 68030 CPU, but turned out to be critical for operation of kernel memory allocation.

Until this point, I was able to rely on the low-level exception handling built into my bootloader if my code caused a CPU exception. But with the MMU working, that code was no longer mapped.

So then came another few hours learning how to create a minimal early console driver. An early console is used by the kernel prior to the real console getting initialized. In this case, I'm using the MC6850 on my mainboard for the early console, since that's what my bootloader uses. And finally the kernel was able to speak for itself.

It printed its own panic.

The first thing the kernel does is initialize the console. Which requires that com driver and all the machine-specific code I had to write. The kernel is failing at its step #1.

But at least it can tell me that now. And given all the work necessary to get to this point, that kernel panic data printing to the terminal is absolutely beautiful.