Also got another question: what does the ACL Routing Control Register bits 5:4 do? What happens during reads and/or writes to the accelerator queue in it's different settings?
Also, does a operation start happen when the queue is written when no operation is started instead of writing the byte 3 of the destination offset or setting bit 3 of the operation state register?
How is the XYST bit (bit 2) of the accelerator status register being writable factor into all of this? Does setting or clearing it by software affect the accelerator in some way? Isn't that the same as what happens during a resume/suspend/terminate operation(although those might wait on something to finish first)?

Edit: Just implemented a implicit start of accelerator transfer when writing while the X/Y bit isn't set(setting said bit).
Also implemented loading for the first address after starting the accelerator through any means when the ACL Routing Control Register bits 4-5 are cleared. When only bit 4 is set, it's reloaded during every write, otherwise it's never reloaded during writes(for cases 10b and 11b of said bits).
Edit: Just added the SSO bit in the status register for CPU input methods 0, 4 and 5(no CPU involvement(?), X count and Y count(don't understand those? What is their purpose in this context?).

After not reversing the mix map inputs when in descending x address mode seems to fix the horizontal pixels taken at least.

It looks like I'll have to implement the wrapping in order for the WhatVGA tests to work successfully, although the BitBlt memory locations still seem off somehow(if it's incorrect at all?)? I currently see vertical white stripes inside the resulting pattern instead of what it should be according to Pcem? Probably an issue of Y-source/pattern wrapping in that case?
Although X-wrapping might need implementation as well?