If all you read is the wikipedia page sure.

It actually accelerates windows 3.1 functions, has a dual screen access which acts as an overlay over the existing screen (so full dual CRT controllers), compound bitblits, all 256 Microsoft Raster Operations opcodes in hardware.

Can it be implemented without those? Like reporting unsupported for most/all of them(only implementing ET4000AX and memory extensions, perhaps cursor only)?
Also, is the (mouse?) cursor blitted as well or processed during rendering(overwriting DAC input or sequencer output)?

Just implemented most registers but the CRTC/Sprite(except identification registers as ROM and CRTC/Sprite register for selection at the xA address). Based on VGADoc documentation: https://www.cs.utexas.edu/~dahlin/Classes/439 … gadoc/TSENG.TXT

So that's a ET4000/W32 without accelerator functions but with detection and base ET4000 and VRAM support(minus extra memory windows).

CRTC/Sprite registers read 0xFF always atm.

Currently still disabled by a flag in the source code(to be configured later).

Eventually added the memory mapped registers (mostly ignored) and other window supported and ignored by the card atm.

I see it booting the OS eventually but no VRAM character fonts seem to be loaded, thus a black screen is displayed?
Edit: The cause was faulty memory wrapping on the Tseng ET4000/W32 chip emulation only(not on the normal ET4000). It was calculating a mask for VRAM addressing, and instead of properly applying size-1(for the bits to mask for) it was using size, which resolved into a result of only the topmost bit + 1 being able to be set for VRAM reads and writes!

Having fixed that, the W32 chip now properly displays and boots.

I did notice, however, that the BIOS seems to detect 2MB display memory, while only 1MB is installed?

Anyone knows how the BIOSes detect display memory installed?
Edit: Hmmm... WhatVGA hangs/crashes when it has the extended functions for ET4000/W32 memory enabled somehow?
Edit: It seems to be waiting on BFF36(M+36) to clear bit 2, which currently always reports set?

Now the question: how much is supposed to be implemented and left for ROM values in the registers for the software to not hang and the remainder of the card(minus any BitBlt operations) to operate correctly...

Just implemented a storage backend of all registers (both memory mapped and at I/O port 217A/217B (officially 21xA)). The only exception being the registers only defined once for the CRTCB registers behave to pointing to those in both CRTCB and Sprite windows and the CRTC/Sprire control and Image Port Control. They all resolve to the same registers in both CRTCB and Sprite windows.

Then the Status Registers (M+35 and M+36) all are read-only, with values 0x00 being reported atm (so software can continue on?).
Edit: WhatVGA doesn't hang anymore and messes up the display and seemingly character fonts in VRAM as well?

Just implemented the MMU 0-2 window areas and their functionality(just VRAM accesses, though).

It's still unclear what WhatVGA means with the "accelerator registers" when M+13h bits 0-2 are set? Currently I just caused it to float the bus during reads and do nothing when written(though taking the access instead of anything like RAM(normal RAM installed) or ROM(like BIOS etc.) responding to the address).

Is there any diagnostic software I can use to check the UniPCemu implementation of the ET4000/W32 video card? (Of course one that doesn't require full implementation of the actual BitBlt functionality)

It's weird that WhatVGA somehow seems to corrupt the video RAM (plane 2 in particular)?

Edit: Hmmm... Inspecting what the highest VRAM address actually written by software, I see that the ET4000/W32 only writes up to 256KB of VRAM? It says it detects 1MB, but what does it base that off?

Just managed to find the issue with WhatVGA corrupting video RAM:

The ET4000(AX and Rev E) documentation lists bit 5 of the Video System Configuration Register 1 to indicate contiguous mode (essentially matching linear mode on the linear memory aperture).

But the ET4000/W32 documentation in the TSENG.TXT of WhatVGA changes this bit: it now enables the Memory Mapped Registers(A.k.a. Tseng Addressing Mode). So enabling this bit doesn't cause the video memory to be presented in a contiguous way(linear memory buffer)! That's only happening on the extended memory area when it's enabled by bit 4 of said register!

Edit: It makes me wonder, though... What exactly is this bit 5 on the ET4000AX chips?

The documentation says the following about it:

Bit 5, when set to 1, will enable the address mapping of the display memory to be contiguous. This enabled much more efficient use of the ET4000's internal resources and thereby, improves the performance. When set to 0, will enable address mapping compatible with the VGA's. Note that the use of this bit will not affect the compatiblity with all video modes unless the software assumes the relationship of the address mapping between modes.

So does that mean it only affects the chained mode to behave in a more optimized way and not affect anything regarding the way VRAM is presented to the CPU?

Huh? Weird? When switching from a ET4000AX to a ET4000/W32, Windows 95 thinks the ET4000 has been removed with nothing in return?
Edit: Even weirder, it thinks that the "Gameport Joystick" has been removed from the system?

Just now reinstalling Windows 95 OSR 2.5 "C" within UniPCemu, since the device detection went faulty somehow...

Now, looking at the detlog.txt during detection, I see the following:

1Checking for: XGA/2 Display Adapter
2QueryIOMem: Caller=DETECTXGA2, rcQuery=0
3	IO=3b0-3bb,3c0-3df
4Checking for: Tseng Labs W32 Display Adapter
5QueryIOMem: Caller=DETECTTSENGW32, rcQuery=0
6	IO=3b0-3bb,3c0-3df
7Checking for: Tseng Labs Display Adapter
8QueryIOMem: Caller=DETECTTSENGW128, rcQuery=0
9	IO=3b0-3bb,3c0-3df
10Detected: *PNP091A\0000 = [11] Tseng Labs ET4000
11	IO=3b0-3bb,3c0-3df
12	Mem=a0000-affff,b8000-bffff,c0000-c7fff

So it's somehow detecting it as a ET4000AX instead of a ET4000/W32?
That's of course incorrect, since the W32 is actually emulated(mostly, except sprite and acceleration itself)?

Hmmmm... According to PCem, only bit 5 of the video system configuration 1 register enables the MMU registers in the selected VRAM window. Windows 95 seems to agree (seeing it poll said registers with only bit 5 set and bit 3 cleared). But the documentation on the ET4000/W32p and ET4000/W32i and WhatVGA say that both bit 3 and 5 need to be set for this to be enabled?

slightly different interpretation would be that the registers need to be polled with bit 5 set to 1 and bit 3 set to 0 😁

But polling the register has nothing to do with it's functionality. The reading of the register has no effect on the actual effect of those bits on the VRAM window presented to the CPU? It's what the CPU writes to it that determines it?

What's now happening is that the OS writes bit 5 set and bit 3 cleared and reads that back. And it's the write that actually sets the functionality of the VRAM, in this case bit 5 being set and bit 3 being set or not(doesn't matter) to enable the MMU register area in the VRAM window.

What's now happening with Windows 95 is that the CPU seems to hang during boot once again, but since it's not polling or doing anything with the ET4000 chip, I assume that the problem with the video card is something different now?
I see that the display is garbled up, taking about half the screen with a bit of residual below that, which probably means that it's just entered the graphics mode for displaying the desktop (the mode after it's displayed it's booting screen), so what I'm seeing is probably the 256-color 256-color boot screen (probably LOGO.SYS) interpreted using the desktop width and pixel depth instead of 8-bit 320 pixel wide display(so reinterpreted as 640 pixels 8-bit colors with each even and odd scanline displayed on each single line?).
Edit: Changing the horizontal pitch to A0h in the precalcs used to render itself(leaving the backend registers unaffected) shows the Windows boot screen (LOGO.SYS) at part of the screen, with wrong rendering of colours of course, being seen 4 times horizontally.