D3thAdd3r wrote: ↑Tue May 29, 2018 1:39 pmVery interesting stuff. Since this mode is already in a construction state I will try to check out what FoaD and Mode 74 are doing. It sounds like the method you mention is the ideal.
For actual SPI RAM tech, you could also check
this example in Mode 748 (it should compile fine on a clean checkout). It loads data from a file, filling up the SPI RAM while safely having the display off, then shows off the 4bpp bitmap mode.
Bitmap mode is tricky, especially at this resolution. 5.5 cycles per pixel (if you want the improved resolution with 256px visible width) just doesn't work too well with the SPI RAM, you can easily get 2bpp, but anything more would be tricky. 6 cycles per pixel could offer a 3bpp bitmap if you found a way to encode it so it can be decoded during the scanline (Mode 748's technique might or might not fit here). 4bpp is impossible (I think Mode 748's 4bpp is the max what can be done reasonably without sacrificing the inline mixer, there is just no SPI bandwidth and RAM for more).
I don't think HAM would be visually useful on the Uzebox as we don't have enough total colors for that (256 versus the Amiga's 4096). For still images bitmaps at 16 colors should do very well, with such a palette you have to select colors distinct enough for a nice image so the limitations of the Uzebox palette doesn't matter much. Gradients could be best accomplished by creative pixeling, one example is the Outcasts title I did for Mode 74's Multicolor mode:
- outcasts_title_crop.png (7.34 KiB) Viewed 11090 times
This is 16 colors, each 8x8 tile can use 4 of these colors, the image can be served entirely from RAM. Particularly the center is tricky where I set up the illusion of further hills.
Another problem with HAM is that normally it is 6 bits per pixel, and you can't do that fast with the AVR (neither it would be cycle-efficient on a contemporary CPU due the need for shifting and combining). At 4 bits per pixel? Meh... (that would be a 4 color palette + option for 2 levels of Red / Green / Blue, total of 64 colors accessible, but at this point, using the 4 bits to address a 16 color palette seems to be better).
My best bet would be a Multicolor mode for this: the 2bpp bitmap sitting in the SPI RAM, and having the attributes in normal RAM, a 256x200 image is pretty much doable. It would take 3200 bytes of attributes (4 bytes for each 8x8 tile), 4bpp (to have only 2 attribute bytes) is likely impossible at this resolution for this mode, and the free selection of colors would allow very colorful overall results, better than what is achievable on a Plus/4 (which had two colors global, and of course 160x200 resolution). I think this is what could get you the nearest to what could be achieved with HAM if it was possible.
(I would likely have this mode as an option if I do an SPI RAM variant of Mode 52, there of course at 5 cycles per pixel)