Some seperate question: are the queued and loaded registers update for the CPU to see a different value when the raster operation is finished or suspended? Does the CPU read anything else than the data originally written to the destination address register when loading the queue into the internal registers?

Does anyone know how the zoom settings affects the CRTCB/Sprite window? Do they make it wider/higher? Or do they still stop after the specified on-screen pixels(the width/height of the window) have been rendered(like a width of 32 and x2 horizontal zoom becomes only 16 sprite/CRTC inputs rendered)?

Hmmm... The broken mouse cursor happens in 16-bit color mode. In 8-bit color mode the cursor only has transparent pixels somehow (address 0x60000)? And in 4-bit color mode(16 color mode) it isn't used at all(it's disabled, drawn through the normal desktop pixels functionality of the (S)VGA).

One little interesting fact: running dxdiag does actually show the video card as being a W32/W32i video card! So the video chip is at least detected correctly while in 16 color mode(4-bit mode)?

Although it's still unknown why the cursor in 8-bit mode and up fails(8-bit invisible sprite and 16-bit interleaved sprite with double width?), as well as the accelerator wrong address issues?

Just added a little more functionality. I simply remapped the writes to MMU memory-mapped registers 80h and above to be handled through the same function as the writes to the MMU windows (MMU 0-2), including said waitstates and the bits in the status register.
The only difference is now that they don't write to the accelerator's input function, but instead to the queued registers instead.
The lower registers(below 80h) still are written directly like before.
Although it's still a simple 1-byte queue that's being used? Does this need to be multiple levels for dword inputs (like the registers) to be handled? Or will a simple 1-byte FIFO work as well?

Edit: More simply said: can the queue be 1-byte in size? Or does it actually need to be 4 bytes minimum (due to the size of the MMU registers needing to be cached in total during 32-bit memory writes)?

Edit: Just fixed two bugs with the new MMU register write handling:
- The writes weren't arriving at the registers due to bit 3 of the status(the X/Y busy flag) not being set.
- The handling didn't clear the accelerator idle flag.

Just fixed a bug in applying the multiplier by 8 for the MMU Memory Base Pointer to not apply to the memory base pointer as well (which was loaded together with the address and shifted left after that, instead of shifting before adding the base pointer), which was generating incorrect addresses in such cases.

Hmmm.... Does writing to MMU register 36h have any effect at all? Some of the documentation says that bit 2 is probably writable? But all emulators I know of (All PCem-based ones(PCem, PCem-X, 86box)) don't handle said writes, ignoring them (leaving said register unchanged)?

Hmmm... Forcing the X and Y position registers to 0 when starting an accelerated operation by writing to the memory aperture improves things a bit: it now at least tries to render stuff like the background of the start menu (although in the wrong locations).

Text is still messed up somehow (seemingly reduced to seemingly random dots on a single line of text)?

Hmmm.... According to 86box, the destination address in the queue is also loaded with the unpatched address (without multiplying by 8 ) when it's loaded from the queue by a write to the accelerator memory aperture while it's not in operating mode(X/Y bit in the status register not set)?

