Hmmm.... Hwinfo on Windows 98 also doesn't add much:

All below that is just the driver information (versions, revisions etc.).

There is one thing I didn't try yet, though: Running WinCheckit 4 on Windows 98? Neither on Windows 95. Perhaps that will show more, since it's a testsuite?

superfury wrote on 2021-04-29, 08:49:

Hmmm.... Hwinfo on Windows 98 also doesn't add much: 1433-hwinfo not adding much information on the W32.png […]
Show full quote

Hmmm.... Hwinfo on Windows 98 also doesn't add much:
1433-hwinfo not adding much information on the W32.png

All below that is just the driver information (versions, revisions etc.).

There is one thing I didn't try yet, though: Running WinCheckit 4 on Windows 98? Neither on Windows 95. Perhaps that will show more, since it's a testsuite?

Prepare to be disappointed.

weedeewee wrote on 2021-04-29, 11:05:

superfury wrote on 2021-04-29, 08:49:

Hmmm.... Hwinfo on Windows 98 also doesn't add much: 1433-hwinfo not adding much information on the W32.png […]
Show full quote

Hmmm.... Hwinfo on Windows 98 also doesn't add much:
1433-hwinfo not adding much information on the W32.png

All below that is just the driver information (versions, revisions etc.).

There is one thing I didn't try yet, though: Running WinCheckit 4 on Windows 98? Neither on Windows 95. Perhaps that will show more, since it's a testsuite?

Prepare to be disappointed.

Ran it. Gave slightly more info:

So it looks like it isn't detecting the W32 extensions for some reason, thinking it's a base ET4000AX instead?
That explains why the ET4000AX drivers don't complain about anything on the W32?

So my logical conclusion is something is missing from the emulation? But what it it?
Btw the 1MB VRAM installed is because switching from ET4000/W32 and then back lowers the installed VRAM to the lowest decominator (ET4000AX in this case, with 1MB installed). Only when switching between other video cards will it enforce a redetection of VRAM to install (unless it's less than 512KB or more than 4MB, which is unsupported, or on ET4000AX more than 1MB or less than it's minimum CRTC register value).

Edit: Hmmm.... I am using a different BIOS afaik (the ET4000/W32 BIOS identifying itself as a "VGA GUI 1600S DATE: 11/24/1994"
"CHIPSET: TSENG LABS ET4000/W32"
"4 MB display memory"

The XL drivers from vogonsdrivers fail also.
Now trying the W95W320.ZIP one from the Metropoli BBS... (It says ET4000/W32/i/p drivers for W95 after all)...
Edit: Still fails with those drivers?
Does that mean something's wrong with my emulation somehow?
Any idea if those I/O ports in the W32i documentation are all the video card supports? Or are there still some undocumented I/O ports or registers?
Edit: Hmmm... Interesting. Windows 98 using Windows 95's ET4000/W32 drivers says (in System properties): "The loaders for this device cannot load the required drivers. (Code 23)"

I've just modified the KEY sequence using port 3D8 to work even if the device is setup for mono mode. It looks like both Windows 98 and the BIOS try to use the enable/disable sequence with 3D8, even if it's setup for mono mode? Although I've left the functionality of the CGA/MDA emulation to keep relying on the mono/color setting (bit 0 of the Misc. Output Register).
I've also modified the NMI generation to work on the ET4000/W32 chips as well (using feature control bit 7 set while CRTC 34h bits 7 set and bit 5 cleared). Although the ET4000/W32 chip documentation mentions them as undefined (ET4000AX does document those).

Just modified the behaviour of the Video Enable Register (3C3/46E8) to have seperate storage, being OR-ed with each other to determine if the VRAM and I/O ports (except the 3C3/46E8(selected by the CRTC register 34h bit 3), starting out at boot time having 46E8's bit set and 3C3 bit cleared (as 46E8 seems to imply that it's only used with hardware I/O ports). I've also modified the power-on bit 3 of CRTC register 34h to be set (thus selecting port 46E8 (which should be used for all non-motherboard VGA's)).
This seems to have the effect of allowing the Windows 98 hardware detection wizard to actually detect the ET4000/W32 when detecting the hardware!

