Hmmm.... Right now experimenting with the 16-bit color mode using the accelerator.
I see, when looking at the VRAM data that's transformed into the sprite that's displayed for the cursor, that somehow every other byte seems to be always 0xAA (so all odd bytes in the bitmap sprite structure is 4 transparent 4-bit pixels)? That's kind of weird behaviour?
It also seems to display only half the horizontal size of the sprite somehow?
Hmmm... Selecting basic acceleration functions (slider 1 to the right of the left side) in the properties of the ET4000/W32 seems to render text properly as well in 16-bit color mode?
It's still using a broken sprite though?
Edit: Selecting "Most accelerator functions" causes corrupted text?
While still having the accererator fully enabled, added a little bugfix. Each time it starts a new accelerator operation (except when setting the XYST bit in the status register from 0 to 1), it will reset the bit number (for the mix map in0uts) to process for the next pixel it's processing to start at the first bit (bit 0 for increasing x addresses, bit 7 for decreasing x addresses).
The text output seems to improve slightly. Still not really readable, but text can be vaguely made out of it.
Well, the row addition algorithm is the same in all acl modes. It's the et4k_stepx function for wrapping horizontally(if used) and the et4k_stepy function for wrapping vertically(handles the row advancement logic).
And since images are rendered correctly, together with windowing etc., that shouldn't be the cause?
It simply adds/substracts the value of the y offset register plus 1 to the addresses(destination/pattern/source) and wraps them afterwards(wrapping is based on PCem's code, as there's no proper documentation on wrapping behaviour of the W32 ACL I can find anywhere).
When starting the accelerator, the address from the start of the previous row is restored from a backup, which is saved after the y increment completes and when an accelerated operation is started. It adds/substracts the source/pattern/destination Y offset register + 1 to said addresses when the X position overflows the X count.
Improved the handling of the ET4000/W32 ACL MMU queues when using terminating/suspending. Said request now overwrites (when the bit is written with 1) the MMU queue for the memory aperture(it's aborting it after all). One difference now is that queued writes to MMU registers are left intact and will be written to said register before the suspend/terminate is executed.
VDIAG doesn't seem to like this? Most blits don't modify video memory.
The texts in the bottom right are still seen, as is the Stat error.
New is that it now mentions that all of said earlier-working blit tests all seem to fail(all but the first blit with yellowish color)?
