I know that Windows 95 can use the Windows 3.1 drivers for the extended video modes, but the vanilla ET4000 driver for Windows 95(that RTM installs by default) only allows 640x480x16 and 800x600x16. Is there a way to make it support all possible graphics modes, like WhatVGA can(up to 1280x1024x16, 1024x768x256, 800x600x64K, 640x480x64K, 640x480x256col, 800x600x256col and all other compatible modes with enough video memory(1MB))?
Well, it's not a physical machine, if that's what you mean. I'm running Windows 95 RTM inside my UniPCemu emulator. It's graphics card is a regular VGA-based(with Tseng Adjustments of course, where needed only) ET4000 chip with 1MB VRAM and with the Sierra Hi-color DAC (mask 0xE0 on the DAC command register) as it's DAC. It's BIOS is a regular ET4000AX one. Like I said, Windows 95 doesn't support the extended modes out of the box it seems? Is there a way to make the slider in the settings go all the way to 1280x1024 and the color depth settings from 1-bit to 64K colors? For some reason I can only do that by installing the Windows 3.1 drivers each time I want to change display resolution or color depth?
I tried changing the monitor from none to the various SVGA ones(UniPCemu supports up to just below ~4K in it's framebuffer(2048x2048), except on the PSP(where it's only 1024x1024 due to memory limitations)) but it didn't seem to have much effect as far as I remember?
Since it is being emulated, is there a specific reason you have to have it be an ET4000 ?
Well, the only other option in that case is plain VGA, which has two options: 640x480x16 and 640x480x2 (b/w). The ET3000 graphics card seems to have a few issues with various higher graphics modes (using both Windows 3.x and WhatVGA testing), while the other graphics cards don't work at all (EGA doesn't POST for some weird reason) or aren't supported by Windows 95 (CGA(640x200 isn't enough)&MDA(no graphics modes)) at all.
cyclone3d wrote:
Hmm.. Well, I was looking around last night and it looks like Windows 95 should support the higher resolutions / color settings out of the box.
Guessing it is something to do with it being on an emulator / vm.
But what could be the cause in that case?
One thing I weirdly do notice is that the Windows 95 hardware autodetection detects the ET4000 as a plain VGA graphics card, even though afaik I've implemented pretty much all ET4000 hardware I/O functionality(and even using the ET4000AX BIOS). So why would it still think it's a VGA graphics card?
Will a W32/p/i driver even work on a ET4000AX? All those MMIO registers and the memory map register(for the 1MB window mapped from 1MB up to 16MB(according to WhatVGA)) aren't supported by the ET4000AX chipset.
I'm not sure if it will work or not. I just kept coming across posts that all said to use the W32/i/p driver for the AX cards.
The Winport2 driver is some driver pack that supports multiple video cards that I guess came with some sort of capture device or something. At least that is that it looked like to me from the readme in the accompanying disk 1 zip file.
Just tried the W32/p/i driver. It crashes Windows at 2F7:264B, executing a TEST ES:[7f36],02. The ES descriptor cache contains a base of 0, limit of 4GB, but a access rights field of 0x14, which means it was originally 0x94, but having cleared it's present bit due to a privilege level change from CPL 0 to CPL 3(RETF/IRET)?
So, with said driver installed, it crashes with a BSOD executing said TEST instruction. Although that Not-Present ES descriptor is weird in and of itself?
Just have been looking at the ET4000 emulation and ET3000 emulation... Then I noticed that CRTC registers 0x33 and 0x35 were writable, but not readable when the KEY isn't set. And the documentation, as well as the various detection schemes I can find of the hardware say they're writable and readable always, even if the key isn't set(and use it to detect the hardware). That's a small hardware bug out of the window! 😁
Edit: Also implemented the missing emulation of the requirement of the 3CD register(Segment Select Register) to require that the KEY has been set at least once since the last Synchronous Reset(and Halt, which is triggered by clearing Sequencer Register 0 bit 1) or power-on of the graphics card. I used to have this half implemented(by requiring the KEY to be set to access it), but that seems to have been incorrectly emulated in that way(it's obvious why).
Just found more Tseng bugs: The ATC flipflop wasn't working for registers 16h/17h.
Also, the CGA/MDA mode control registers and Extensions Enable scheme(of the same I/O ports) didn't follow the Misc Output Register's mono/color bit.
That makes me wonder: what about the CGA color register? Does it disappear in mono mode as well?
Edit: What about the ET4000 KEY being set/reset? Is that applicable to the ET3000 as well?
Edit: Hmmm... Looking at what the ET4000 BIOS emits, I see something strange. The enable of the KEY is done normally. But it looks like the disabling of the key(if it's that?) is done in reversed order? I see it writing 1 to the Hercules register(3BF), then 29h to the Mode Control Register, not the other way around(as the WhatVGA tseng.txt documentation says)?
After making the order of those the same as on the KEY enable sequence(first port 3BF, then port 3#8, the enable and disable sequences all seem to work properly.
Then I found out, when running WhatVGA's 800x600x64K color mode, that the disabling of port 3CD(The Segment Select Register, which is done by a Synchronous Reset(TS register #0 bit 1 being set to 0(probably not just toggling it to 0 but any time it's written as 0)) also seems to disable the value that's within it as well. So even though the register still has some value in it, it won't have any more effect on the VRAM window provided by the graphics card to the CPU?
Having made said register unavailable and unused when the KEY isn't set after such an reset or power-on, the hardware seems to behave properly(at least in MS-DOS and WhatVGA)?
Hmmm... Having changed the Windows 95 drivers back to it's factory default ET4000 one, it complains about there being a problem with the display settings? The only choices are still 640x480x16 and 800x600x16. No higher or lower color modes, nor other display resolutions are available?
Edit: Trying autodetection(I'm trying to reinstall the graphics card drivers automatically), at 0%(it seems) I get a "failed to allocate memory for it's own internal use" error message from what seems to be the hardware detection wizard?
Edit: Rebooting after adding the ET4000 manually went fine. Until I tried to open the display properties screen(right clock on desktop, properties, final tab) at which point it complained there was an issue with the video driver/card?
Hmmm... Having disabled the (documented by the ET4000 chip programmer's reference manual 1990) disabling of the 3CD register whenever the bit 1 of TS register 0 is cleared(not taking bit 0 into account), it now shows settings up to 32-bit color depth, even though the DAC only supports up to 16-bit?
OK. So far, 16-color and 64K color modes seem to work on the default Windows 95 ET4000 driver(removed the 3CD disable toggle from the Sequencer Register 0 bit 1 set to 0). Now going to test 256 colors. Weirdly enough, it also displays 24-bit colors, which the DAC doesn't even support(is that remapping 24-bit to 16-bit or actual 24-bit DAC invalidly detected?)?
Edit: 256 colors 640x480 works... Sort of... It keeps changing display resolution(CRT timings) and perhaps also color depth while booting to the desktop. After that, it's behaving properly(at least while opening the shutdown dialog and shutting down Windows).
Still odd that there's a 24-bit color mode, even though the DAC doesn't support it? Perhaps some translation is done by the driver, mapping 24-bit colors onto 16-bit ones? Do you know anything avout it?
(It uses a Dosbox originated(for it's documentation Sierra Hi-color DAC, with mask 0xE0, having all said 3 bits functionality emulated, supporting 8-bit(VGA-compatible)/15-bit/16-bit modes(selected by the upper 2 bits combined) and DAC-based 4-bit(for 8-bit colors) or 8-bit(for 16-bit colors) latching(as selected by setting bit 5 of the DAC command register(set latching 2 4-bit or 8-bit pixels to 1 8-bit or 15/16-bit double plotting pixel)).
Just have been looking at the RAMDAC.TXT documentation(https://www-user.tu-chemnitz.de/~kzs/tools/wh … tvga/ramdac.txt ) as well as the testdac function of whatvga ( https://www-user.tu-chemnitz.de/~kzs/tools/whatvga/idvga.pas ). Then, when looking at the failing DAC detection(detected as OAK 66HC in WhatVGA when using the RAMDAC.TXT documentation of the SC11487, I noticed something when comparing them: bit 3-4 is supposed to be redirected to the actual DAC Mask Register bits. But when WhatVGA tests bit 4 for trying to set it(before that clearing the DAC Mask Register bit 4), it notices that the bit is set(due to the redirect being both readable and writable), while that shouldn't happen(in other words: the redirect happens for reads, but is Read-only for writes!).
So, simply adding a bit to the documentation on bits 3-4 for the Sierra chips by looking at the WhatVGA IDVGA.PAS source code: those bits are actually read-only bits, not writable(which isn't documented in any documentation, including Dosbox's(which doesn't even emulate the full register anyways). Dosbox uses a copy of the very same documentation).
Original documentation:
1HiColor DACs: (Sierra SC1148x, MUSIC MU9C4870, OAK OTI66HC, UMC UM70C178) 2 3REG04 (R/W): Overlay RAM Write Address (SC11481/2/4/5/8/9 only) 4bit 0-3 Write index for the Overlay registers. 5 6REG05 (R/W): Overlay RAM (SC11481/2/4/5/8/9 only) 7bit 0-5 Data port for the overlay registers. Works like the PEL data register 8 (3C9h) except that the overlay registers are accessed and the Overlay 9 Address registers are used for indexes. 10Note: on the SC11484/8/9 the Color Look-up Table and the overlay registers are 11 24bits wide (rather than 18bits) if the 8/6 pin is high. 12 13REG06 (R/W): Command Register 14bit 0 (SC11487) (R) Set if bits 5-7 is 1 or 3, clear otherwise 15 3-4 (SC11487) Accesses bits 3-4 of the PEL Mask registers (REG02) 16 5 (not SC11481/6/8) 17 If set two pixel clocks are used to latch the two bytes 18 needed for each pixel. Low byte is latched first. 19 If clear the low byte is latched on the rising edge of the 20 pixel clock and the high byte is latched on the falling edge. 21 Only some VGA chips (ET4000 and C&T655x0) can handle this. 22 6 (SC11485/7/9, OTI66HC, UM70C178) Set in 16bit (64k) modes (Only valid 23 if bit 7 set). On the SC11482/3/4 this bit is read/writable, but 24 has no function. On the SC11481/6/8 this bit does not exist. 25 7 Set in HiColor (32k/64k) modes, clear in palette modes. 26Note: This register can also be accessed at 3C6h by reading 3C6h four times, 27 then all accesses to 3C6h will go the this register until one of the 28 registers 3C7h, 3C8h or 3C9h is accessed. 29 30REG07 (R/W): Overlay RAM Read Address (SC11481/2/4/5/8/9 only) 31bit 0-3 Read index for the Overlay registers.
My improvement:
1HiColor DACs: (Sierra SC1148x, MUSIC MU9C4870, OAK OTI66HC, UMC UM70C178) 2 3REG04 (R/W): Overlay RAM Write Address (SC11481/2/4/5/8/9 only) 4bit 0-3 Write index for the Overlay registers. 5 6REG05 (R/W): Overlay RAM (SC11481/2/4/5/8/9 only) 7bit 0-5 Data port for the overlay registers. Works like the PEL data register 8 (3C9h) except that the overlay registers are accessed and the Overlay 9 Address registers are used for indexes. 10Note: on the SC11484/8/9 the Color Look-up Table and the overlay registers are 11 24bits wide (rather than 18bits) if the 8/6 pin is high. 12 13REG06 (R/W): Command Register 14bit 0 (SC11487) (R) Set if bits 5-7 is 1 or 3, clear otherwise 15 1-2 (SC11487) unused, but stored 16 3-4 (SC11487) (R/O) Accesses bits 3-4 of the PEL Mask registers (REG02) 17 5 (not SC11481/6/8) 18 If set two pixel clocks are used to latch the two bytes 19 needed for each pixel. Low byte is latched first. 20 If clear the low byte is latched on the rising edge of the 21 pixel clock and the high byte is latched on the falling edge. 22 Only some VGA chips (ET4000 and C&T655x0) can handle this. 23 6 (SC11485/7/9, OTI66HC, UM70C178) Set in 16bit (64k) modes (Only valid 24 if bit 7 set). On the SC11482/3/4 this bit is read/writable, but 25 has no function. On the SC11481/6/8 this bit does not exist. 26 7 Set in HiColor (32k/64k) modes, clear in palette modes. 27Note: This register can also be accessed at 3C6h by reading 3C6h four times, 28 then all accesses to 3C6h will go the this register until one of the 29 registers 3C7h, 3C8h or 3C9h is accessed. 30 31REG07 (R/W): Overlay RAM Read Address (SC11481/2/4/5/8/9 only) 32bit 0-3 Read index for the Overlay registers.
Hmmm... With those latest changes, it now detects a Sierra Sc11483. So that means that, for some reason, the x and y values(DAC MASK register 0xFF, command register to 7F becomes 7F, command register to FF becomes FE) aren't correctly becoming FF and FE in that case? Hmmm...
Edit: Changing the bits (bits 3-4) to be R/O fixed detection by WhatVGA. It's now properly detecting it as as Sierra SC11487.
Edit: Also noticed I still had the 0xE0 mask on the value written to the register, while it should have no mask(except the bits 3-4 being turned off for replacement with the DAC Mask Register's bits when reading the DAC Command Register).
Just tried switching it back to 16-color mode... It looks fine from the hardware perspective, except that the Palette Registers are somehow messed up? It all contains garbage(00,0c,0a,0e,01,15,23,07,0f,24,12,36,09,2d,1b,3f). The DAC looks like it contains it's normal values(the usual 16 colors, at least in the first 16 entries).
Edit: Perhaps it was actually the '32-bit' color mode as I was testing the different color modes selectable in the Display Properties window.
Edit: Hmmm... Tried running it in 16-bit color mode again. Those 'garbage' registers are still there. but the display is normal? Hmmm...
The attribute is set up the same. So is the attribute controller toggle register.
So, the mode is just a plain 16-color mode(when set to 32BPP in the settings), except that the software is somehow rendering 32BPP pixels into VRAM(which are rendered as 16BPP pixels in some weird way(1BPP parallel planes to 4-bit pixels))?
So, in short, is there a way to make Windows 95 recognise my emulated RAMDAC (which is said Sierra chip) to work properly?
Edit: One strange thing about Windows 95's Tseng ET4000 driver, is that somehow I keep getting repeated display changes(halving/doubling) while clicking things and opening stuff(e.g. applications, display settings etc.). Also, the display seems messed up?
Edit: Hmmmm... The 8-bit color mode is set, but the load rate and memory address clock are set for the character clock.
Edit: Hmmm... I do see a lot of Sequencer Register 4 updating the CRTC precalcs?
Edit: Strange. The Sequencer Memory Mode register keeps toggling between values 6 and 0xE. So it keeps enabling and disabling the Linear Graphics mode emulation(which has not only effect on the display memory aperture mapping(triggering Chain-4 addressing, Tseng-style), but (think about it) also display generation itself(due to Linear Graphics mode switching between linear graphics mode and planar mode!!! )). That isn't supposed to happen, I think?
