Part 3 ended with a 160x240 graphics mode, which - even though it allowed other programs (BASIC, and ML) being run concurrently - chewed up nearly all processing power of the VIC. Now how did we get to display 208x208?
tokra wrote:I could speed the process up a little today by starting to copy back while the 48 extra-lines are still being displayed -
This reminds me about the HCB mode in 'Edge of Disgrace'. There, the colour RAM at $D800 also is swapped on-the-fly, so that in a FLI-mode *all* attributes are of 4 pixels height. During display of the top half of the characters, the bottom half is written - and vice versa.
They even went as far, as they even don't copy the data from yet another RAM range, rather the new attributes are operand fields of LDA # instructions.
(This last sentence took a few seconds to sink in ... and then:)
Eh, you might be up to something ...
LDA $2xxx:STA in the lower 1K
Even though then there's no more a continuous bitmap, the provision of the image data then only takes 5/6, instead of 7/8 cycles.
I have just used PUCrunch for that now. This produces a RUN-able BASIC-program (although it didn't crunch any bytes out of the unrolled loop).
In that case, the addresses are all distinct. Thus far I haven't seen a packer that smart to recognise an operand field is counted upwards.
As I wrote beforehand, a case for a code generator.
(One and a half hour later:)
P.S.: It just occured to me you could even go one better:
Put the bitmap, with char map, again complete into the upper 4K, so that you don't need to save the ZP.
Then, two routines, which write 48x20 bytes with LDA #$xx:STA $xxxx into the bitmap, doing the update always at that place where the raster beam is currently absent.
2 * 6 cycles/copy * 48 * 20 = 11520 cycles/frame.
lo and behold, VIC runs with nearly 50% of its original speed again.