VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

What is the difference between the high-resolution 8-bit attribute mode and the normal 8-bit attribute mode control register latching bit?

It must have an extra function or something like that for attribute register 16h to have a duplicate function?

This is what I could find out about the Tseng chipsets(ET3000/ET4000) from the ET4000 programmer's reference manual(what's at least scanned correctly at least, parts are not readable due to scanning errors):
DotClock/2 (Seq 01 bit 3, value 8 )=Doubles width from 320 to 640 pixels. Only set with CGA/EGA 320 16-color pixel modes?
Attribute mode ctrl register bit 6(value 0x40)=Halves the rate of pixel output to the screen. 4 instead of 8 pixels per character clock. So one pixel rendered every 2 pixel or dot clocks? Only set in 320x200x256? Sounds like the normal (latching) operation of the VGA (attribute controller wise)? This seems to be the same required for the Attribute Controller 16h's high resolution 8/16-bit modes to function?
Attribute controller 16h bits 5-4. When bit 4 is set, 256-color/64k(Hi-color) highres/hi-color mode. Hi-color mode when bit 5 is set as well. Nothing is explained in the manual? It's seemingly never used in the register settings given?
GDC 05h bit 6=256 color mode. Nothing explained about it in the manual? Set with all 256-color modes. I assume this makes the sequencer behave like the VGA does as well with this bit. Otherwise, nothing is known about it(attribute controller/DAC inputs/screen timing)?

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

Reply 1 of 4, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've tried to make an estimation on how all VGA and SVGA clocks interoperate(mostly how UniPCemu operates as well, with exception to the dot clock divided by 2 and DAC operation clocking(based on attribute stalling only, the noted "dot clock" has a seperate source based on the MCLK(may be divided by 2) of the Sequencer stage provided by the CRTC timing algorithms)):

The attachment (S)VGA timing relations.zip is no longer available

Can anyone confirm this behaviour?

The divide dot clock by 2 is a strange one. In order to work properly, the DAC needs to depend on the Attribute controller(and 256-color mode setting by the Attribute controller) in order to properly stall and not send any new pixels on the screen for the duration of the attribute controller latching? The dot clock divide by 2 then needs to apply to the clock sent to the DAC as well(for the DAC to double the pixels only after the attribute controller has latched the second pixel)?

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

Reply 2 of 4, by superfury

User metadata
Rank l33t++
Rank
l33t++

Managed to get the timings in the document working.

Although I did need to halve/quarter the DAC output pixels multiplier at the end for 320x200 32k/64k two pixel latching modes by using the MCLK/2 and MCLK/4 divider in the Sequencer register 07h when the DAC is operating in 15/16-bit mode, as all other registers apparently can't be properly used for detecting this case. Otherwise, the display would become around 350 pixels wide instead of the proper 800 pixels(VGA display resolution afaik is 800x600).

Having implemented those, now all color modes tested by WhatVGA (including the new 24-bit modes on the new DAC) work properly. All that's left is to check whether Windows 95 is still running properly with it.

Edit: Still running! 😁 Now all color modes should work without issues! 😁

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

Reply 3 of 4, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.. Slightly related. Can Disney's Villain's revenge for Windows 95 support the 24-bit true color mode? The manual and software says it needs 16-bit or 32-bit modes?

Edit: It runs in 16-bit color depth. It does give a "Bad stop code" error before displaying the sound test menu, though?

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

Reply 4 of 4, by superfury

User metadata
Rank l33t++
Rank
l33t++

Eventually managed to make it a bit more simple to render without dividing the output for the 8-bit modes and up for most of the time.

Now, all modes render to the screen with a 1:1 ratio of rendered pixels. The only exception is the 24-bit color mode (active display pixels rendered at 3:1 ratio, with both active display and overscan being rendered at a 3:1 ratio).
Then, there's some slight doubling/quadrupling being applied during active display when the DAC isn't in 16/24-bit mode on the Tseng chips (ET3000/ET4000):
MCLK/2 and MCLK/4 (TS register 07) double and quadruple(respectively) the rendered pixels when in 8-bit mode without linear mode.
MCLK/2 and MCLK/4 (TS register 07) double and quadruple(respectively) the rendered pixels when the DAC latches 2 bytes per pixel and both 8-bit mode and linear mode are set.
Those are mainly for fixing the 320 pixel modes in both 8-bit VGA and 16-bit modes(modes 13h, 0313h and 0413h). Otherwise, they only render 320 pixels to the active display due to missing dot clock divide by 2 not being set.

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