I've just finished the core of a new RLE mode.
It is 5 clocks per pixel. 256 pixels wide. Full 256 colours with one minor exception. If you have a single run of pixels that is only 2 wide, the second pixel can only choose from 128 colours (LSB must be set)
Any single change of pixel colour uses up 2 bytes of RAM.
It also uses less than 1K of flash.
It runs fine on real hardware, but at the moment neither of the "release" versions of the emulators Uzem or Cuzebox support it because it uses the USART0 Transmit Complete interrupt to end the scanline.
This is very similar to how I used Timer1_Overflow to end the scanline in Tornado2000 (and now has been used in a few other modes). It sets the UART for 7 Data bits, No Parity, 1 Stop and the Baud Rate Divider to 8. This is then a pseudo timer that ticks over at 1304 clocks.
The reason I had to use the USART as a timer is that TIMER1 was already being used for something else amazing.
Any time there is a run of 10 pixels or more of the same colour, the pixel-render-loop can return from an interrupt and start running user ASM code. This means you can keep filling the RLE buffer as the screen progresses.
You are REALLY "racing the beam"
For every pixel greater than 10 in a run the AVR gets to execute 5 extra CPU clocks. So the included UZE file which has 4 colour changes per line with each run being approx 64 pixels
Code: Select all
(4 x (64-10)) x 5 = 1080
Code: Select all
1080 x 224 = 241920
So that is about 8x as many free clocks as what a standard video mode gives. Of course that is assuming 4 colour changes per line. If you for example had 8 colour changes per lines you only end up with 90K free cycles (3x more than normal)
For the moment I have called if mode1337 due to how many "wait" clocks it had in free on the first line of the video mode.
It probably works well for things like 3D space ships flying around with lots of pixel runs of black for empty space
I'm having a few issues again so I'll be back in about 2 weeks.