Allow Me to Interrupt

When I built the 8-port serial card for Wrap030, my 68030 homebrew computer project, I omitted support for interrupts. The reason why is already lost to time. Perhaps I couldn't figure out how to pull it off with the board space I had left; perhaps I didn't think it would be necessary. No matter the reason, the result is the same — to get any data in or out, the CPU must continually poll all eight logical devices or risk losing data. This is terribly inefficient and why interrupts exist to begin with.

I suspect that lack of interrupt support may have contributed to the problems I had trying to get NetBSD to boot multi-user. I would like to address the issue before I circle back to trying to get NetBSD running on this machine.

There are a few challenges:

This was an expensive board, well over $100 two years ago; I would prefer not to have to build a new one from scratch.

There is no board space left. Even as a 4-layer board, I struggled to route all of the signals on this board. Dense component placement on top and bottom leaves little room for bodging.

There are eight active-high interrupt signals I need to combine or encode for the 68k active-low interrupt inputs.

My original Wrap030 bus layout (going all the way back to the original wire wrap prototype) did not break out the CPU's three interrupt signals for expansion boards to use.

I did not break out the eight interrupt output signals on the serial board, so wires will need to be soldered directly to the fine pitch QFP pins.

I spent quite some time trying to figure out the best way to combine the UART interrupt signals. An 8-input NOR gate would work, but those appear to have only been built in CMOS, and I don't have anything like that on hand. I could throw a 22V10 programmable logic device at it, but that is an expensive solution to such a simple logic problem.

I eventually decided to use an 8-bit comparator — I have a small stock of 74F521 comparators on hand. These chips output a logic low when their two 8-bit input ports match. By grounding the second port, the chip will output a low signal when all of the interrupts are inactive, and go high when an interrupt is asserted. The result is effectively an OR gate. I ran that into the base of an NPN transistor to invert the signal and give me the open-collector output I needed for properly sharing the CPU interrupt inputs.

There was no good space on the board to deadbug bodge in this new circuit, so I built it on a small breadboard. I used an unpopulated oscillator footprint to give me a socket to hold the new board in place beneath the serial board, and attached a header for a ribbon cable to connect the two.

Since the CPU interrupt signals are not anywhere on the bus, I had to run a wire-wrap bodge from the breakout board to the main board. It's a fragile solution I don't care much for, but have used on this project before when necessary.

All that was left was to solder 8 tiny wires to 8 tiny chip leads. This was the hardest, most frustrating part of this endeavor. It is very difficult to get the wire soldered into the correct pin without bridging over to the next pin. Once the wires are soldered in there is very little surface area binding them to the pins, so it's easy to pull them loose. I used some polyimide tape to hold everything in place, with each new wire's tape also helping hold down the previous wires.

All together, I can't say it's the best solution, but it should work. All eight UARTs will show up under the same interrupt vector, and the CPU will have to identify which if the eight chips requested the interrupt. But that is still much more efficient than constantly polling the devices.

Solving Problems One-by-One

I left off last week with my revised PikaPC host card briefly running code but crashing before it could fully boot to the forth prompt. As best as I could tell it was crashing when returning from a subroutine, which could indicate main memory still was not working.

I started by probing the DRAM control signals to verify that memory bank was getting properly initialized as DRAM and accessed as main memory. I could see the DRAM RAS and CAS signals immediately start running regular refresh cycles as soon as the bank was configured, so it was indeed using that bank as DRAM. What I could not see however, was any attempts to read or write main memory before the machine crashed.

I went back and double-checked my bank configuration settings and reread the section of the manual on configuring memory banks. There it was, right in the manual:

PPC403GA is an embedded chip, not necessarily intended for general-purpose computing. As such, it has some helpful features that a general-purpose CPU, like the PPC603, would not have. One of those helpful features is the Bus Interface Unit (BIU), which provides the memory banks, DRAM control, etc. The BIU defines SRAM/peripheral banks as starting at a minimum address of 0x7000,0000, and that's what I had used when I defined all the addresses ppcforth should use. However what that line in the manual says is any banks defined as DRAM start at a minimum address of 0x0000,0000.

