A little bit of Mode 9 insanity

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally »

Is there enough time in HSync to load some of the graphics? Such that an image could be loaded 120x112 at 4bpp. Perhaps preloading half of the image before the display routine, then replacing the lines as they are displayed. If half a line could be loaded on each line, then everything could be displayed with smaller amount of RAM.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian »

I thought about such modes, but it is messy, you may remember the pitfalls from the development of Tempest by CunningFellow. The biggest problem is that SD cards may demand arbitrary time between sectors, and it would be quite difficult to interleave code which polls the card and loads the bytes with the graphics output. Using only the HSync isn't really viable if you want to retain the mixer and use a decent width (my Mode 74 can do it, but only at most one 512 byte sector within a frame, which is not much for the purposes of graphics generation).

A big further problem could be the ROM cost. To get such a mode which is more tolerant to crappy SD cards than Tempest would require larger amount of code, likely unrolled scanline renderers, and your ROM reasources aren't exactly abundant with the use of code tiles (and this is mathematically impossible to be reduced any further). So I would really suggest avoiding this path to favor using your ROM for more game content (unless you already designed it so that it is loaded from SD, that is, you see you don't need too much further ROM).

What about 2bpp by the way? 120x112 with good RAM management could even fit, but if you interleaved graphics with story or other material (as text mode rows) you wouldn't even need a full 112 pixels double scanned height for the graphics.
yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally »

I already load some of the game content from SD. The 2bpp 120x112, would work great. Not much would going on in the game itself during the enhanced display, so you could use more cycles if needed. I would only need to check for button presses, to exit this mode, or switch to the next image. I am at 49008 bytes of program space. I have planned on creating an sd music load routine. Which would save a little over 3.5k. I was also looking into saving a temp file to the sd card. If I get that working, it would free up easily 800+ Bytes. These are the only major features left to add to the game.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian »

I added the new feature, you can check it out from here: https://github.com/Jubatian/uzebox/tree/mode90

I also pulled and merged the uzebox/master branch, so you should have a proper fresh kernel there. The new mode is identified as Mode 92, which is almost fully compatible with Mode 90 (but supports only 8 pixels tall tiles which shouldn't be a problem for you). Its prefixes remain "m90", so in the game you only need to modify the makefile to use Mode 92 instead, and it will work. You don't need to re-generate the tileset (compatibility there is retained).

The 2bpp framebuffer support:

By default it is off, and it would provide a quad scanned result using colors 12-15 of the palette and the normal VRAM (the 60 bytes used for a tile row provide the pixels for this framebuffer as well as 2x30 bytes for the two pixel rows within a tile row).

To turn it on, set m90_split to the line where you want to switch back to "text" mode (so you can have 2bpp framebuffer on the top of the screen, "text" mode on the bottom). Setting this to 0 turns off the 2bpp framebuffer, setting it anything above the current render_lines_count (224 typically) will turn the entire screen into 2bpp framebuffer.

To get double scanning (so 120x112 total), you need to set up m90_exvram to point at the extra VRAM from where the odd rows come. By default it is pointed to vram resulting in the apparent quad scan. For one tile row of 2bpp framebuffer, you need 60 bytes of this.

Hope it is okay and useful!
yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally »

I installed the new kernel, thanks. However There is some screen corruption. The whole screen is shifted the right, and loops around. Also the top line and a quarter are damaged. Perhaps the whole screen simply starts at the spot on the second line, which causes every line to be off.
roguze_92.png
roguze_92.png (11.88 KiB) Viewed 7035 times
Roguze_play.png
Roguze_play.png (8.33 KiB) Viewed 7035 times
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian »

What happens with the original Mode 90 with the new kernel? I tested these including the new 2bpp mode (just not with something overly visual worth to present), and they behaved OK with correct sync signals. So I need a bit of feedback on where exactly the thing goes wrong.

So please test (and re-test if applicable):

- Current game code with the old kernel + Mode 90 (if you don't have it, you can check it out by this commit, just to verify that things still build proper).
- Current game code with the new kernel + Mode 90.
- Current game code with the new kernel + Mode 92.

Where things start to fall apart?

As a quick try you might verify whether you do a completely fresh build, that there are no old object files etc. laying around. Such might also mess up things, and it might not be trivial if you use some IDE which hides the make process.
yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally »

I'm running eclipse for the ide. If I set it to mode=90, and do a clean then build everything works fine. Then I set it to mode=92, do a clean, and a build. I get the results I posted before. Then setting it back to mode=90, clean and build, problems disappear. Since I can make the problem appear and disappear, I figure the clean is cleaning everything.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian »

OK, then definitely something is there relating to Mode 92.

The two modes use different amounts of RAM for internal state which causes everything else slightly moving around. I think there might be some code somewhere else which might rely on some alignment which breaks with this change.

Try to add this at line 242 of videoMode92/videoMode92core.s (in the kernel):

Code: Select all

        .space 2
This will pad Mode 92 to Mode 90's RAM consumption, so everything should align again (well, dropping arbitrary tile height actually saved 2 RAM bytes even with the 2bpp mode introduced...).

If that doesn't work, then look for a ".map" file produced in the build process. Search "vram" in it, it should be some line reading like

Code: Select all

        0x0000000000800100      vram
Post what you find in that area (belonging to uzeboxVideoEngineCore.o). That could give some indication why it doesn't work.
yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally »

adding the .space 2, didn't help. It seemed to make things worse. The screen was mostly black with that change. The map file has vram at 0x0080010e.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian »

Yllawwally wrote:The map file has vram at 0x0080010e.
That's a problem! Many video modes require it to be at 0x0100 (and not at 0x010e as indicated here), so I went with the flow when I got fed up with that you can't even add a constant with "subi" if it is to be resolved at link time (it can't even do the negation), so Mode 92 is locked to have the vram at 0x0100 (Mode 90 is not, the scanline entry is different).

For an ugly hack, you might change lines 316 and 317, rewriting the constants there to 0xF2 and 0xFE respectively. But by the .map file you can also see with what linking order you ended up with. Correct it so uzeboxVideoEngineCore.o comes first (this is a required thing anyway for most other video modes as well).

EDIT: Forget it, check out again. https://github.com/Jubatian/uzebox/tree/mode90 . I forgot that the assembler can actually do this if I use extra parentheses around vram. Still, no warranties whether something else won't break in the kernel...
Post Reply