This is a follow up of #58:
Need to find out what these options means.
The options in SAE control "when" the CPU should wait for the blitter. Take a look at maybe_blit() in blitter.js (line 1500)
Immediate: blit as soon as BLTSIZE is written.
Waiting: insert blitter-waiting-states to the CPU.
W-Never: blit on the next access of a blitter register.
W-Auto: insert waiting-states if no free cycles and "blitter nasty" or CPU-speed in maximum.
W-Noidle: insert waiting-states if no free cycles and "blitter nasty"
W-Always: always insert waiting-states, till the blitter is done.
Just thinking out loud here…
Eventually, I could imagine to have the following additional compatibility features for the Blitter:
Since feature 3 requires feature 2, and feature 2 requires feature 1, a slider (with 4 levels) would be a suitable UI-element. Level 0 selects a fast, but less accurate Blitter, and level 4 a slow, but accurate Blitter. In detail:
For level 0 and 1, the emulator would call the FastBlitter (which is already there). For level 2 and 3, it would call the cycle-accurate Blitter which hasn't been implemented yet.
Possible internal names:
Enum {
BLT_FAST = 0,
BLT_FAST_BUSY
BLT_SLOW
BLT_SLOW_BLOCKING
}
I just had a look at the microcode of your new slow blitter. Wow this looks very well structured, I bet you can mimic the real hardware with it much better than with the fast blitter code, because you now have divided all logic in little microcode pieces. Very nice. Is now perfectly prepared and suitable for cycle exact emulation. 🤗
First time vAmiga can draw the International Karate intro with the slow Blitter 😎:

Here is the proof:

Oh no, there are wrong pixels here... under the "I" of "TIME" 🙈. The pixels are wrong even when the fast Blitter is used 😫.