OSDev.org

Hi folks,

for (some obscure) reasons I'd like to activate the planar VGA mode (16 colors, 4 planes) on the S3 Virge VGA chipset. So far, not much luck. I've studied the manual, and checked the OsDev wiki. The best I can get is a mode that looks like "ModeX" such that the bytes of the planes are interleaved (i.e. plane 0, plane 1, plane 2, plane 3 and so on), but not planes as "individual bitplanes" as VGA planar is supposed to work.

chipset contents are quite straight foreward:
SR04 (TS_MemoryMode) is 02
CR66 (ViRGe ExtMiscControl1) is 80 (disabling extensions)
CR3a (ViRGe Misc1) is 05 (also disabling extended modes)
CR31 (ViRGe MemoryMode) is 00 (byte mode, no extensions)
CR17 (CRTCMode) is e3 (byte mode)
CR14 (Underline row address) is 00 (byte mode)
GR05 (Graphics mode) is 00 (chain-4 clear)

The ViRGe stream processor is verified off.

Strangely, the ViRGe manual states that the 16-color planar mode is supported by the "VESA driver". I wouldn't know that the VESA driver supports a plane-interleaved planar mode, so I must be missing something. One possible technical detail would be to swap A0 and A1 incoming to the graphics processor by some higher order address bit, but also the "chain"-bit (bit 1) in GR06 seems to be non-working on this chip.

I was hoping that either somebody could help me with this mystery, or probably has a on old ViRGe based hardware available in the basement and could check whether the vesa driver *does* actually work in 16-color (planar) mode.
If it does, it would be immensely helpful if some good soul would be able to dump the VGA registers for me, including the extended ViRGe registers. Maybe there is some missing bit to enable the address bit swap to have a "true planar" mode and not this "mode-X" fake-planar.

Thanks a lot,

Thomas

thorfdbg wrote:Strangely, the ViRGe manual states that the 16-color planar mode is supported by the "VESA driver".

The "VESA driver" is any driver that calls VBE functions in the option ROM to set the video mode. Examining a randomly-selected S3 Virge option ROM indicates support for VBE 1.2 and 16-color planar modes 0x102, 0x104, and 0x106. Of course the option ROM also supports ordinary VGA modes.

thorfdbg wrote:If it does, it would be immensely helpful if some good soul would be able to dump the VGA registers for me, including the extended ViRGe registers. Maybe there is some missing bit to enable the address bit swap to have a "true planar" mode and not this "mode-X" fake-planar.

There are tables of register values in the option ROM. I don't have the patience to reverse-engineer enough of it to identify all of the tables or exactly which register is which.

All standard VGA modes should have the same values in the extended registers, whether they're planar or not.

Found it! The solution of this riddle is an innocent looking bit in one of the clock control registers of the CRTC that reduces the memory access cycle count from 3 to 2. The additional cycle is required to perform the VGA "address bit shuffle". With the bit cleared, the VGA memory bitplane shuffle works. Unfortunately, the maximum addressable memory of a bitplane is then limited to 128K, as per GDC 06.

Seems the sprite/hardware cursor seems to be affected by the VGA bit shuffle as well, but it's not unusual that the sprite doesn't work in planar mode.

thorfdbg wrote:Unfortunately, the maximum addressable memory of a bitplane is then limited to 128K, as per GDC 06.

The option ROM can set up 1280x1024, which would require a 160k bitplane, so there must be a way to do it. I'd guess the ROM uses a 64k window and writes to CR6A to swap banks, but the datasheet isn't very clear and I haven't disassembled the ROM to check.

Do I assume correctly that the video bios is designed to be used in real mode only? In such a case, you would need 64K windows anyhow to access the graphics?

BTW, does anyone know more details on the interrupt and vertical blank capability of the Virge3? Strangely enough, the vertical blank bit of "InputStatus1" seems to be non-operational, and vertical blank interrupts are neither being generated.

thorfdbg wrote:Do I assume correctly that the video bios is designed to be used in real mode only?

It's designed to be called in real mode, but it's assumed that the OS will run in whichever mode is most convenient and only switch to (or emulate) real mode when it needs to call the VBE functions.

VBE 3.0 has optional protected mode support, but I don't know if any ROMs ever implemented it.

thorfdbg wrote:In such a case, you would need 64K windows anyhow to access the graphics?

The ROM needs it, since the ROM runs in real mode, but you don't need it. You can tell the ROM to set up a mode that uses a linear frame buffer. Of course this assumes the hardware supports a linear frame buffer; the datasheet implies that you can't have a linear frame buffer in planar modes.

thorfdbg wrote:BTW, does anyone know more details on the interrupt and vertical blank capability of the Virge3? Strangely enough, the vertical blank bit of "InputStatus1" seems to be non-operational, and vertical blank interrupts are neither being generated.

Section 12.7 of the datasheet is pretty clear on how you enable the vertical blank interrupt, but you won't see anything happen until you configure your interrupt controller(s) appropriately. How are you configuring the interrupt controller?

Octocontrabass wrote: The ROM needs it, since the ROM runs in real mode, but you don't need it. You can tell the ROM to set up a mode that uses a linear frame buffer. Of course this assumes the hardware supports a linear frame buffer; the datasheet implies that you can't have a linear frame buffer in planar modes.

Well, I'm not quite sure where the manual states that. I can (by means of GR6) get a 128K "linear"/planar frame buffer, but that is as far as it gets. As soon as I enable the "linear" mode by means of LAWControl/CR58, plane addressing is gone and I am more or less back to a plane-interleaved "mode X" like frame buffer.

