VOGONS


First post, by Battler

User metadata
Rank Member
Rank
Member

On real hardware, does the the (S)VGA 256-color shift (GDC register 5 bit 6) force the video memory into Chain 4 mode regardless of sequencer register 4 bit 3? Or is that a Tseng-specific thing? Because I have two different Tseng drivers, the Windows 3.1 driver for the ET3000AX and the OS/2 "SVGA" driver that appears to be for the ET4000AX, and both seem to just expect Chain 4 in 256-color mode.

Reply 1 of 8, by kdr

User metadata
Rank Member
Rank
Member

The CL-GD542x technical reference manual doesn't mention anything like that - whereas it does specifically call out a few situations where certain bits are either ignored or take priority. Here's what it has to say about GR05 bit 6 (256-color mode):

Bit 6 (256-color Mode): If this bit is programmed to ‘1’, the Video Shift registers are
configured for 256-color Video modes. GR5[5] (Shift Register Mode) is ignored. If this
bit is programmed to ‘0’, the Video Shift registers are configured for 16-, 4-, or 2-color modes.

And SR04 bit 3 (Chain-4):

If this bit is programmed to ‘1’, A0 provides Plane Select bit 0, and
A1 provides Plane Select bit 1. This has an effect similar to Odd/Even mode,
except that both A1 and A0 are used. This bit takes priority over SR4[2] (Odd/
Even) and GR5[4]. There is not a separate bit in the Graphics Controller to
select Chain-4 Addressing, as is the case with the Odd/Even bit. The Graphics
Controller Read Map register (GR4) is ignored when this bit is ‘1’.

Reply 2 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

It's indeed Tseng-specific behaviour. All other graphic card(including IBM VGA) just use the Sequencer Mode Control register bit. Tseng also doesn't call the GDC bit by it's normal name(256-color shift mode (loading for the latches when rendering)), but calls it linear graphics(LG) mode because it also enforces CPU addressing using byte addressing mode for loading during rendering, breaking VGA compatibility with demos as is well known (which is less documented).

Tseng ET4000/W32P:
"6 Enable 256 color mode"
"Bit 6 When set to 0, permits the loading of the ATC's shift registers to be controlled by bit 5.
When set to 1, the registers are loaded to support the 256-color mode."

Note that it doesn't say shift registers the second time, probably because it does a lot more than that(chain 4 and byte addressing mode being included/enforced to be exact).
Then there's the many times it lightly documents the LG/Linear Graphics mode throughout the document in many 8-bit scenarios, which is quite confusing and only adds to the ambiguity.

TS index 4 adds to that:
"Bit 3 When set to 1, will enable Chain 4 (linear graphics) mode"

So it implies (and register dumps in the document for the various modes confirm) that the two bits are OR'ed together for Chain 4 mode to become active.
Edit: GDC and TS registers are loaded as in VGA on W32 chips. ET4000AX loads GDC and TS as VGA as well?
But, the 8-bit mode of the attribute controller mode control register is only set during mode 13h, but not all other 8-bit modes.
So according to the documentation, only the attribute mode control is different from specs, with it being setup differently by the BIOS and drivers(they also use the linear mode bit in the extended ET4000 registers instead?). It's also differing with the 8-bit and linear modes(1 clock/byte instead of 2(VGA/mode 13h) during LG mode) from VGA.

For a more simple explanation on how I implemented the various Tseng addressing modes, look at UniPCemu's tseng.c and search for the locations using the linearmode precalc.
There's a lot that's combining together to form the actual mode it seems (both for rendering and CPU):
- ET3000 1M linear memory mode(segment select register high 2 bits=2 or 3).
- ET4000 linear system configuration bit (bit 4 of system configuration 1).
- ET4000 bit 5 of system configuration 1(contiguous mode).
- Sequencer memory mode register bit 3.
- Graphics mode register bit 6.
- Attribute mode control register bit 6(having only effect on rendering).
- Sequencer clocking mode register bit 3 (and bit 1 is wrongly set instead in some modes on ET3000) for Dot Clock Rate division.
Those are all factoring in together in determining the memory map the CPU sees and how the Tseng chip addresses VRAM for rendering.
It's kind of complicated how UniPCemu combines all those, so look at tseng.c for the actual way they seem to combine (verified using the actual ET4000AX and ET3000AX BIOSes).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 8, by Battler

User metadata
Rank Member
Rank
Member

