A couple of questions about background modes and memory maps

[AzimuthFE]

I have been reading about the various background modes on the snes but I can't get it to "click".

Could some please explain in layman's terms what "offest-per-tile" actually does? Also, I have read that mode 5 only takes half the pixels from a 16x16 tile. What's the point? I'm very confused. I would be very grateful if anyone could point me to videos of games that use each background mode so I can actually see them in action.

My second question is more of a hypothetical question relating to the mapping of the ROM in the cartridge. I understand that the address mapping is handled by the cart itself. Could someone, if they were so inclined, create a cartridge with no mapping at all (i.e. the 2MiB from banks $00-$3f, the ~4MiB from banks $40-$7f, 2Mib from $80-$bf and the 4Mib from $c0-$ff) to create a ~12MiB ROM? I get that this would be massively overkill for a snes game, but would it be possible?

[Ramsis]

Also, I have read that mode 5 only takes half the pixels from a 16x16 tile. What's the point?

Mode 5 takes the even pixel columns of a tile and displays them as "half-pixels" on the mainscreen, while the odd ones are displayed on the subscreen (or vice-versa, depending on whether bit 3 of SETINI/$2133 is set or clear). The whole point of this is to essentially double horizontal resolution (i.e., your image becomes 512×224 px in size).

One thing to watch out for though in Mode 5/6 is that the smallest possible tile size is 16×8 ("half-pixels" × "full" pixels), not 8×8 as you might expect.

[niconii]

Offset-per-tile allows you to scroll tiles individually. It uses values in BG3 as scroll values rather than tile data IIRC; I don't have much experience with it.

Mode 5 is one of the high-res modes (doubling the horizontal resolution from 256 to 512), the other being mode 6. Taking half of the pixels and forcing a tile width of 16 pixels are part of how they achieve that effect.

Basically it works like this: say you have four pixels with colors 0, 1, 2, and 3. Normally, the SNES renders them like this, with each character representing half of a normal pixel:

Code: Select all

00112233

Now, the SNES has a feature you can turn on caled Pseudo Hi-Res. If you had pixels A, B, C, D on the sub-screen at the same location as 0, 1, 2, 3 on the main screen, it renders this:

Code: Select all

0A1B2C3D

This is pretty useful just by itself, if kind of unwieldy, since hi-res images have to have their pixels split between the two screens. But mode 5/6 have additional tricks that make this nice to work with.

What they do is take a 16-width tile and draw it as if it were an 8-width tile. If it's the main screen, it'll take half the pixels and draw 0, 2, 4, etc., and if it's the sub-screen, it'll take the other half and draw 1, 3, 5, etc.

So, the trick is, if you have a row of a 16x16 tile 0123456789ABCDEF, normally it's drawn:

Code: Select all

00112233445566778899AABBCCDDEEFF

But, in mode 5, the main screen would have:

Code: Select all

0022446688AACCEE

And the sub-screen would have:

Code: Select all

1133557799BBDDFF

So if you set both screens to read the same tile data, what you get on-screen is:

Code: Select all

0123456789ABCDEF

That's right! The tile data just shows up half as wide! In the end, no pixels are actually missing.

Regarding the memory mapping question, yes, it is possible. That said, a cartridge like that would've been incredibly expensive back when the SNES was current.

[lidnariq]

a cartridge with no mapping at all (i.e. the 2MiB from banks $00-$3f, the ~4MiB from banks $40-$7d, 2MiB from $80-$bf and the 4MiB from $c0-$ff) to create a ~12MiB ROM? I get that this would be massively overkill for a snes game, but would it be possible?

In fact, this is the memory mapping used by the decompressed (S-DD1-less) Star Ocean translation.

[tepples]

Could someone, if they were so inclined, create a cartridge with no mapping at all (i.e. the 2MiB from banks $00-$3f, the ~4MiB from banks $40-$7f, 2Mib from $80-$bf and the 4Mib from $c0-$ff) to create a ~12MiB ROM?

The largest SNES flash board at infiniteneslives.com implements exactly this. You'd end up with 95 Mbit of accessible ROM, the other 1 Mbit being behind RAM at $7E0000-$7FFFFF. But 96 Mbit of mask ROM would have cost Neo Geo game prices.

[AzimuthFE]

Thank you for your answers! I think I have a more solid grasp of the backgrounds, now. At least enough to have a go at implementing them myself.

So is the Star Ocean ROM only available as a physical cart in that case, or do emulators support modes other than ExLoROM/ExHiROM (the only >8MiB mapping I'm familiar with)?

[tepples]

Authentic copies of Star Ocean have a 48 Mbit mask ROM and a the same decompression coprocessor used in Street Fighter Alpha 2. The bootleg version is 96 Mbit with everything decompressed.

What do you plan to use all this space for?

[AzimuthFE]

Authentic copies of Star Ocean have a 48 Mbit mask ROM and a the same decompression coprocessor used in Street Fighter Alpha 2. The bootleg version is 96 Mbit with everything decompressed.

What do you plan to use all this space for?

Haha I wish I had the creative talent to fill all that space. I'm simply curious, that's all.

[93143]

Could some please explain in layman's terms what "offest-per-tile" actually does?

In practice it's mostly used for column scroll. Allows wavy effects like the lava in Yoshi's Island. Combined with HDMA for line scroll, you can rotate a BG layer through a decent angle before the artifacting gets too bad; this is how Star Fox did its banking effect (only on the backdrop; the Super FX layer was drawn at the proper angle), and also why it didn't do 360° rotation while the backdrop was visible.