The Cirrus chips have an additional bit that extends the VGA memory to 256K by disabling the adress wrap-around. There is a similar register for the VirGE (CR31 bit , except that clearing it gives only 128K, whereas setting it gives you only a 64K window. SR4 bit 1 (ext mem) is of course set.

Octocontrabass wrote: Section 12.7 of the datasheet is pretty clear on how you enable the vertical blank interrupt, but you won't see anything happen until you configure your interrupt controller(s) appropriately. How are you configuring the interrupt controller?

Not clear enough, I afraid. It does not mention additional interrupt sources (LBP) you only find after reading the additional section about the MMIO registers, and it does not state how the MMIO interrupt handling interacts with the old-style I/O VGA interrupt handling, e.g. if the VSP bit is set in case of an MMIO interrupt as well and whether I need to clear the interrupt bits there as well.

The problem is not so much that I do not get interrupts - the problem is that when I get them, the corresponding I/O or MMIO registers do not indicate that there actually was an interrupt. Thus, I cannot clear the interrupt as the same interrupt line is also used by other sources in the system. In fact, the MISC and INPUTSTATUS1 bits are all bogus and read all zero, so I cannot even busy-wait for a vertical blank, and the same goes for the MMIO registers.

No, the chip does not sit behind a traditional PIC, it is not in a PC system here. It sits behind PAULA, but the problem is not at this end. Other interrupt sources on the same bus work, and even the Virge seems to trigger interrupts, just that I do not get a reliable status that they have been triggered. In fact, once VBlank has been triggered, the system is locked as the interrupt is coming back after the interrupt service routine as the interrupt status does not indicate a pending interrupt source at all.

Update on this: Actually, I moved now the ViRGe interrupt to the very end of the interrupt chain, so every valid interrupt from any other hardware is filtered out before the code checks the ViRGe. However, as stated, the wierd thing is that even though the vertical blank IRQ arrives at the code, the corresponding ViRGe registers (both legacy I/O and the MMIO status register) do not indicate the presence of a vertical blank.

Weird stuff. I wonder whether this is due to some erratum of the chip.

thorfdbg wrote:Well, I'm not quite sure where the manual states that. I can (by means of GR6) get a 128K "linear"/planar frame buffer, but that is as far as it gets. As soon as I enable the "linear" mode by means of LAWControl/CR58, plane addressing is gone and I am more or less back to a plane-interleaved "mode X" like frame buffer.

Right. The description of CR66 says bit 0 must be clear in planar modes, but elsewhere the datasheet says CR66 bit 0 must be set for linear addressing. This suggests that linear addressing isn't possible in planar modes. Banked addressing should still be possible, but again, I haven't examined the option ROM to see how it works. (My guess is it sets CR31 bit 0.)

thorfdbg wrote:Not clear enough, I afraid. It does not mention additional interrupt sources (LBP) you only find after reading the additional section about the MMIO registers, and it does not state how the MMIO interrupt handling interacts with the old-style I/O VGA interrupt handling, e.g. if the VSP bit is set in case of an MMIO interrupt as well and whether I need to clear the interrupt bits there as well.

If CR66 bit 0 is clear, the only interrupt source is vertical retrace, you can control its generation through CR11, and you should see its status through input status 0 bit 7.

thorfdbg wrote:The problem is not so much that I do not get interrupts - the problem is that when I get them, the corresponding I/O or MMIO registers do not indicate that there actually was an interrupt.

Do you get sensible values when reading other VGA registers?

Right, I should see a pending interrupt in inputstatus0 bit 7, but I don't. The register just remains 0. I also should see it (for the enhanced modes) in MM8504, but I don't. The bits remain zero, but the interrupt comes. So, in a sense, I can turn on interrupts, it's just a "blind flight".

Other VGA registers work. So for example, in the interrupt code, I can read the CRTC index register (which I need to save as I need to update CR11 to clear the interrupt status), and also clearing the interrupt through CR11 works.

thorfdbg wrote:Other VGA registers work. So for example, in the interrupt code, I can read the CRTC index register (which I need to save as I need to update CR11 to clear the interrupt status), and also clearing the interrupt through CR11 works.

Does reading other VGA registers in the 0x3C0-0x3CF range work? Other than some kind of errata, the only explanation I can think of is that some other device is responding to reads at those addresses.

It's unlikely that there is a conflict because the S3 sits behind another decoder on the bus, shifting its addresses to a unique I/O space, so its separate from all other expansion cards. It seems I can read from the GRx index and data registers, so that's fine. I can also write to feature control register at 3DA, but if I read from input status 1 at the same port, I get only zeros, including the reserved bit 2 which is supposed to be hard-wired to 1 according to the manual.

I can also read from all memory mapped addresses, i.e. like the stream processor window position, and I get the results I wrote back. But if I read from the status register MM8504, even in enhanced mode, the pipeline fill level is provided just nice, but the interrupt bits are all zero. However, if I just leave the interrupt handler without clearing the interrupt (i.e. writing a 1-bit into bit 0 of MM8504) the interrupt comes back, so it is definitely pending. However, neither MM8504 nor input status 1 bit 7 indicate that there is an interrupt pending - they are both 0.

Thus, I wonder whether there is either a chip erratum that leaves these bits zero, or whether there is some other form of switch that I need to trigger to make the IRQ visible to the CPU.

Okay, that's really weird.

But, since you mentioned a missing switch, the datasheet says the PC-compatible option ROM is supposed to configure everything so that interrupts are usable in VGA-compatible modes. If you really are missing something, you should be able to find it by looking at how the option ROM sets the mode.

The problem being: There is no "Option ROM" in my setup. The chip does not sit on a PC graphics card, and not in a PC system, and it is not driven by an x86 CPU. That is, I have to initialize the chip myself. All of it.

Yours doesn't have an option ROM, but the ones sold as PC expansion cards did have option ROMs, and you can find copies of those ROMs available for download.