clerLine() needlessly uses VRAM

[konimaru]

Said function utilises half an empty line to efficiently generate empty lines during scrolling. This can be handled differently without much penalty (and getting the VRAM back).

• draw a line in background colour at the top of the character line
• duplicate this line with h/w blitter (avoid <5 transfer widths, window 9,0,1,20 looked interesting)
• the line drawing will have to be accelerated as it's pixel based which introduces a huge overhead

[konimaru]

I do have a solution for this which just needs one final test this evening on real h/w.

[konimaru]

Out of curiosity, in MoveBlock the location of the wait-for-move-to-finish depends on the previous direction. Why is that? The vs23 documentation seems hopelessly out of touch with reality.

[uli]

The reason is that you can set up the start address for a block move while the previous move is still in progress, but only if the latter is a forward move. For a reverse move, the start address is used as the end address, so it cannot be modified until the move has completed.

[konimaru]

Turns out that source and destination address for the block move have to be at least 4 bytes apart (at least in the configuration I am using, i.e. skip == 0). Modes 3 and 4 happened to trigger a delta of 2 which made it all fall apart ...

[konimaru]

For the record: #61

From the looks of it, SDL's MoveBlock function doesn't work vs23s010 style. The latter honors live updates while moving stuff around. SDL simply takes a snapshot of what is there and copies it somewhere else. I'd argue all platforms should have the same behaviour, in this case following h/w. Your call.

from left to right: original, 1st ^L, 2nd ^L

[uli]

Fixed in 55bbcf2cc.