SPI Ram Video Mode

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian »

D3thAdd3r wrote: Mon May 28, 2018 5:41 pm
Jubatian wrote: Mon May 28, 2018 5:56 am (By the way with M748 you could do exactly that: Disable the mode for the duration of your sensitive code doing anything on the SPI, and enable afterwards. You will get ugly flicker if you run out of VBlank, but nothing will actually break).
I think you mean an entire frame? It must be something different you mean though, since I don't see why flicker would happen so long as this state lasts the same length as a normal drawn frame. (...) there must be something the user could pull off in ~200*1440= 288,000 cycles.
Yes, it means the entire frame, but only that you set the Display Enable flag (which my modes have) disabled until you are in the sensitive part. If you can complete it within the VBlank, and enable the display again before the next frame actually started, display remains normal. So this is rather a safety feature ensuring that anything critical done with SPI is not broken by video.

The aforementioned kernel modifications contain a feature which would allow the video mode to simply return early. So you may disable it without using SetRenderingParameters() to set up a narrow screen, and you get all the cycles, which is useful for example for loading stuff from the SD card fast. Currently you would have to use SetRenderingParameters() to achieve this, however even that is buggy, causing a frame of lost sync (which is a lot worse than a frame of blank screen).
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r »

Very 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.

Going to add a display list thing where the user can specify how many lines to a mode switch. This can be to trigger another scrolling or not scrolled plane for overlays, underlays, etc. but importantly I think a bitmap mode for title screens. Seeing as this mode offers no graphics compression (though arguably easily offloading levels to SD makes up for this), I feel that is important. I have been pencil and paper playing with a "Hold And Modify" as the Amiga had, but not that similar really just inspired by, due to limited bits per pixel it might not work well for actual images. Main concept is palette reloads inline, where back to back same colors allow 1 palette color change. Hopefully a slightly higher resolution than would otherwise be possible at the given bit depth...maybe, and a conversion program is of course required (dconvert).
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian »

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
outcasts_title_crop.png (7.34 KiB) Viewed 11088 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)
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r »

For sure with high skill you can do a lot with 16 colors as you show there. Some intangible angle still interests me though, and the primary motivation would be SPI Ram only and lower development time required. I imagine some low decoding overhead method could exist to perceptually get past some 3 or 4 bit color depth(really 3 max if SPI Ram only, at a useful general purpose resolution, IMO). Something specific to the data in an image. I should say HAM as it is on the Amiga of course is not possible or useful on Uzebox, but a display mode that has a lossy form of compression at it's base might wiggle some different direction possible. The only real direction I would be interested in(seeing as you have already covered all the other ones anyway), would be something as this.

The attributes mode steps quite a ways past packing a few pixels in a byte though, since really that is an image specific compression technique taking advantage of the fact that neighboring pixels in a small block likely share similar colors; a good use of '644 bits there. Then of course a second smaller but faster stream of bits coming in is going to be able to do things that you couldn't do from SPI Ram only no matter what. The particular use case I have in mind would not allow to really use any of the '644 ram though, so SPI Ram only is the most immediate need I have.

The image I have tried to keep photo-like I was able to reduce to IIRC 38 unique colors and it was almost exactly the same perceptually after quite a bit of work. As hard as I tried with color balancing, pixeling, different dither styles, it just ended up looking like something trying too hard to look like a photo and failing when moving to 16. A photo is nice since you needn't spend the time creating from scratch of course. The only "free signal" I see when checking out the data, would be runs of 3 pixels in a row that are the same color. I would call HAM something as a "rolling palette" since it is stateful of previous data. It could specific to the particular image I checked, but this one looks like some lines would have many 3 pixel runs. Ie. 3 pixels @ 3 bits each as: ....001, 111, 101, where 001 is just some palette entry, the 111 is an escape indicating that 3 pixels in a row are this color(the previous, the current, and the next), and 101 is 3 new bits to accumulate for a palette color. Palette colors get replaced in a linear fashion as the situation occurs, so that you could have significantly more than 8(-1 for escape value 111) colors by introducing more of those scenarios(dithering is very effective, and would kill this so perhaps a wash). It may not work, it would also take a stateful conversion program to even test out which would be more development time required, versus what benefit it might be. Interesting at least.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: SPI Ram Video Mode

Post by CunningFellow »

How many clock cycles do you think you could do inverse discreet cosine transforms and hufman encoding.

(I am half being silly here)
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r »

