Interestingly enough, when Windows 95 boots, I seem to see at least part of the detection routine (on inspecting the values written to the DAC command register only) happening as well?

So the Tseng BIOS seems to be an indication of how both the Dosbox (both Dosbox-X and official Dosbox 0.7X) and UniPCemu UMC/SC11487 DACs deviate from the real chips?

I see one weird part of code in the ET4000 BIOS: it sets the high 3 bits of the command register and expects the Sierra Hi-color chips to not set all 3 top bits not to be kept set?

Edit: Looking aty documentation again, it's actually saying it's a "Sierra Mark2 (15-bit) or Mark3 (15/16-bit) DAC". So the BIOS is seemingly detecting it correctly? It's just Windows 95 that isn't detecting it?

Now then, why does Windows 95 think that the DAC is a 24-bit one? Does Windows 95 have some weird DAC detection routine?

I have no idea why your win95 thinks you got a 24bit dac, I would guess the driver just assumes it is 24bit, but due to your post, I now know that those DACs fall under a very specific customs tarif code. 🤦

https://eur-lex.europa.eu/legal-content/NL/TX … 6PC0578&from=EN Search for 20C490

weedeewee wrote on 2021-02-08, 21:00:

I have no idea why your win95 thinks you got a 24bit dac, I would guess the driver just assumes it is 24bit, but due to your post, I now know that those DACs fall under a very specific customs tarif code. 🤦

https://eur-lex.europa.eu/legal-content/NL/TX … 6PC0578&from=EN Search for 20C490

🤣. Various descriptions above that already matches those DACs. Indeed, all the DACs I'm emulating, except the UMC one(and Dosbox's) match that bullet point alone. There's also the mention of multiple inputs(in other words, latching), which describes all hi/truecolor DACs.

Although not relevant with regards to detecting the hardware 🤣

Would you be interested in the Bios of an Opti Local Bus ET4000ax card ?

I wouldn't be surprised if it uses the same BIOS as what I'm testing with. Does the ROM dump contain the text "Copyright(c)1988 Tseng Laboratories, Inc. 04/07/93 V8.01X" (without quotes)? It looks like it's some generic BIOS used by most cards (due to many DAC configurations supported according to the ET4000 manual)? The disassembly of the BIOS proves that to be the case(at least the RAMDAC detection part I've disassembled). It has all the 8.00+ cases in it, just not the special 02h case (using the 8.00+ instead of the SS24 one).

It does report 02h for the sierra DACs, though. So does the Windows 95's MS-DOS prompt running my polldac app(assembler code for nasm compilation can be found in the UniPCemu assembly folder). It's a very simple app that executes said bios call, converts the BL register to hex, prints it to the screen using MS-DOS, adds CR&LF and finally quits the program.
Weirdly enough, no other sources exist for such information(testing/diagnostic apps), other than WhatVGA.

Edit: After small 'fix', applying terminating the command register(as WhatVGA UMC and SC11487 documentation says(but not WhatVGA SC1148X/UMC line further up in the documentation RAMDAC.TXT)), I now receive the following results (For the SC11487 in UniPCemu):
- Simcity 2000's UniVBE driver: Hi-color 15-bit DAC
- BIOS: Still 02h(given by polldac program).
- Windows: Untested so far. Will update when done.

Nope, this Bios one is a an older one.

opyright(c)1988 Tseng Laboratories, Inc. 07/01/91 V2.00X

Then it could be that it doesn't even support all mentioned DACs?
The AT&T 20C490 falls under the V8.00+ BIOS results. So it'll only report 00h and 01h(since 02h and up fall under special(02 case for specific card) and V8.00(02 sierra and 03+).

Now going to check Windows 95 with the write fix(missing in Dosbox, implemented in UniPCemu). UniPCemu also, for the sc11487, has bits 0(r/o, depending on bits 5-7) and 3/4(r/o in command register mode) implemented as documented in WhatVGA and RAMDAC.TXT.