I updated ppcforth to point to the new memory address range and it booted to the forth prompt!

… and immediately crashed as soon as I typed anything.

This was an interesting bug that took me a while to track down. I started by disabling cache so I could capture what code it was running when it crashed. Sitting at the forth prompt, it was in a tight busy loop waiting for a new character to come from the serial port, w4char. So I pressed a key to see where it jumped and what code it ran next. It never loaded any code beyond that w4char loop.

I took a detour here to write a simple memory test just to make sure main memory was actually functional (my first time sitting down and writing anything significant with PowerPC assembly!). It passed without issue. It's not an exhaustive test, but it does at least confirm that a word written to memory could at least be read back some time later. So that wasn't the problem. I needed to track down what actually happens when a character is received over serial.

The ppcforth code was written to use hardware interrupts for receiving serial data so I had to learn how interrupts work on PowerPC. PPC uses an exception vector table similar to M68k, where each type of exception triggers the CPU to load from a specific offset into the table. Unlike M68k however, the CPU does not load an address for the interrupt handler from this table. Instead, each vector is a 256 byte (64 instruction) block of code. If more than 64 instructions are needed, the programmer will then need to branch to the rest of the interrupt handler located elsewhere in memory. That's what ppcforth does; it adds a single branch instruction at each vector to the interrupt handler.

PowerPC is a RISC architecture. It very strictly adheres to the rule that each instruction is one word, and one word only. In M68k, a jump instruction could be one word followed by a long word with the full address for the jump. On PowerPC that is not allowed. The branch address is embedded into the branch instruction and thus a branch is limited to 24 bits. With my ROM above address 0x7000,0000 and my RAM down in the 0x0000,0000 range, a branch instruction could not reach from the table in RAM to the handler in ROM.

This is not a unique limitation for a branch instruction. It's fairly common for branch instructions to have a specified range, forwards or backwards, that it can branch to. This is often supplemented by something like the M68k absolute jump instruction. PowerPC does not have an absolute jump instruction, at least not that I could find. The only option is to load an address into a register, copy that register to the Link Register (which is generally used to store the return address for short subroutines), then branch to Link Register. Instead of loading a single branch instruction into the vector table, I would have to load code to load the handler address into the Link Register and then branch.

Or I could just run everything from RAM. I tried the former option; it was more complicated and it crashed. I didn't bother trying to debug it. I just wrote the code to copy ROM into RAM on startup and run from there. That got me to a functional Forth prompt and I was able to run programs!

The next thing to try was test the host card with my video card to see if it would work. It did not. Nor did any of my other cards.

This is the same bus I've been running on my prototype, it should just work, right? Well, almost. Comparing schematics I found two discrepancies — CS2# and CS3# were swapped (a problem I remember fixing on the prototype but never carried over to the host card), and two address signals were wired incorrectly (PPC403 uses them as byte write strobes normally, but can also use them as address inputs during external DMA cycles). The first problem I could fix easily by reassigning input pins on the bus control CPLD. For the second I needed to cut a couple traces and bodge the signals to ground.

And with that, I was able to initialize video and draw on screen using my video card with the new host card. With almost no time to spare, PikaPC phase 2 is running in time for VCF Southwest 2026 this weekend! I will be exhibiting both the PikaPC prototype and phase 2, along with my Wrap030 project.

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.

It's a new month, a new project to rotate in. It's time to get back to the minicomputer. I need to work on some of the equipment that I got, and test some logic designs. I've taken a few days off from work, so hopefully I can convince myself to actually start working on things.

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.

Two Steps Forward, One Step Back

Finally, I have video working on PikaPC, my PowerPC homebrew computer. I've adjusted my Forth Mandelbrot program to draw on screen instead of over the terminal. But surely I can do better, right?