Edit: Hmmm... Just modifed the writing of the MMU aperture while a transfer isn't in progress (the X/Y status bit not being set) to load the queued destination address with the combined (unwrapped) address that's the simple addition of the memory aperture's base address register (one of MMU base address 0 through 2) and it's offset (shifting the offset left 3 bits when it's set to mix data mode).

Not shifting the memory address window offset left by 3 bits at least produces a proper location of all the elements (like 86box applies it), although the actual text display is garbled (most of the other parts of Windows 95 look fine)?

Edit: Just fixed another bug: starting a new accelerator operation in any way clears the amount of remaining pixels it's processing (causing it to properly start with a cleared buffer). I've also fixed said clearing of remainder pixels (which only happens during the 8 to 1 ratio (mixmap)) when reaching the end of a horizontal range (overflowing the X Count registers's location). So that would mean that up to 7 pixels of input can be discarded when the X count isn't 8 pixel aligned, causing the next few pixels on the next scanline to start at their correct position within the mix map inputs from the CPU.

Of course, starting a new transfer is also fixed with that bugfix, since an amount of pixels can be left in the cached remainder of pixels at the end of a graphics operation (also up to 7 pixels that are invalidly counting towards the next graphics operation, which is bad).

Edit: Hmmm... All text displays on Windows 95 OSR 2.5 ("C") is still garbled up in 8-bit color mode (using the ET4000/W32 accelerator)?

Weird? The text corruption only happens to items that aren't disabled(grayed-out)? (right-click menu disabled items display fine?)

Hmmmm... If Windows draws corrupted text instead of proper letters while the ET4000/W32 accelerator is used, and the mouse cursor(which is a sprite that's supposed to be at 0x60000 in VRAM, but contains only 0xAA values(transparent pixels only)) isn't visible properly, does that mean that Windows 95 is probably corrupted itself?

I also still notice that both Windows 95 OSR 2.5(a.k.a. "C") and Windows 3.1 using the W32 driver both still hang because they never properly set the CRTC 0x36 bits 3&5(mainly bit 5 for this hang to occur))?

So does that mean that the CPU emulation in UniPCemu has some kind of unknown bug that's causing this?

16-bit color mode on the ET4000/W32 at 640x480x4BPP displays without issues though?

Could there be some issue with handling CPU input modes (in this case mix data, source data, x count or y count. Although mix data has the highest probability for this(font rendering?)) in some cases that's showing itself with the text output of Windows 9x?

Edit: Running dxdiag and making it dump the information to a text file (from the corrupted text interface, saving it to a text file) reveals something interesting though: its's detecting the entire 4MB VRAM that's installed in the ET4000/W32 (the BIOS and WhatVGA only display it having 1MB)! 😁

I think I'll open a new thread regarding the Windows 9x ET4000/W32 initialization issue (CPU bug?) and then keep working on the accelerator issues in this thread.

OK. Even after a full reinstall of Windows 95, during first boot (where it finalizes settings) it still shows a corrupted font instead of an actual font it should be using?

Although with the correct BIOS(from 86box), the accelerator no longer hangs on the unmapped registers (they're properly mapped in it's window now).

The text is somehow still corrupted?

Edit: Hmmm.... It's definitely a problem with the Mix map data being supplied by the CPU (either the data being supplied or the mix map processing itself)? When I make it so that the ROP is replaced with 0xFF when the mix map data is given by the CPU, only text display change into weird white areas instead of the corrupted text!

Edit: Hmmm... Forcing the mix map to 0xFF causes the same pattern to be drawn on the screen, only taking the white color in the title of the window and black in the content part of the window...

So that means that the mix data (in effect, the font being rendered?) it's supplying to the renderer is somehow messed up (random garbage)?

Edit: Hmmm... Replacing the mix map CPU input with 0xAA values causes the text to become a barcode type of pattern inside the window, with most text becoming a barcode pattern(some parts of the text still become solid blocks). The text in the title bar is somehow unchanged from the earlier examples?
So perhaps this isn't a video card failure anymore, but instead a CPU emulation failure?

Hmmm... Just tested Windows 3.1. It displays the background of the setup.exe properly(the blue gradients), but everything in the foreground is incorrect? There's a huge blob of randomness at the top, a colorful curcor blinking at it's correct position, just as windows 9x no mouse cursor(?) and everything else isn't displayed at all?

Just fixed some issues with the Sequencer and Attribute extended registers needing to become read-only instead of non-existing when the KEY isn't set. Although that applies to all Tseng chips (ET3000, ET4000AX and ET4000/W32).

Hmmm... Windows 95 in 24-bit color mode on the ET4000/W32 seems to run correctly now?
8-bit still seemed messed up? Don't know about 16-bit?
Windows95 itself also reports 4MB VRAM installed in the card (which it is in it's current configuration).

I 'm pretty sure 8 bit mode is going by palette , while the others have bytes /partial bytes per color component for each pixel... though not sure how this would be of any help.

@weedeewee: I do know that 16 color mode (4BPP) doesn't use the accelerator at all. 8-bit mode uses the accelerator and failed up until now (didn't check yet). Don't know about 16-bit.
Perhaps it doesn't use the accelerator in 24BPP mode(16M color mode)?

superfury, I do find the screenshot

quite funny where it says 1 bit while still being in color 😀

weedeewee wrote on 2021-03-31, 19:35:

superfury, I do find the screenshot https://www.vogons.org/download/file.php?id=105670&mode=view quite funny where it says 1 bi […]
Show full quote

superfury, I do find the screenshot

quite funny where it says 1 bit while still being in color 😀

Yeah, it's actually 4-bit in that screen capture I made. Perhaps it's some CPU bug or Windows 95 bug?
Does it show the same in other emulators and real machines when in 16 color mode on ET4000/W32?
Edit: Also, it doesn't seem to use the accelerator at all when in 24-bit color mode (which explains why it displays itself properly).
So it's only using it in 8-bit and 15-bit(16-bit not being used by Windows 95) color modes?
Edit: Hmmm... The accelerator is only used (together with the incorrect sprite and sprite functionality in general) in 8-bit and 16-bit color modes.
Text is still messed up when using the accelerator, mouse is either interleaved correct/transparent, thus broken (sprite errors in VRAM as far as I can see) or fully transparent(in 8-bit color mode, each byte being 0xAA, thus transparent).
Edit: Just changed the VRAM settings in UniPCemu. Windows 95 correctly reports 1MB when 1MB is installed and 4MB when 4MB is installed 😁