#ppc403ga

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.

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.

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.

Need Input

I'm working on adding peripherals to PikaPC, my homebrew PowerPC computer project. I have plans for adding support for video, SD card, and keyboard & mouse. I'm still waiting for some parts to arrive for video, and I'll need to build a SPI interface for an SD card, so I'll start with adding a keyboard/mouse controller.

I've decided to use a PS/2-compatible keyboard controller salvaged from an old PC motherboard that was destroyed by a leaking battery. There are endless options that would have served this purpose, but these 8042-compatible controllers are abundant and fairly easy to use.

The keyboard controller will be sitting on the 5V peripheral bus, so it will need the PLD I programmed previously for enabling the level-shifting bus transceivers, but otherwise it didn't need any other glue logic to interface with the CPU. It just required some inverting buffers for the physical PS/2 interface. This also makes it a good place to start testing my 5V peripheral bus.

I got everything wired up & flipped the switch to test it, and if course it didn't work. The computer would no longer boot. A problem like that is bound to be bus contention and removing the bus transceiver confirmed the problem. Probing with the logic analyzer, I realized the bus enable signal was stuck in the active state so the bus transceiver was trying to drive the bus at the same time as ROM and RAM.

Pulling the PLD and going back to the breadboard, I was able to duplicate the issue — the bus enable signal was always asserted and did not respond to any input changes. This took me a while to track down. I went back to the simulator and realized I hadn't simulated this particular signal previously. When I added it to the simulation, it came back as indeterminate state. Nothing I did seemed to have any effect. Despite assigning a value to the pin, it always compiled to be an input.

What was the problem? A typo. I had swapped two letters. The PDBEN pin I had defined at the top was never referenced, but the PBDEN signal I assigned a value to was used throughout. With that corrected, the computer booted into Forth again without issue with the 5V bus reconnected.

The next step was to update the ROM to configure the additional memory regions I would need for the keyboard controller. The PPC403GA has a built-in memory controller with 8 banks that can be configured for accessing DRAM or ROM/SRAM/Peripherals. Each bank comes with proper chip select signals and can be configured for proper timing for whatever device is connected to that bank.

I have the first two banks configured for ROM & RAM. I set up additional banks for the keyboard controller and future SD card & video peripherals. This ended up requiring some back-and-forth because I misunderstood how the bank addressing works. But once I sat down and mapped out all the regions of the address space that each bank needed, I was able to get the system running with all the requisite banks enabled.

All I needed then was some software to test the keyboard controller and keyboard. I have experimented with 8042 keyboard controllers before, so I had an old Arduino sketch that had worked for me previously. I just needed to port the initialization code over to Forth so I could start testing —

Success!

Playing around with my Forth code, I can initialize both the keyboard and mouse, and see them report back data. The keyboard sends valid scan codes for button press and release; the mouse sends valid data packets for movements and button clicks.

Just Read the Datasheet

It was staring me right in the face.

I had run into a roadblock and had no idea where to look next. After sleeping on it, I came back with fresh eyes to look over some logic analyzer captures from the night before. I had noticed a weird issue where ViRGE would assert its device selected signal (loca#) past the end of one bus transaction through to the end of the next, but had so many other problems I didn't look into it.

What I had missed was ViRGE was actually asserting its Ready# signal to terminate the bus transaction … roughly two clocks after the CPU had ended it.

I adjusted the PPC403 port definition to wait for the ready signal and finally saw it complete a bus transaction without timing out.

But I could only get it to respond if I tried writing to VGA register 0x3c3. That specific register has the primary video system enable bit, so I suspected that it would ignore other registers if the video system was disabled. I'm not sure that's actually true, but it did send me down the right path. I thought that I might be asserting the wrong Byte Enable signal on the ViRGE.

This ended being both true and not true.

IBM, being IBM, ordered the bus pins on the PPC403 backwards from what is standard for pretty much every other chip. For IBM, 0 is the most significant bit, not the least significant. For my own sanity, I reversed the numbering on the data & address busses in my schematic. This gave me a pretty close analog to the Motorola 68030 bus, where 8-bit peripherals sit on the most significant byte of the data bus, D[31..24].

The problem is when I wired my 5V bus controller, I did not reverse the order of the PPC403's Write Byte Enable signals. So I was signalling to write the low data byte while putting data on the high byte of the bus and vice versa.

But it's more complicated than that because of bus endianness. The backwards byte enable signals I was sending to the ViRGE were in the right order for what it was expecting, it was the data bus byte ordering that was not what it was expecting. I needed to swap the two middle bytes of the bus and swap the outer two bytes. That way when the PPC403 outputs a byte for an address ending in 0, it ends up on the data bus pins and x86 device would expect for an address ending in 0.

It's confusing. I had to write out a table of what the IBM-numbered pins were, then what I had numbered them for my schematic, then where a VLB device would expect them. And then triple-check all of it.

And then removed and rewired all 32 data signals between my bus transceivers and the ViRGE.

That was it. That is what I was missing that was preventing me from writing any data to the ViRGE registers. Once I got my byte lanes and byte enable signal order straightened out, I was able to write to registers and have the ViRGE terminate the transactions as expected. I loaded up the VGA initialization program I had thrown together in Forth and let it run.

The monitor woke up instantly and displayed a solid color screen. I checked the menu and it reported the resolution as 720x400@70Hz — exactly what I expected for the text mode I had configured it for.

But remember last week when I was trying to figure out why I was seeing an output signal on a pin I expected to be the second chip select input? Now that I know the chip lives, I should be able to read the ID data from its registers, right?

It read back 0.

It should not be 0.

Every other register read back 0.

I had missed something else important. PPC403 multiplexes its two highest and two lowest address pins. When a port is configured for 32 bit, those pins become the Write Byte Enable signals. On a read cycle they are held high. There is no way to decode the low 2 address bits when reading from a 32-bit port because the CPU expects the device to return all 32 bits it's requesting.

The problem is, if I configure an 8-bit port on the PPC403 for interfacing with the 8-bit VGA registers, read/write data will always need to be on the most significant byte of the PPC403 data bus, but will need to be steered to VLB byte lane called for by the lowest two address bits. This would require another three bus transceivers and additional logic that I don't really have the board space for.

Since I cannot get those lowest two address bits from the PPC403 when operating a 32-bit port, I have no choice. I'm going to have to find what I can sacrifice to cram in the additional logic.