The OS/2 ET4000AX driver also writes to sequencer register 0E (which is entirely undocumented!), setting bit 1. The Windows 3.x ET3000AX driver sets bits 4 of attribute register 0x16.

Edit: And I'm running the actual BIOS'es as well. What I see, with both of those drivers, is the card being put into 256-color mode, the Chain 4 is not set, but both drivers expect it to be in Chain 4 mode anyway.

Reply 4 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++
Battler wrote on 2021-04-08, 18:50:

The OS/2 ET4000AX driver also writes to sequencer register 0E (which is entirely undocumented!), setting bit 1. The Windows 3.x ET3000AX driver sets bits 4 of attribute register 0x16.

Edit: And I'm running the actual BIOS'es as well. What I see, with both of those drivers, is the card being put into 256-color mode, the Chain 4 is not set, but both drivers expect it to be in Chain 4 mode anyway.

Forgot about attribute register 16h. But that only affects the rendering to enforce 8-bit/16-bit mode when decoding the rendering mode(the shift modes, overruling the graphics register bits for that). It has no effect on the CPU's addressing of VRAM through the MMU window.

The sequencer memory mode behaves as documented(unless overridden by some other bits to 8-bit linear mode). In this case, the linear aperture mode in CRTC 36h and GDC 05h bit 6. Bit 5 of GDC 06h has no effect on it(only the rendering mode, unless overridden).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 8, by Battler

User metadata
Rank Member
Rank
Member

But then why is it expecting to be in Chain 4 without Chain 4 being set?

Edit: So then Shift 256 is OR'ed with Chain 4? That might be true but then wouldn't the Windows 95 boot screen and Wolfestein 3D both break since I have observed both of them using 256-color planar mode?

Edit #2: Reading the above again: "When set to 1, the registers are loaded to support the 256-color mode.", this implies that the Tseng cards automatically set Chain 4 when Shift 256 becomes 1, rather than simply OR'ing Shift 256 with it. Planar modes would then work when Chain 4 is disabled. Can anyone with the real hardware confirm this?

Reply 6 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++
Battler wrote on 2021-04-09, 22:20:

But then why is it expecting to be in Chain 4 without Chain 4 being set?

Edit: So then Shift 256 is OR'ed with Chain 4? That might be true but then wouldn't the Windows 95 boot screen and Wolfestein 3D both break since I have observed both of them using 256-color planar mode?

Edit #2: Reading the above again: "When set to 1, the registers are loaded to support the 256-color mode.", this implies that the Tseng cards automatically set Chain 4 when Shift 256 becomes 1, rather than simply OR'ing Shift 256 with it. Planar modes would then work when Chain 4 is disabled. Can anyone with the real hardware confirm this?

It would be required to use said Chain 4 bit as well, since apps depend on it(in non-256 color modes it might be used after all, so it's required for VGA compatibility).
I also saw stuff like Windows drivers toggling the 256 color bits and Chain 4 bits while in 256 color displaying mode(640x480x256) causing memory addressing issues if this wasn't done(due to corrupted video memory).
Search on this forum for my posts regarding 640x480x256 colors on Windows 3.0. Noted a lot of weirdness back then before this was implemented correctly without the special modes implemented. It's also widely known that the Tseng chips have incompatible chain 4 (including byte mode).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 8, by Battler

User metadata
Rank Member
Rank
Member

I found your old posts about that stuff, and they match what I observe as well, and the OS/2 ET4000AX driver does the same thing - sets 256 color mode, without Chain 4, but expects to be in Chain 4 mode. On your end, I see that you simply patched the registers used, but there must be a better way to solve this. On my end, I simply made Attribute register 0x16 bit 4 force Chain 4 when in 256-color mode on the ET3000AX and the undocumented Sequencer register 0x0E on the ET4000AX, but I'm not sure even that is correct.

Reply 8 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++
Battler wrote on 2021-04-10, 22:17:

I found your old posts about that stuff, and they match what I observe as well, and the OS/2 ET4000AX driver does the same thing - sets 256 color mode, without Chain 4, but expects to be in Chain 4 mode. On your end, I see that you simply patched the registers used, but there must be a better way to solve this. On my end, I simply made Attribute register 0x16 bit 4 force Chain 4 when in 256-color mode on the ET3000AX and the undocumented Sequencer register 0x0E on the ET4000AX, but I'm not sure even that is correct.

What do you mean with 'Sequencer Register 0xE'? The sequencer index is only 3 bits wide on the Tseng chips afaik, so that resolves to sequencer register 6(Some 'Zoom Control Register'?).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io