Eh..not sure on that...if I figured out how to do it in 2 cycles, you'd probably find a way to optimize it to 1 anyway :lol:
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian »

D3thAdd3r wrote: Sat Jun 02, 2018 4:34 amA photo is nice since you needn't spend the time creating from scratch of course.
Converting to Multicolor isn't very hard if all 4 colors are freely selectable. Commodore 64 or Plus 4 is difficult since there are 3 or 2 free colors per 4x8 block, the other 1 or 2 colors are global which you may only change line by line. So a multicolor converter would have to look at a much larger region (an entire tile row) with some tailored algorithm. If all 4 colors are free, such doesn't have to be carried out, you can process every 8x8 block individually, and it will produce an okay result.

I don't think much more was possible. If you need the inline mixer (and if you otherwise want to work with a normal RAM tile oriented mode, you do need the inline mixer as you need all the clocks in VBlank which you can have), then you only have a very limited room for preparation, not suitable for processing something spanning an entire row.

If you need more than 4 active colors, you need a palette buffer as you can only use code tile blocks for at most 4 colors (at 16 colors, the code tile approach, no matter how you do it, at best has only the same performance like the palette buffer approach, you can't use either below 5,5 cycles per pixel, even then only with RAM tiles). If you have a palette buffer, you may replace at most probably 2 colors per scanline, and no color within a scanline.

A middle ground could be a 6 color code tile block solution, producing 3 pixels for a byte (216 values), this would work at 6 cycles per pixel. You could use the remaining 30 values to encode stuff, but if you do so, there are no pixel values for the 3 colors being output.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r »

Blah, I spent a couple hours and I have come to the conclusion I was searching for a unicorn. I can't find anything(which fits in 6-8 clocks) which is fundamentally different in any useful way. The only thing maybe, which I don't recall if you mentioned already, is the rather obvious 16 color mode that used pixels 0/1 from SPI Ram, pixels 2/3 from flash, pixels 4/5 from SPI Ram, pixels 6/7 from flash, for a 16 color mode which requires a 256 byte palette(without 4 colors per 8 pixel restriction and no attributes to consider). The flash cost is very high of course, so stretching it to 7 cycles is nicer than 6 for screen coverage. Not realistic to extend to 32 colors with an attribute that I see unless it were tile based. This is probably already a subset of another solution anyway, I have only had time to dabble in and out lately so keeping up with state of the art has been futile.

Do you think there is any specific solution which is over all more general purpose than other solutions? That I can see, it is quite image specific which solution is best and no way around it(though I would lean towards attributes winning this one). I think I may not include bitmap for Mode 15 for this reason, as tiles and ram tiles work pretty well for a title screen also.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian »

D3thAdd3r wrote: Sun Jun 03, 2018 7:18 pmThe flash cost is very high of course, so stretching it to 7 cycles is nicer than 6 for screen coverage.
That already exists: Mode 748, row mode 4 (the repo links are 404 as it is in Master now, you will find the code here).

If you are okay with low-res, an idea could be double-scanning with a line buffer, thus trading off vertical resolution for improved horizontal resolution. 4bpp would work well this way at 9 clocks per pixels, which is exactly square when doubly scanned (up to 160x112 pixels image), but this wouldn't align well with Mode 3's pixel width. Doing this at 6 cycles per pixel or 5.5 cycles per pixel might be possible (the line buffer permits loading part of a line early to offset the low bandwidth of the SPI RAM), but I am not entirely sure.

I would really suggest attribute mode for this, it is perfectly possible (if I could do a complete useful mode at 5cy / pixels, 2bpp, then this is relatively easy), and it is possible to desing a good converter for it.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r »

I know you came up with a 3 cycle 1bpp+attributes mode that I believe was a code tile technique. Did you already do some non-attribute 3 cycle variant that does not use extra rom space? So far I only see loading the SPI Ram byte, then jumping to 1 of 256 pre-baked pixel output routines via ijmp and obviously that eats a lot of rom. I am only interested in outputting either 0 or 255 for a pixel color, but even 3.5 cycles doesn't seem to work without unrolling(or a weird pattern of 4 and 3 cycle pixels maybe :? ). The hypothetical thing I imagine this for has rom as a premium, so if it were impossible at 3(without gobs of rom) then 4 becomes more attractive as it lowers the blitting burden anyway. Thought I would ask before I wasted too much time on it if it has already been done.
Post Reply