nesdev.com

Just 1 whole screen uncompressed.

(256/16)*(240/16)
16*15 = 240.

Or (256/16)*(256/16) = 256
if your "screens" are defined as 256x256 like mine are.

I use 32x32 metatiles because I only have 1 page of RAM allocated to this, and I need 4 screens stored. I store my screens in RAM because otherwise I would have to battle through a few levels of compression to check every point. This method lets me do the time consuming stuff (working through the RLE compression of the screens) only on the frame a new screen is scrolled to, while the fast decompression (which 16x16 tile of the 32x32 tile are we in?) is done every time a point needs to be checked.

If it is not time consuming to decompress your data, you could certainly just read from ROM rather than doing what I do.

If it is time consuming, you can get away with using only two pages of RAM to store separate screens of 16x16 tiles for this method since your game only scrolls horizontally.

SMB1 uses two 16x13 pages to cache the decompressed map.

Kasumi, thank you for your explanation. That's what I just calculated too... can fit just one whole screen in a page of ram. I see what you are saying about we might only need 2 pages of ram... since we're only scrolling horizontally.

I don't know if we will use compression for our maps... Thank you for your recomendations!

I guess this works because of the blockage of 24 scanlines on the top and bottom of the NTSC SDTV screen... ? That's incredible to know! Thank you tepples! Do you know if they use the same two 16x13 pages in the PAL version? (PAL TVs block the same number of scanlines?)

16x13 is used by Nintendo on SMB1... They know awesome things! That's a savings of 96 bytes right? That's quite a lot!

The 16x13 is because the top 32 scanlines are a status bar.

Oh... ok thanks for replying tepples. : )
Hold on ...16 - 13 is 3.
3 * 16 is 48.
48 - 32 = 16.
16 / 2 = 8. So, are 8 scanlines hidden on the top and bottom edges of the screen?

16-13 is 3. But the screen is not 256 pixels high.

(240-32)/16 = 13.

_________________
https://kasumi.itch.io/indivisible

Ah... yes, you were able to figure out my math. I didn't need to color the numbers; thank you Kasumi!



(correct screen height - status bar height)/16 = 13.
Why divide by 16? How does 13 relate to the number of hidden scanlines at the top and bottom edges of the screen?

16 is the height of a metatile. When you divide by 16 you get the number of metatiles in each column, and with that you can calculate how many bytes a screen would take if stored uncompressed in RAM.

The fact that there are hidden scanlines doesn't mean every game has to do anything special about them. Most games show parts of the map in those areas normally, they just don't put important objects or structures there, but there's usually something there.

ninja'd by Tokumaru, but as usual: Posting anyway.

You divide by 16 because that's the metatile size. You subtract the height of the status bar (32) from the screen height (240) and divide by the metatile height (16). You get 13.
You divide the screen width (256) by the metatile width (16). You get 16.

So, 16x13 is how much many bytes of RAM a screen takes up in Super Mario Bros. (According to Tepples, I haven't checked myself).

It's only related to the the possibilty of scanlines being hidden as a cause/effect thing. Super Mario Bros. probably couldn't store its "MARIO WORLD TIME" at the VERY top of the screen, because some TVs might cut it off. If there was just map up there, it wouldn't matter if it got cut off. But it wasn't, so they moved the bar down which happened to have the bonus of saving some extra RAM/ROM. Since the top of the screen is scroll locked to keep the status bar from moving, nothing solid could be put there anyway since it would look strange not scrolling.

I've said how I do it and why. We've said how Super Mario Bros. works. Decide if you like either, or come up with something that suits your own game's needs better. You should be making design decisions based on what YOU need. If Super Mario Bros. didn't need to display so much text, it could have used sprites to display its information. This would mean the top of the screen wouldn't need to be scroll locked, and it could use 16x15 screens. They made their decisions based on exactly what they wanted and needed, and you must do the same.

When I opened the debug menu in FCEUX and pressed Step Into the PC changed from $8007 to $800A

Why is the PC inside $8000? My code starts at $C000...

btw, thank you tokumaru and Kasumi! I understand I can and must do this.

If you don't have any subroutines (or any kind of executable code) in $8000-$BFFF there certainly is a bug somewhere. Are all your vectors properly defined at $FFFA-$FFFF? Maybe an invalid IRQ or NMI address is throwing the PC off? Can't really say without seeing more.

tokumaru, thank you for your quick reply! My vectors ($FFFA-$FFFF) seem to be fine... in the .lst file they are listed as 9E C2 00 C0 37 C3 so they are all after $C000 i think...

The PC, within the $8000 - $BFFF range appears to be broken... it just switches between two values over and over and over again.

Try opening the ROM in FCEUX for Windows (or another similarly capable debugging emulator) and putting an execute breakpoint on $8000-$BFFF, and you may have a clue as to how you ended up there.

I havent used FCEUX for Windows very much... but I tried to set an execute break point on $8000-$BFFF. The game continues to run these two lines over and over:

Maybe a bug in FCEU debugger if your ROM is 16KB? Try it in some other debugging-capable tool.

EDIT: Many apologies if my response is way off the mark. I just realized I stepped into this thread on page 33!