Could very well be... I've got the drivers as well with it... but... they're on 5"1/4 discs. No idea if it's HD or DD and I only have one 360K 5"1/4 drive

anyway, it's attached, so if you want to test/disassemble it... enjoy ! 😀

Well, still don't know if I can share my disassembled work for the RAMDAC BIOS code here, since I don't know how the forum rules apply to it (see my other thread on that).
I think i'll put it on my dropbox for now. Link once ready.

Edit: The link: https://www.dropbox.com/sh/roh23x0nkj2e4bm/AA … g0B5Fx1LLa?dl=0

It immediately takes me to the mentioned code. Scroll up for the start of the detection(the top block, int10_detectDACtypetoAL, is where DAC detection starts).

someone in the other thread suggested putting it on github.

Noticed one other little thing after the RAMDAC command register write returning to normal mode(it's the wording for 'returning to the PEL mask register state' in the documentation of the chips themselves I could find(all but the UMC chip)).

Besides the Simcity 2000 UniVBE driver now reporting a 15-bit DAC, Windows 95's command prompt(within running Windows' window) running the polldac program reports 01h from the 'ET4000' BIOS. Although I think that's the ET4000 windows driver talking, seeing as the BIOS still reports 02h in MS-DOS 6.22 running it in real mode.

Windows 95 still gives the 'option' for 24-bit color depth. Although it won't be able to set it properly, causing nasty display issues(displaying the wrong information because it's rendering 24-bit in VRAM and the DAC not being in an existing 24-bit color mode(15-bit with 2 clocks/color to be exact, due to setting the register to E0h).

Well, it could be faux-24 bit, since 18bit color depth is neither here nor there.

Real mode(MS-DOS 6.22) polldac still reports o2h.
WhatVGA 2.00 says Sierra SC11487.
UniVBE says "HiColor 15 bit DAC" (w/o quotes).

There's still the weird case of bits 1-4 in the RAMDAC CMD register.
WhatVGA says that bit 3-4 are the PEL mask bits. But clearing those in the PEL register and then setting it in the CMD register with the CMD register, finally reading it back set(bit 4) causes WhatVGA to detect a "'Trident TKD8001" instead.
WhatVGA says this:

bit 0 (SC11487) (R) Set if bits 5-7 is 1 or 3, clear otherwise
3-4 (SC11487) Accesses bits 3-4 of the PEL Mask registers (REG02)

But it's source code disapproves about bit 4?

WhatVGA's code at https://www-user.tu-chemnitz.de/~kzs/tools/whatvga/idvga.pas at least approves of the bit 0 behaviour.
But, for the SC11487, bits 1-4 could all simply be a r/o passthrough to the DAC mask register. Bit 4 at least has to be(for that detection to work). But bits 1-3 are either always set, probably fully settable(documentation says nothing on it) or more simply all passed through to the PEL mask register?

Edit: It also looks like bit 0 on the SC11487 is only set when trying to use two clocks per pixel without 16-bit color mode active(latching 2x8 bit for an 8-bit PEL mode). And of course that's invalid to do. So it sets bit 0 in that case. So it's kind of an error flag.
Edit: Hmmm... Case 01h is invalid in this case and 02h is correct: 01h is a SC1146[1/6/8], which this isn't(SC11487).
Edit: Just have been searching some more. Eventually found the dr Dobbs journal entry on it's detection:
https://www.drdobbs.com/database/sourcecode/g … amming/30401306

It does this:
It switches to DAC mode, sets the command register to 0x00 and DAC mask to 0xFF, switches to command register and expects it to not be 0xFF(the mask). It also notes that the 0 in the command register should be read back.

So when both that and WhatVGA is supposed to work, since the DAC mask is fully set and clearing it should clear bit 4 according to WhatVGA, while setting the mask register but clearing the command register should read back 0x00, that would mean that the command register bits are mostly running normally(returned as-is). The only exception being bit 0(the error bit) and bit 4(which needs to clear in the read result if the mask bit is also cleared). So the bits in the command register is to be written normally, but the reading of bit 4 would have to be masked by the clearing of the mask register. That way, both cases would work as documented?

