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)?