#vlb

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.