Just modified the DAC mask register bit 4 to mask the DAC command register instead of being a ROM bity in the DAC command register. Bit 3 is behaving normally, only being in the DAC command register now.
Bits 1&2 behave as they've always been.

In fact, now all bits, except bit 0(the error flag), are now stored in the register. But when the register is read(on a SC11487), the register bit 4 returned to the CPU is masked with the DAC mask register. That would allow WhatVGA to detect correctly, but also allow the Dr Dobbs journal to be correct.

I now see something interesting happening on Windows 95. Trying to set the 24BPP mode will make it give a message that the mode isn't supported. It'll still show it, but it won't be able to set it, behaving gracefully.

Simcity 2000's UniVBE driver still detects a 15-bit DAC. Although Simcity 2000 doesn't seem to actually use it? I seem to remember it did actually use it sometime in the past(before becoming more accurate)?
The MS-DOS prompt in Windows 95 running the polldac program returns 02h, which is correct.

Edit: Hmmm... UniVBE Pro from the 11th hour game seems to detect a SC11483/5/9 chip instead of a SC11487 now?
Edit: A small redetection by running the config tool fixed that.

Then I made the DAC mask register affect more bits on the DAC command register(bits 1&2 added).

Just optimized the bit 0 calculation a bit using pure bitwise operations. Simply shift the written register right 2 bits(to get the two bits to compare for set(bit 5) and not set(bit 7) to line up at bit 5 for comparison), xor it with the AND of the written register bit (the AND to filter out the single bit from the operation) to get the bit 5 set with bit 7 not set case only(thus resulting in 0x20(top 3 bits being 001b or 011b) and 0x00(all other cases)), then shift right by 5 bits to get it into bit 0 and or it into the register with bit 0 masked off(to set said bit to the documented value).

Originally did it with an if-statement(val&0xe0=0x20 || val&0xe0==0x60), but then optimized it to val&0xa0==0x20 and finally to what's mentioned above:

1		//It appears that bit 0 is a flag that sets when 16-bit mode isn't selected and 2 pixel clocks per pel are selected, which is an invalid setting.
2		et34kdata->hicolorDACcommand = (et34kdata->hicolorDACcommand&~1)|((((val>>2)^val)&(val&0x20))>>5); //Top 3 bits has bit 7 not set while bit 5 set, moved to bit 0?

Got to love bit magic!

Anyone knows anything about how the bits 1-4 work on the Sierra SC11487?
I can't seem to find anything about them. Only WhatVGA sees a SC11487, all others see a "15-bit DAC" or one of the other models?

I know that the config utility of the 11th hour game seems to detect it correctly. But all others report case 1 it seems(Simcity 2000(15-bit DAC), BIOS correctly(polldac reports case 02h), Windows correctly(when setting the monitor to 24-bit BPP, it refuses when pressing OK) as well as incorrectly(polldac reports case 01h in the Windows MS-DOS prompt window).

Hmmm... When I run uvconfig.exe inside the 11th hour folder and select a different chip, then run it again, it really seems to autodetect the "SC11485/7/9 16-bit DAC" chip as it calls it. So the chip emulation itself seems to be fine?
It's just that the UniVBE driver inside Simcity 2000 doesn't seem to further recognise the chip and simply reports it as a "HiColor 15-bit DAC", as it's the closest equivalent it can display (and perhaps even detect, as it doesn't do more fine grained detection).

All that's left is to verify it in Windows 95.
Edit: It applies the 24-bit mode when clicking the apply button. It requests to reboot, which renders an incorrect mode when booting Windows again... It looks like 24-bit graphics mode with 8-bit DAC mode, which is incorrect? The DAC command register is 00h, so in 8-bit mode?