#pikapc

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.

Sometimes the Hardest Problems Need Only the Simplest Fixes

I have been working on improving video output for my PikaPC homebrew computer. When last I left off, I was able to initialize the video chip to output 320x200 video, but it was only outputting 4 colors instead of 256. I really wanted to get it into the proper 256 color mode.

I never did figure it out.

Throughout this project, I've been referencing an annotated disassembly of the Trio64 VBIOS to try to figure out how to use these chips. I've also spent some time in ghidra working through the ViRGE VBIOS. I am currently working with the Trio64V+ which is different from both of those, but they are all close enough to get a good feel for what is going on. The VBIOS initialization sequence is a little hard to follow because it jumps around quite a bit, and requires some detailed knowledge of the PC platform which I lack. But I was eventually able to find and work through the video mode selection function, stepping through the data tables it used for configuring the myriad registers.

The result? 640x480, 16-bit color, with full linear addressing enabled. Far better than I had hoped for. The results were beautiful! But unfortunately it really called attention to a problem I had been ignoring.

I had initially noticed the problem when trying to write low values (dark colors) to video memory. Higher values tended to work without issue, but darker values would end up written to the wrong location or skipped entirely. There was a pattern to the glitches vaguely resembling incrementing binary values, presumably influenced by the write address.

It didn't make much sense to me. Why would the data value affect the address that the data ended up written to? And why would writing 0, in particular, result in a higher address being affected?

And then the problem got much worse … after I removed my logic analyzer probes.

Where previously only very low value writes would glitch, now any value was potentially affected. The binary pattern was much more pronounced. And over time as I tried to debug the problem, it continued to get worse. Eventually nearly every write would fail.

Ok, this is clearly a timing issue. I've had timing issues before; I know how to handle this. I'll just reduce the clock speed from 25MHz to 20MHz. No change. Perhaps 16MHz? or even 12? I think that made it worse. Well … what if I throw a 32MHz oscillator at it, what might that do? Surely overclocking the system will only …

… Largely fix the issue.

What? How‽ That is the craziest thing I've seen. When fighting timing issues, the answer is never go faster. But faster really did improve the issue. It did not resolve it completely, but it was much better.

I decided I needed to pull out the big logic analyzer and compare what was happening on my shared Address/Data bus with what was getting latched by the video card's address registers. This required soldering 21 tiny 30-gauge wires to the leads of the TSSOP package register chips. It was very fiddly work that took far longer than it should have, but I got there in the end.

With all the analyzer leads attached, I was finally ready to sit down and figure out what was causing this problem.

There was just one small new problem — there was no problem. With all the test leads attached, it worked flawlessly.

[techknight] pointed out that the probes would change overall capacitance of the bus, which tied into a previous conversation we'd had regarding series termination resistors for high speed signals.

Series termination resistors are small-value (20Ω to 30Ω range, typically) resistors placed near the driver on a bus to help with signal reflections. Adding discrete resistors to my hand-wired prototype would be a challenge. I don't have a lot of board space left over and it would require a significant amount of rewiring.

There was an alternative option though — 74'2244 buffers. Anyone in this hobby deep enough to know a few 7400-series part numbers off-hand might recognize the 74'244 octal bus buffer, but '2244? The difference is integrated series termination resistors. As I understand, series termination resistors work best if they are as close as possible to the output driver, and it's hard to get closer than on-die. Plus, it would mean no wiring changes.

So I ordered a few 74ABT2244 buffers and swapped them in for the 74AHCT244 buffers I had been using. And it works beautifully.

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.