#s3 graphics

[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.

[techav]

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.

That was such a wild ride. Countless hours debugging for a fix that ended up being so simple. But I'm glad to finally have it working. I plan on exhibiting this project at VCF Southwest 2026 coming up at the end of May. It might not be doing anything interactive, but at least it will be able to make some pretty pictures.

[techav]

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.

And I'm going to have to rewire that peripheral data bus again.

[techav]

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.

This is the bare minimum I wanted to have working in time to exhibit the project at VCF Southwest in May. I have some time to keep building from here. I am very excited. It has taken a lot of work and a lot of frustration to get the project to this point. It's great to see it starting to come together.

[techav]

PikaPC Phase 2

I'm moving forward into the second phase of my PowerPC homebrew computer project, PikaPC — spinning up PCBs to replace the wire-wrap prototype. I've spent the past week dividing up the schematic into manageable cards using my new bus spec, and laying out 10x10cm PCBs for each section. I have five cards planned to start with: a host card, a 72-pin SIMM card, a card for the S3 ViRGE, an power supply & bus termination card, and a card for an 8042 PS/2 keyboard/mouse controller.

I've completed all these PCB designs just in time for Spring Festival to shut down production & shipping, so I expect it will be quite some time before I receive them. In the meantime, I think I might try to implement my new bus on the wire-wrap prototype so I can test the new cards on a known-good system.

[techav]

Farewell ViRGE, We'll Meet Again Soon

I've removed the ViRGE graphics chip and its video memory from my PikaPC prototype. There's just a large bare spot on the board left in its place.

My new PCBs for phase 2 of the project have finished production and are awaiting shipping, but I also have quite a few parts I'll need to order as well. While I wait, I've decided to go ahead and add the buffers and logic necessary for driving my new bus to this prototype. This will let me test the new peripheral cards with a known working system, which should aid in debugging. I needed to free up some board space to add the new logic so for now, ViRGE had to go.

It will be back though. One of the PCBs I ordered is a nice 4-layer board for ViRGE. I think a proper PCB with a solid ground plane and nice short traces (relative to my hand wiring, at least) should resolve some of the signal problems I ran into.

[techav]

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.

But there is a problem. It was here last week and I missed it. The Trio64V+ video chip is supposed to be configured for 256 color mode (or 256 shades of grey, as that's how I've set up the color palette), so each byte written to the video buffer should be one pixel. What's actually being displayed is only 4 colors, and each byte affects two pixels. I'm going to have to dig back into the Trio64V+ manual to figure out what registers I've missed to get this into the correct color graphics mode.

[techav]

New Bus?

I believe I may have run into a hard limit of using wire-wrap construction. After weeks of trying to debug video memory access with the S3 ViRGE, it's looking like the failures are in the analog domain. I'm not consistently hitting necessary timing requirements, presumably due to the relatively weak drive circuits for the ViRGE memory control signals and higher impedance? capacitance? something? of my hand wiring. Analog domain is where my understanding really breaks down.

I've been through this before with my initial Wrap030 prototype barely being able to run at 4MHz, but the PCB running smoothly even when overclocked up to 56MHz. I think it's time to start thinking about moving PikaPC to a proper PCB.

I'm not sure I'm ready to take this project to a monolithic fully-integrated PCB though. I've not yet built and tested the disk interface I wanted to try. I wanted to test using SIMM DRAM instead of SRAM. There is still the chance that ViRGE won't work out and I'll need to pivot to a different chip. And there is also the long-term goal of graduating up to something like the PPC603.

So modular is the way to go. I can develop and test individual parts without the expense of a complete large motherboard. Modular is good because if I plan things out well, I can reuse the peripheral cards I develop here for future projects (something I could never do with what I developed for Wrap030).

I just need a good bus to use.

I need to support at least 32-bit data so that rules out something like SMEbus or modern hobby buses like RC2014. Anything card-edge is out; good card-edge PCBs are expensive and without external support the connections are not reliable. That rules out ISA, Microchannel, VLB, S-100, etc. PCI can has non-card-edge standards, but uses some weird drivers and bus terminations and is a little too complex for this purpose so it's out too. I am partial to the 96-pin DIN 41612 connectors used for a number of bus standards over the years; VMEbus could be a viable option here. NuBus probably comes closest to what I need, but its control encoding and inverted data bus are annoying.

I'm going to throw a wrench in my own requirements here — I already own a DIN 41612 backplane, but it does not have the center row wired and already has power and ground wired in a non-standard manner. If I want to use the backplane I already have (backplanes are expensive), I'll have to come up with something custom.

I'm taking inspiration from NuBus, but decoding the control signals. For simple peripheral cards, this will minimize the glue logic I'll need compared to what would be required for NuBus proper. I've kept a similar pinout, making allowances for the pre-defined power pins on my backplane and the additional control signals I'll need.

I've started laying out PCBs using this new bus for the initial set of cards I'll need, starting with the host card. I'm planning on a host card (CPU, ROM, bus control, & serial), DRAM card, keyboard controller card, video card, and a power supply & bus termination card.