One of the original goals of this project was to get the proper tools and development environment set up for writing PowerPC code, but I've spent all my time writing Forth code for it. It's time I set up a C compiler.

This would have been so much easier if I were running anything other than Windows on my main computer. Cygwin and MinGW never given me anything but trouble, and something is wrong with my WSL installation. So I was left to the mercy of whatever precompiled tool chain I could find.

The first result that came up for a PowerPC C compiler for Windows, a gcc build, was very broken. The preprocessor & compiler worked, but the assembler output was always empty. Not much use. Eventually I did find another that did work. It is missing some common libraries, but at least it will properly compile useable code.

With that sorted, I tried porting my integer Mandelbrot program from Forth to C. It did not work. I have no real debugging environment set up, and at this point couldn't even print to the terminal from C code, so it was really hard to have any idea what was going wrong.

I was however able to get it to work using the GCC built-in software floating point library. This worked great! It only took … 13 minutes to render. That is double the time the Forth program took to run. I know this machine can do better than that. Time to give fixed-point authentic another shot.

I tried. I really did. First I tried the easy decimal fixed point I used in Forth, where numbers are multiplied by 1000. I never could get it to work right. I don't think it's the best approach anyway; better to use binary fixed point.

For binary fixed point, a certain number of bits will be the integer component, and the rest will be the fractional component. Unlike floating point, there is no exponent. It's much simpler in that regard. I tried to figure it out myself, but ultimately pulled the code I needed from libfixmath.

Finally, success!

This new fixed-point C code is much faster than my Forth program. I knew this machine could do better.

Good Enough to Move On (For Now)

I've been working on bringing up the video card for PikaPC, my PowerPC homebrew computer. This is a custom card I designed to support the S3 ViRGE or Trio64V+. I'm using the latter for now because ViRGE was known to have some bugs in its VLB support. Last week I was finally able to work out a wiring error that was preventing me from accessing the chip and get it to output a valid video signal. That's about all I could get it to do though — no matter what I wrote to video memory, the output remained black.

I stayed at that point all week. I tried different initialization sequences, video modes, timing. I dug through example code, existing drivers, disassembled S3 VBIOS. I read and reread the descriptions for each of the hundreds of registers. Nothing helped. The best I found was I could set the color of the screen by writing to RAMDAC color 0, so I figured I had to be missing something that was blanking the screen.

Eventually I did find an output enable setting in the first VGA Attribute register. It gets disabled during initialization and should be re-enabled at the end. It seemed like just the thing I was missing! It had no effect.

Later, I was doing some experimentation with getting a text mode set up instead of graphics, hoping I might have better luck with it, when I found the enable bit in the Attribute register. I didn't have all of the register settings programmed out for the text mode so I had pasted the graphics initialization routine into the Forth prompt and run that, and then I ran my partial text mode initialization routine. The screen changed color and this time had a border.

After some more reading, I ran the graphics initialization routine again so I could run some more tests and suddenly the monitor switched to displaying random garbage on screen. Finally I had the chip displaying its (uninitialized) frame buffer!

There was just one problem — I had no idea how I had done it.

I tried to retrace my steps and figure out what I had done, but I still kept ending up at that same old blank screen again. At some point, I ended up inadvertently running the graphics initialization routine a second time without resetting the chip. The display again switched from black to a solid color with a border. So I ran it a third time. The display switched to the random contents of video memory.

Something is wrong with my timing or order of operations. I have no idea what it is, and so far have had no luck finding it. But if I run the initialization routine three times in a row it works and I can draw video. It shouldn't be necessary, but at least it works reliably. Good enough to move on.

Now that I could finally draw on screen, I set about modifying my Forth Mandelbrot renderer to output to video instead of to the terminal.

It took around six minutes to render this 320x200 frame at 256 iterations. Not bad, especially given the limitations in ppcforth that required some rather inefficient code. I would like to get a C dev environment set up to see if I can get that time down. I know PowerPC can do better, even at only 24MHz.