So port 3C3 shouldn't be used with the ET4000/W32 (the bit in CRTC register 34h bit 3 should be set on powerup because it's a VGA card instead of motherboard internal card)?

As for register 3C3, Windows 98 and the BIOS seems to clear said bit 0 when starting up instead of leaving it enabled. Thus causing the card to disappear and being unable to POST properly. (the same thing happens during Windows 98 boot and hardware detection!).

The power-up value of those two registers are:
- Non-ET4000: 3C3 enabled, 46E8 disabled(if present).
- ET4000 chips: 46E8 enabled, 3C3 disabled.

Edit: Yay! After said fixed functionality, the ET4000/W32 is properly detected by the hardware detection wizard (because the hardware isn't disabled by port 3C3), while the accelerator is enabled when starting the GUI (and it's reading the version from register ECh!).

It's actually using the accelerator! And guess what? Corrupted fonts galore once again!

Edit: It's sprite address also starts at 60000h, only containing 0xAA bytes(only fully transparent pixels)? So that's the same as Windows 95 C (OSR 2.5) did?

So the Windows 98 (First Edition) issues with the accelerator are exactly the same as the Windows 95 ones?

Ah.... Interesting...
When bringing up the Start Menu, the items display correctly, but when selecting(start menu main menu items), but the programs display becomes corrupted once selected. So do the favourites(once selected), find corrupts all items in there, so do Settings and recent documents.
So they display fine once flying out(animating), but some of them corrupt all items once the animation stops?

Now, changing color depth to what looks to be 16-bit color depth causes some text to display between the garbled fonts (before rebooting)?

Start button/right click menu: same behaviour. OK until corrupted by selecting or finishing opening slideout animation(depending on the item).

Edit: Dxdiag.... Again, almost readable, although largely transparently drawn(window background fill missing?).

Just improved the fifo buffer of the accelerator a bit. It will still report filled when it's at least partly filled, but set the sync enable bit to 0 on power up and reset(when terminating the accelerator using the suspend/terminate register bit).

One thing it does now is when being requested to add to the queue:
1. If it's being requested to terminate, handle as if the buffer is full.
2. If the queue is at least partly filled, handle as filled(steps 3+). Otherwise, add to the empty queue and start to report queue filled.
3. The queue is either filled or requesting termination. If not requesting a new add to start(happens during the second+ write of a broken up write, like for (double)word writes) or the sync enable is set, goto step 4. Otherwise, try to raise the write fault interrupt and abort the write.
4. If it's the 2nd+ byte write to the queue of a single transfer(multibyte write) and there's enough room in the queue to store it, add to the partly filled queue. Otherwise, start waitstating until there's room(in other words, add to the multibyte queue if possible and force waitstate if it can't). Writes on the first byte of a (multi)byte write with a full queue will trigger a normal waitstate (when the Sync Enable is set), fault if the queue is already filled(when enabled) or perform a NOP if neither is enabled(as documented).

So the multibyte queue is actually only used when a multibyte write is used on an empty queue. It will automatically force a waitstate if such a multibyte write past the first byte actually reaches a full multibyte queue and otherwise add the remainder of the (double)word written to the queue. Single byte writes are handled as documented(either faulting, writing to the queue, being ignored(sync bit cleared) or waitstating(sync bit set)).
So, in effect, multibyte writes(word/doubleword) are always fully added to the fifo(in effect counted as a single write), unless it was already filled and the sync enable wasn't set when the write reaches the ACL(in which case it's ignored).

Thinking about it.... What happens to the offset used during a multibyte(word/dword) ACL aperture write? So the first byte location is multiplied by 8. What about the second one(the upper half of the word or second of four bytes of the dword write)? Is it automatically 8 bytes past the first one?

