SPI RAM Mode74 development

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 Mode74 development

Post by Jubatian »

nicksen782 wrote: Mon Apr 02, 2018 8:01 pmRemember how Bowser in Super Mario World would be zoomed on the screen in between battle phases? You are using the same graphics but with the extra RAM would there be enough time to do something like zoom effects?
I can't quite recall or find it now, but I guess you refer to some sprite zooming technique.

The sprites are in SPI RAM, making it difficult to apply effects on the sprite graphic itself, but the SPI RAM is quite large. You can use that to your advantage: precalculate zoomed sprites before starting the scene using them, so you can just output them like normal when the game arrives to the point they are needed.

There wouldn't be much "extra RAM" by the way, as like normal for bitting modes, you have RAM tiles, and you naturally need as many of them as you can afford for intensive sprite action. Mode 748 is even a little worse in this regard to Mode 74 as the latter has a sprite importance system which does great job throwing away minor sprite parts when the RAM tile limit is exhausted, maintaining an acceptable overall look. This is not really possible to implement in Mode 748 due to the different technique used for RAM tile management (which was demanded by the SPI RAM background).
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

I would say the mode is complete, and could be used for games, likely I will only do bugfixes on it from now if any problem surfaces.

Should (could) it go into Master (along with some updates on the Wiki)? It has several examples included, and is a lot easier to use than Mode 74.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

It should definitely be in master.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

I added it. Also it got its Wiki entry in SPI RAM video modes, hopefully with enough information for a start.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

Have you run any tests involving scrolling and sprite blitting? I was thinking to make a customized video mode to solve my ram problems, but it is starting to look like a really big project combined with the game and everything else. This seems like it would solve these problems for the sacrifice of color depth and horizontal resolution(which is better than simply not being able to do what I want to do!). My understanding of the scrolling in this, is that the entire vram needs to be shifted and then the new data moved in place which will take some cycles. The idea of SPI Ram source sprites is very appealing, but I am concerned combined with other elements I wont be able to blit as many sprites as Mode 3(due to cycles, this is what happened on several attempts with Mode 13 15 color mode).

Just curious if you have some rough figures for scrolling a screen and blitting 40 ram tiles from SPI Ram; how short a screen it needs to be.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

D3thAdd3r wrote: Sun Apr 29, 2018 3:25 pmHave you run any tests involving scrolling and sprite blitting?
It is a few posts above, the code of the example is in the repo, you can experiment with it. A 200 pixels tall screen usually should give enough time to process considerable amount of sprites.

You don't need to touch the VRAM at all in a scrolling setup, at least as long as you can throw the full map as-is in the SPI RAM, the example demonstrates it. You may look at the bg_move() function in the example which is responsible for positioning the viewport over the SPI RAM background.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

Ah perfect thank you!
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

Did any of you experiment with this mode? I would like to hear some feedback on how complex is to set up display in it, how well its new concept on the handling of row modes work.

I got a game idea for a normal "unexpanded" Uzebox, and would like to design some more video modes using this concept, now for that particular game a 2 bits per pixel "high resolution" (5 clocks per pixel, 288 pixels width maximum) mode similar to Mode 74, however using Mode 748's concepts as I think this is significantly simpler to use (although possibly not as efficient).

2 bits per pixel is attractive to me as it can have many RAM tiles with low RAM demand, and if you want, you can display reasonably large images loaded from the SD card into memory, suitable for graphics adventures RPGs and likes. It can also pack a lot of tiles into the ROM, which, even though colors are limited, could be nice to add diversity.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

Jubatian wrote: Sat May 05, 2018 9:35 am Did any of you experiment with this mode?
I have not yet, just preliminary looking into it as a possibility until I get time to dig further. As for features, like M74, it is quite the luxury video mode with all those useful options(color remapping for instance, I wish M3 had or at least mask/ANDing with a flash source...palette reload in 1 scanline, nice!). The manual for it seems to explain everything quite well. One thing I did not notice anywhere, is there some method for reading and writing from/to SPI Ram that would cooperate with the kernel's scanline reads? I was hoping to find some mechanism where a volatile variable could indicate if the SPI Ram is busy, and also if a user operation was interrupted if for instance taking too long in a user callback. Not sure if it would be some general purpose thing or not, but if it were possible to schedule these things for the kernel to do it safely, it could be quite handy.
Jubatian wrote: Sat May 05, 2018 9:35 am 2 bits per pixel is attractive to me as it can have many RAM tiles with low RAM demand, and if you want, you can display reasonably large images loaded from the SD card into memory, suitable for graphics adventures RPGs and likes.
Sounds interesting. I always think for the lower bit depths ideas, something grayscale like graphics as the Gameboy used to have could be engaging. I suppose the possibilities for offloading to ram tiles would let you have a ton of large graphics, beyond what cartridge games of the day could possible do. If you don't have to worry so much about limited sprites you could really have an engaging game with a mode like that at 4 colors(of course assuming even better than this, as you could likely reload the palette):
2bppAdventure.png
2bppAdventure.png (90.79 KiB) Viewed 7117 times
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

D3thAdd3r wrote: Sat May 05, 2018 6:27 pmOne thing I did not notice anywhere, is there some method for reading and writing from/to SPI Ram that would cooperate with the kernel's scanline reads? I was hoping to find some mechanism where a volatile variable could indicate if the SPI Ram is busy, and also if a user operation was interrupted if for instance taking too long in a user callback. Not sure if it would be some general purpose thing or not, but if it were possible to schedule these things for the kernel to do it safely, it could be quite handy.
There is no such thing as there is no real use for it. Mode 748 accesses SPI during the full frame, so you have to do your SPI stuff between frames. In VBlank the mode leaves SPI alone. Since the M74 blitter has no automatic sprite render capability, that neither can cause any trouble: SPI will be accessed when you blit sprites from your main program, and not any other time. If you happen to be interrupted by a video frame, the video frame will cancel any pending SPI access, so video will always be fine (and only your main program SPI access will be broken, which is a tolerable outcome for blitting sprites from SPI RAM). The video frame can not be delayed at all, so nothing really can be done there. I imagined one would turn the display off for the duration of SD accesses, as with the SPI RAM present, one could load assets for a scene in one pass. If you still wanted to display something, such as a loading bar, you could do a safety toggle of the Mode 748 display enable flag: Wait Vsync, then on the beginning of the VBlank you turn it off, you do the critical SPI task, then turn it on. If for any reason the critical task couldn't finish in the VBlank (for example a very unlucky slow read from SD), you only get a frame of blank screen without breaking your SPI task (Toggling M748 Display Enable is perfectly okay, M748 even has a disabled screen color feature: it just causes M748 to output empty rows, not affecting the kernel at all. This case of course the mode leaves SPI alone).

2bpp: Yes, something like that, I even programmed the original GameBoy for a little (displayed some images on it). There are diverse possibilities here, the current 5 cycles / pixel scanline code is capable to optionally have an attribute source (so one color can be replaced for every tile if you want), and it can also set an arbitrary split between ROM and RAM tiles from a register (so you can even change between scenes depending on what you need). 64 RAM tiles take only 1K, and at that point if they are used for sprite targets, likely a CPU bottleneck will be near (blitting capability, I don't know yet how it would relate with the M74 blitter, whether it could be faster or would be slower). For a single screen scene (No attributes used, 1K VRAM + 1K RAM tiles), this could even permit reserving some RAM for sprites loaded from SD.
Post Reply