SPI RAM Mode74 development

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

SPI RAM Mode74 development

Post by Jubatian »

Now that we know that the SPI RAM is reliable after a little fix on the PCB, I picked up my SPI RAM oriented Mode 74 variant.

First actual SPI RAM tests now pass, the screenshot below and the attached example program demonstrates it. The entire image is fetched from SPI RAM and RAM at 4bpp, still having an inline mixer (234 cycles). 12 bytes of RAM is necessary to produce a line.
The attached example running in CUzeBox
The attached example running in CUzeBox
screenshot.png (53.94 KiB) Viewed 8789 times
The video mode is on my fork of the Uzebox repo (Mode 748). The image was generated by my image quantizer which I modified to produce images suitable for use with Uzebox.

The total image size is 20736 bytes (192 x 216 @ 4bpp). Of this, 18144 bytes are in SPI RAM, 2592 bytes in RAM.

The video mode has Mode 74's normal tiled variant (192 ROM tiles + 64 RAM tiles) for game content (tested, works), a little simplified. For SPI RAM, it has the following options:
  • 192 pixels wide 4bpp, needs 96 VRAM bytes / tile row (this is demonstrated now).
  • 192 pixels wide 3bpp, no RAM requirements (still buggy).
  • 384 pixels wide 1bpp with 96 VRAM bytes / tile row (foreground / background color for each 8x8 tile) (untested).
  • 384 pixels wide 1bpp with no RAM usage (global foreground / background colors) (untested)
All five modes align with each other (the 384 pixels wide ones are 3.5 cycles / pixel ones), it is possible to have arbitrary splits between them. Of course for the normal ROM + RAM tiles mode, sprites may also be fetched from the SPI RAM (this option can coexist with an SPI RAM sourced on-screen slice).
Attachments
m748_test_spi4_arch.tar.bz2
The example program
(161.93 KiB) Downloaded 403 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

It seems your quantizer does an excellent job with dithering. If one considers accurately the amount of variety, resolution, and color depth, I would say there have been few things on Uzebox that looked that "detailed" on Uzebox. The art style is nice also. Definitely eager to see more, and I am guessing this art style might also be seen in a future RPG :ugeek:
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

This is about the maximum possible if you want to get anything on-screen without using the Flash. The image by the way is from this one, I think I will keep using it for examples for the mode as I released it under GPLv3 / CC-BY-SA, which is compatible with Uzebox's own license. For a real game, I would rather do original pixel art (192 x 200 or so is large enough for great stuff, a good pixel artist can get any visual impression done with 16 colors), however the tool could be nice who doesn't want to get so much involved in graphics.

What I somewhat miss from the package is a 2bpp mode at 384 pixels width, as far as I checked this is possible, but only with a very contrived line layout and gobbling up 25 or so kilobytes of ROM. So such would only work as a standalone mode, nothing really useful (however a similar idea at 4.5cy / pixel would be more possible, giving a nice square pixel 2bpp bitmap mode served entirely from SPI RAM, maybe useful for some games).
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

I fixed and added some stuff, and now the 3bpp mode is also functional!
Mode748 row mode 5: No RAM usage
Mode748 row mode 5: No RAM usage
screenshot.png (42.88 KiB) Viewed 8734 times
This mode is a plain SPI RAM mode, similar to Alec's Akuma demo, except it is 192 pixels wide at 7 cycles per pixel with 3 colors per pixel. No RAM usage (except for the palette buffer in the 0x0E00 block, as visible in CUzeBox, only 64 entries are actually used since only the first 8 colors display). This might be useful for actual game material (if an SPI bitmap with a little weird pixel arrangement is OK), or as free "eyecandy" (like a HUD) around a normal ROM + RAM tiles game field.
Attachments
m748_test_spi5_arch.tar.bz2
Mode748 row mode 5 test
(69.69 KiB) Downloaded 386 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

Looks great, for a second I thought you showed the exact same image. Looks like someone sat down and manually converted the whole thing 16->8, very nice. A useful mode for a lot of things, considering you can mix them. For me I get intimidated to try and understand them all, but it has lots of potential to be maximized.

That 384*4 colors seems a great mode, not sure if you are going to realize that or not, but I would put it to use at least for an experiment. Maybe speed is some issue, but with double buffers I feel you could make a reasonable GUI for an OS. 25K code wouldn't matter, since a useful OS probably needs some virtual machine to allow running programs from the SD card. It would be fun at least to make some windows drawing code and a cursor, and see where it can go. No other way to do such a GUI(that would actually be useful resolution) besides an SPI bitmapped mode.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

The 384 pixels @ 4bpp requires the same amount of RAM like the 16 color mode above (that's why it is tricky: it outputs more data than what the SPI bandwidth can serve). Probably this isn't really what you want there.

At 4.5cy per pixel I think it is more affordable as that requires no RAM, and it is a simple, small code (4.5 x 4 = 18 cycles, one SPI transaction). You could have up to 320 pixels width with that (that's the same width like Mode 3 has, so the edges aren't necessarily visible), a nice 4:3 mode would be 288 x 216 using slightly less than 16Kbytes of SPI RAM.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: SPI RAM Mode74 development

Post by Artcfox »

Wow! These graphics are impressive!!!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

I created a test for the 384 pixels wide 1bpp + Attribute mode, as below:
1bpp with Attributes
1bpp with Attributes
screenshot.png (48.07 KiB) Viewed 8633 times
It has slightly higher resolution than the Akuma demo to align proper with Mode 74's 7 cycles / pixel, possibly this is the highest resolution reasonably possible with attributes. It is a tricky partial code tile mode taking only about 3 KBytes of ROM, capable to also serve non-attribute mode. (Possibly 3 cycles per pixel could also be done with attributes, but that certainly would tax ROM heavily, and its RAM demands might neither be affordable)
Attachments
m748_test_spi6_arch.tar.bz2
1bpp with Attributes
(187.89 KiB) Downloaded 386 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

Very nice mode. Do you have an idea how many frames per second could be done with this rewritting the entire screen?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

D3thAdd3r wrote:Very nice mode. Do you have an idea how many frames per second could be done with this rewritting the entire screen?
The calculation is fairly simple. You can do about 100 SPI transaction at most in a scanline (for a moment of course forgetting about the HSync interrupt, with that present it is about 90 transactions). You have 37 lines (excluding VBlank task interrupt if any) when you display 224 (37 VBlank + 1 lead-in + 224 display = 262 total lines). One line of this mode is 48 SPI bytes, let's just say 50. So for every displayed line, you need roughly a half VBlank line of CPU time to fill. If you copy within SPI RAM, then for every line displayed, you consume a VBlank line of CPU time. So a frame copy within SPI RAM (or SD to SPI RAM) would take about 6 - 7 frames.

If you plan for a game with sprites, then a better approach would be doing only one full copy to initialize the screen (or two copies onto two pages for double buffering), then you draw sprites over it, and before starting the render of a new frame, you clear away the sprites only (by refilling only the sections of background the sprites covered). This wouldn't be very fast either, but likely suitable for a graphic adventure game.
Post Reply