Edit: Hmmm... I see something interesting happening: when looking at the combination of the aperture offset and aperture base address(the first 3 registers of the ACL registers), the value calculated during mix map rendering from the CPU(base+address times 😎 doesn't match the address that's in the destination address internal register?
So either the destination address register is loaded incorrectly, or the writes to the aperture are supposed to load the destination address, which is setup to don't do that on each byte write to the aperture (by internal register 9Ch bits 4/5 not being 01b)?

Edit: Hmmm... Internal register 9Ch is set to o2h. So that means that only the first write starting the operation has it's address latched in the destination address register, with all others ignoring the address given by the CPU? Is that correct?

Edit: Just took a look at the addresses the CPU supplies VS what the hardware has in it's destination address register during the mixmap inputted font rendering.
I see the X count being 9, so 2 bytes per row of pixels. The newXYblock variable serves as an indication of new transfers starting.
The first destination address supplied by the CPU matches the destination offset(always latched).
The second byte address also matches.
The third doesn't? This is on the next line. The CPU address is ignored, however, and the destination address starts at the next row of pixels supplied by the ACL destination Y offset.

I'm just thinking... I see Windows changing the aperture address for each scanline it seems...
What is meant in the documentation that the ADRO being cleared(00b) that only the first write is used as an destination address? What about writes to succeeding scanlines during a transfer? Or just the first byte of the transfer loads the address?

Edit: Just found an issue with the accelerator able to deadlock with the CPU because it's done parsing it's data(nothing left to process) in CPU mode 0(no CPU input mode). So that caused it to not parse new data in the queue to start the accelerator back up again, thus keeping the data buffered and never emptied properly(because of blocking the buffer because of the mode 0 being detected). It will now stop the accelerator when it notices that case(mode 0, nothing left to parse(block size being 0) and accelerator being active(which shouldn't happen)).

Edit: Some text seems a bit better now. Most is still corrupted. Start menu displays and immediately corrupts itself entirely afterwards. Right click menu displays fine until selected.
Somehow, the bottom item on the desktop displays the top line without issues, the bottom line being corrupted?
Forcing the mixmap inputs from the CPU to 00h removes any and all corruption, while it effectively hides all text in the rendered results? Forcing it to FFh instead makes it show some areas besides the start menu items as black blocks at about 1.5x the side of the ">"-blocks (mostly to the right of the ">", floating to the right of the menu, corrupting the desktop)?
Disabled items seem unaffected by the issue because it's not rendered using the mix map CPU inputs to the accelerator?
Disney's Villains Revenge seems to refuse to start somehow with the W32?
Edit: I almost start to think it's a CPU bug manifesting itself somehow?

Just tried the VDIAG program again... It now seems to fail on the "Horizonatl Polyline Method 2" and "Vertical Polyline Method 2" tests?

Any idea how those X Count and Y Count modes work? Do writes after starting the modes affect anything (reload the X/Y count registers?)?
Do they behave the same as the no CPU mode (mode 0), but with a trigger to start by writing to the aperture loading the count register's low 8 bits instead? And writes after said initial write while it's busy being queued up for the next operation?

Edit: If I'm understanding the ET4000/W32i documentation combined with https://github.com/86Box/86Box/blob/master/sr … vid_et4000w32.c correctly, this means that for these modes, the initial write to the accelerator aperture causes the low 8 bits of said register to be loaded and all other writes until the finish of the operation writes normal source data instead(just as in mode 1 ("CPU data is Source data" as the DARO description says))?

Edit: OK. Just found out something. If I don't make the accelerator become idle (setting bit 1 of the status register to 0 when no input is queued when requiring input to be served(needing a new mix map byte for example) while the queue is empty), Windows 98 will hang when trying to display some stuff using the mix map input method.
So what the documentation mentions the accelerator being idle actually means it's just not doing anything in video memory. So it's not that it means that no video operation is in progress (which it still is in this case, since the accelerator is waiting for the next mix map input from the CPU).

Edit: It looks that 86Box by comparison handles it quite strangely: it doesn't do any loading (as is actually documented in the W32i documentation) when starting the operation during a X Count/Y Count operation. Then it seems it uses the X Count or Y Count register as a replacement of the CPU input for the "CPU input is Source data" case? That seems quite incorrect, seeing as the X Count is also used for the limiting of the address, so that's just a normal number that specifies a range instead of an actual input?
Or is the X Count or Y Count register actually not used in this case for limiting and only taken by a latched form of the input data by the first write after the mode is loaded until it completes (temporarily replaced, with the remainder of inputs taking the value of the X/Y Count register instead)?

I've just taken a screen capture and looked at the way the invalid 16BPP cursor is rendered...
I see two valid pixels, followed by 2 transparent pixels (in my screen capture), repeating over the entire width of the sprite.
Since a byte contains 4 8-bit pixels and every 2 of those 8-bit pixels form a displayed pixel(2x8 bits are combined by the DAC to 16BPP)... So every byte produces 4x8BPP or 2x16BPP pixels, which matches the interval seen in the sprites output. So, somehow each other byte from VRAM is fully transparent(containing 0xAA), with only half of the actual sprite displayed somehow?

Edit: I also noticed that although the window width is correct (it's setup to 64 pixels), Windows does program the row offset to double that of what it's supposed to be(128 pixel lines), while rendering the pixel bytes at even addresses only (odd addresses are always 0xAA)?

Adding a slight skip odd bytes to the CRTC Sprite handling causes the Windows 98 cursor to be displayed correctly.

Edit: This is what happens with My Computer on Windows 98 now:

It looks like it's rendering something at every other row, while somehow rendering part garbage somehow?

Edit: Running Disney Villain's Revenge on the Windows 98 insta

llation, running it's configuration from the CD-ROM's setup.exe, somehow causes the bottom icon to start displaying part of it's text?

Just have been thinking...
Are there any games that actually use the ET4000/W32 accelerator? Besides Windows I mean.

superfury wrote on 2021-05-09, 18:11:

Just have been thinking...
Are there any games that actually use the ET4000/W32 accelerator? Besides Windows I mean.

Not Windows, but how about running X11 on Linux? That should have W32 support at least in older distributions from that era.

Are there any dos games that used 2D acceleration at all? Vesa died when windows 95 came along, and everyone pretty much ignored VBE/AF. You could maybe find VBE/AF VBE 3.0 test suite if there was one.

I believe that Duke Nukem 3D has a VESA mode optimized for Tseng Labs. But anything using 640x480 in MS-DOS is unplayable with an ISA graphics card. At least nothing that I tried has a decent framerate. Well I played Network Q RAC Rally in 640x480 with this card and it is playable, but the overall impression is that you're watching a high-speed slideshow.

However I haven't heard of anything DOS-based that uses the ET4000/W32i accelerator.

I only found some in xFree86?
https://gitlab.freedesktop.org/ajax/xfree86/- … ind_file/master
Searching for "tseng".

It only seems to use mode 2(mix map input from CPU) for what it calls 'color expansion'? Don't know what that is though? Converting 8-bit color to 16/24/32-bit?

Tried installing ans running Starcraft. It installed fine(matching Windows 10 installed files).
But when I tried to run it it displays the wrinkly first frame of the first animation, then hangs at segment F000? It keeps #GP(0) faulting trying to write port 43h(not allowed by the OS)?

Then it appears the accelerator emulation code is still somehow faulty. Theoretically StarCraft would not be directly using the video card but would pass through the Windows abstraction layer (including the driver).

I had myself some visual pixel artifacts but in my case they were all caused by bad hardware design which I corrected in the second revision of the PCB.

In your case it might be either memory timing errors (but in that case all the screen would get corrupted, not just the font rendering) or some obscure register settings that you haven't figured out, yet.

I have not had any time to follow this thread or look in the datasheet but once I free myself from other projects I will try to also take a look.