Technically, does MMC5 support CHR RAM instead of CHR ROM?
As far as I can tell, no existing mapper prevents the use of CHR RAM.
And I can't think of a feature that would necessarily require the use of CHR ROM, although a specific implementation could prevent writes to the CHR RAM.
The main problem is that with the complicated CHR-bankswitching involving two virtual banks (for BG and for sprites), it will be hard to know where in the CHR-RAM you're writing to.
1. As far as know, there are no official games within CHR RAM, but CHR ROM.
2. As developer, you wouldn't create a game without CHR ROM, since the board offers a complex bankswitching system to improve graphics.
3. As emulator author, I've created a check for CHR ROM to this mapper. Dirty headers might bring the wrong mapper number. In other words, if a game is marked mapper 5 and has no CHR ROM, the emulator halts the loading.
Well, using CHR-RAM in place of CHR-ROM in any mapper with CHR bankswitching more or less presupposes the emulator iNES 2 support, except for 1 or 2 special cases of mappers previously known to have 32k CHR-RAM. Otherwise there's no way to specify how much CHR-RAM you need.
I think you'll find a lot of older emulators will not do CHR-RAM for arbitrary mappers, even the "0 CHR-ROM = normally assume 8k CHR-RAM" iNES 1 level support is pretty spotty from what I've seen.
If the emulator supports iNES 2 it really probably should let you do it for all mappers.
re: #2- nonsense. Lagrange Point uses bankswitching of CHR-RAM, and there's no reason to think that it wouldn't be more useful with even more CHR-RAM or more sophisticated bankswitching schemes.
Bankswitched large CHR-RAM gets you all of the advantages of both mentioned
on the wiki, with the sole exception of "now you have to initialize it".
If your PRG-ROM size is constrained by register size or other practical limits (e.g. PowerPak's 512k) being able to put 256k or 512k of uncompressed CHR in a separate ROM is a pretty significant advantage by itself.
But yeah I don't see what would be confusing about where CHR-RAM goes in the MMC5 mapper. Where once was ROM is now RAM.
Even in the Napoleon Senki mapper, I would think that the original implied CHR-RAM would remain in place and an iNES 2 specified CHR-RAM would replace the previous CHR-ROM portion.
https://wiki.nesdev.com/w/index.php/INES_Mapper_077
lidnariq wrote:
re: #2- nonsense. Lagrange Point uses bankswitching of CHR-RAM, and there's no reason to think that it wouldn't be more useful with even more CHR-RAM or more sophisticated bankswitching schemes.
Hi?
Lagrange Point is
official and
NOT a MMC5 game. Period.
Quote:
2. As developer, you wouldn't create a game without CHR ROM, since the board offers a complex bankswitching system to improve graphics.
Lagrange Point is a counterexample. "Complex bankswitching system" does not preclude using bankswitching on CHR RAM.
By the way, does anyone know how does Lagrange Point exactly uses bankswitched CHR-RAM ? Since there's only 8k of it, I don't really see the point.
(Sorry for derailing off-topic).
I don't know about Lagrange Point specifically, but there are a few things you can do with bankswitched RAM even if there's only 8KB of it. Changing the order in which tiles are mapped in the PPU address space makes background animations possible without the need for name table changes, just like with CHR-ROM, but with the disadvantage of reducing the amount of unique tiles you can have on screen. You can double buffer background pattern animations that take longer than a vblank to update, and only switch the graphics when all tiles are ready. You can also make the same set of tiles available on both pattern tables, for objects that can be displayed both as background and as sprites (e.g. collectible items), which, if animated, will only need to be changed once.
Bregalad wrote:
By the way, does anyone know how does Lagrange Point exactly uses bankswitched CHR-RAM ? Since there's only 8k of it, I don't really see the point.
I think the game uses mostly 8x8 sprites, and primarily uses this to share tiles with the background.
Seems like a case of a feature they already had in the mapper (which was designed for 256k CHR-ROM) that they just decided to use because it was slightly convenient.
rainwarrior wrote:
I think the game uses mostly 8x8 sprites, and primarily uses this to share tiles with the background.
Even when you're using 8x16 sprites you may want to use this if you're also using MMC3's scanline counter, since it gets confused by sprites being fetched from the background side.
rainwarrior wrote:
Seems like a case of a feature they already had in the mapper (which was designed for 256k CHR-ROM) that they just decided to use because it was slightly convenient.
In which part of the game does sprites use tiles from the background or vice-versa ?
Personally I think the graphics in LP are very standard/average for NES and I fail to see where they would have done clever tricks like that. The only impressive thing is the elevator's animation and the cutscenes there is before some boss fights.
Quote:
Even when you're using 8x16 sprites you may want to use this if you're also using MMC3's scanline counter, since it gets confused by sprites being fetched from the background side.
As far as I know, few games ever used MMC3+CHR-RAM, and of those who does, they do not bank-switch CHR-RAM after the initialization, but simply uses it as a good old 8k block.
I don't know of any specific commercial games that do what I said, I was just listing possible uses of 8KB CHR-RAM bankswitching.
In my old Sonic engine I needed to have monitors and rings show up as both sprites and background, and they're animated, but 8x16 sprites fetching from the background side would've broken the scanline counter, so this was a good solution.
Bregalad wrote:
rainwarrior wrote:
Seems like a case of a feature they already had in the mapper (which was designed for 256k CHR-ROM) that they just decided to use because it was slightly convenient.
In which part of the game does sprites use tiles from the background or vice-versa ?
I thought it did this on the title screen and intro, but looking again the sprites used aren't common with any of the background tiles used at the same time.
However, the banking is constantly being used, and very often has banks in common between the two pages. I think that's why I had made that assumption.
Anyhow, I found a much better use for it while looking at it: when walking around and talking to people, it changes banking at a scanline split, so the field can use different background CHR than the text overlay.
With Mesen's debugger you can put the PPU space $0000-1FFF and CHR space $0000-1FFF in two different windows side by side, which is a good way to see at a glance how the banks are used.
I dunno what the logic is behind the specific banking patterns (a flat 8k mapping is never used, it's always some weird combination), but probably it was managed automatically be a tool anyway. I think there's probably a bunch of little things you could do this way. It's not like they had much incentive to stick to flat CHR-RAM banking.
The following layout for MMC3 TG/TNROM should make good use of 8 KiB CHR RAM and allow sharing tiles between background and sprites without interfering with its PA12-rise-triggered interval timer.
Set the C bit, which swaps $0000-$0FFF with $1000-$1FFF, and set the CHR windows to 0, 2, 4, 5, 6, 3.
Window 0 ($1000-$17FF): Banks 0 and 1 (sprite-only things)
Window 1 ($1800-$1FFF): Banks 2 (sprite-only things) and 3 (shared things)
Windows 2-4 ($0000-$0BFF): Banks 4-6 (background-only things)
Window 5 ($0C00-$0FFF): Bank 3 (shared things)
For text overlay, use a raster split to switch window 5 to a font or VWF canvas in bank 7.
Because $1C00-$1FFF and $0C00-$0FFF point to the same memory, spinning rings are practical.