Can anyone shed some light what the lower 5 bits of the command register of the SC11487 really are? Their functions and responses to input? Anyone has a graphics card with such an chip?
I think WhatVGA might be incorrect/lying about those bits(well, perhaps not bit 0, as it does have some logic)?
Edit: Implementing bit 0 and 5-7, other bits cleared caused WhatVGA to detect a SC11483 chip. Apparently 3/7/9 are not identifyable from each other? WhatVGA loses it's 16-bit modes in those?

did you ever look at the datasheet for the sc15025 ramdac?

Just read the SC15025 datasheet...
Holy ....! Those lower bits pack a lot of functionality! Although it would be interesting to emulate for it's 4-byte RGB(not RGBA) modes(UniPCemu only implements 3-byte RGB modes and RGBA using 4-bytes(although never set by the DAC emulation)). So that would make the 4-byte aligned RGB 320x200 a possibility if emulated(640x400 at the most), with the plain ET4000AX.

So, in other words, bit 4 enables extended registers at the color registers space, bit 3 enables LUT(the DAC palette registers) translation for the R/G/B inputs in 15/16/24-bit color modes, bit 0 enables extended 15-bit(in 15-bit mode) or BGR(in 24-bit mode) modes when using 24-bit pixels. 24-bit mode is set by bit 6 without bit 7(in addition to the modes WhatVGA documents for the SC11487). Bits 7&5 act as documented by WhatVGA(16/15-bit enable and 2 clocks latching for 16-bits instead of during 1 clock for 16-bits). Bit 6 enables 16-bit mode instead of 15-bit mode when bit 7 is set. Otherwise, it enables the RGB/BGR modes.
When the LUT translation in the 15/16-bit modes is enabled, bits 1&2 are shifted right(essentially) into the R/G/B inputs for 15/16-bit modes. Extended 15-bit mode just then sets bit 0 to bit 15.
The final step it seems to perform in LUT translation is putting each of the R, G and B as an index into the DAC LUT itself(accessed from ports 3c7/3c8/3c9 in VGA-compatible mode) to obtain their DAC values for the R(taking the red channel), G(taking the green channel) and B(taking the blue channel) for the actual RGB value.
And before performing any and all of the translation(for LUT mode), the entire input is masked with the 24-bit mask in the extended registers(0F0E0Dh (the numbers in xxyyzzh are the extended register numbers which fill these bits)'s value in little endian), which by default has all bits set(poweron/reset). When LUT mode isn't set(clearing command register bit 3), the mask is applied to the 15/16/24-bit input value instead.
Extended register 08h bit 0 enables 8-bit DAC when set. Registers 09-0C are ROM containing 0x53, 0x3A, 0xB1, 0x41 for identification And register 10h bit 0 adds a 4th discarded byte input in RGB/BGR modes that is discarded for a 0RGB or 0BGR mode to be createn(32BPP).

That about seems to sum it up?

Edit: Also (when the bit 4 is set at the command register):
Palette RAM write address register = Extended data registers(r/w)
Palette RAM read address register = Extended index register (write only)
Palette RAM data = Extended index register (read only)

So that's about a complete documentation in readable format on the chip specs of the SC15025's registers and it's rendering. If combined with the information about the SC11487 in the WhatVGA documents(RAMDAC.TXT), it'll be an easily parsable documentation on the SC15025 chip and how it's programmed.

I tried documenting the final functions of the Tseng BIOS a bit(mostly in pseudocode C ):
savePELAnd3C8
DACtoCMD
outb(0x3C6, CL|1);
outb(0x3C8, 2);
save3C6();
outb(0x3C6,0x77);
outb(0x3C8,0);
comparevalCH = inb(3C6);
outb(0x3C8,2);
restore3C6andPELandClear3C8();
return (comparevalCH==originalPELmask);

When it returns TRUE(zero flag set, thus comparervalCH=originalPELmask), it's a result of 9(DACtype_unknown_15_16_24bit_3).

I've updated the dropbox disassembly file of the ET4000 DAC detection with the full documentation of all the functions in the DAC detection code I added.

It now has all the functions that are in the 10F1 function call of interrupt 10h documented.

Eventually just changed the fallback to PEL mask register(a.k.a. normal mode in DAC terminology apparently) for the SC11487 to behave as it did before, then changed the ROM bits 3&4 back to the DAC mask register for the command register reads(though still written to the register, unreadable what's written by the CPU). Although this clashes with the Dr Dobbs article on the Sierra Hi-Color DAC (it isn't 0 when written 0 with the PEL mask register set).
That also fixes Windows 95 trying to set the invalid video mode when trying to set it in the display configuration. Although I have no idea what happens when it's already set (before changing the display adapter) and Windows starts booting with said mode set in it's settings. Would need to try that (set using the AT&T chip, then shutdown and change to the SC11487 chip).

I then implemented the full DAC mentioned in the SC15025 documentation above.
All modes seem to run well on that, except the 16M color mode WhatVGA reports somehow? Like the modes are refused by the BIOS for some reason?

OK. After some testing I noticed the following:
- SC11487: bits 3-4 remap to the DAC mask register as read-only bits(WhatVGA proves this in it's detection algorithm).
- SC11487 and SC15025: Both require not returning to Normal mode when the command register is written(opposite of both the WhatVGA documentation and Sierra's own documentation on said chips).
This is required for Windows and the BIOS to detect the chips correctly. Returning to normal mode makes it detect the wrong chip and apply invalid modes.

Is it correct to assume that the LUT modes only take the otherwise DAC input level(00-FF) and replace it with a DAC input level of the color RAM? So let's say the color RAM fontains the following:
00=010203h (RRGGBBh)
01=040506h
02=070809h
03=0a0b0ch

And the V stages after masking and adding the top 2 bits from the command register(and lower bit for 15-bit extended mode) yield the following values for two pixels(let's say, in 24-bit color mode):
First pixel=000102h
Second pixel=o30200h

So that would, setting the LUT bit, result in the following pixels being output on the DAC outputs:
First pixel=010509h
Second pixel=0a0803h

Would that be correct? The values otherwise sent to the DAC directly are used as entries into the color RAM, with the red channel taking the value of it's entry's red component, the blue channel taking the value of it's entry's blue component and the green channel taking the value of it's entry's blue component? So the color RAM is instead turned into a color table addressed as component[colorchannel] = colorram[component[colorchannel]][colorchannel], assuming the layout of colorram is [256(the usual palette entries)][3(the red, green, blue color channels)]?

Just improved the documentation based on the known outputs of the 10F1 function of interrupt 10h. Now, the entire DAC detection algorithm and all it's subfunctions are documented. So that would make it easy for people to figure out how the DACs are actually detected on real hardware.

Also, are there any MS-DOS games that support the 15/16/24-bit color modes (and perhaps the 32-bit padded mode (the A-channel having no effect on output, being forced 0xFF essentially) on the SC15025 RAMDAC)?

So far I got (not requiring 3D accelerated cards):
GTA
Psychic Detective
Star Trek the Next Generation - A Final Unity
The 11th hour (not working on ET4000).
Magic carpet(don't know if it's requiring 3D acceleration?)

Edit: Hmmm... GTA install.exe crashes with error #8 (double fault exception perhaps?).
Edit: Psychic Detective install.exe has a weird half width screen issue, with data appearing on the next text line? It's also running off the screen because of it (looks like 40x25 text mode with 80x25 text mode content in the VRAM)?
Edit: Perhaps an issue with the GTA install I ran before?
Edit: That seems to be the case! Nothing a "mode co80" command can't fix!
Edit: Detecting system configuration throws a general protection fault apparently! Copying files after that.
Edit: Just found a bug in the 8-bit DAC mode on the SC15025. It was using the pixel repack register bit 0 instead of auxiliary control register bit 0 to determine 6-bit(VGA-compatible) vs 8-bit DAC operation.
Edit: Star Trek TNG's sttng application also crashes with a general protection fault when starting up? What's going on? Weird?