Hi everyone
Super new to nes programming, I am one of the beta backers for NES Maker but I don't think mapper 30 will work for the type of game I'd like to make so I'm looking to program it on my own using mapper 3 hopefully. The question I have about the iNES header is, for the PRG count and CHR count are there only certain combinations that are accepted or could I potentially chose any combination that I wanted. The example I found online is the following.
.db "NES", $1a ;identification of the iNES header
.db $08 ;8 16KB PRG-ROM pages
.db $01 ;1 8KB CHR-ROM page
.db $30 ;mapper 3 and horizontal mirroring only
.dsb 9, $00 ;clear the remaining bytes
If I've notated correctly would that mean that I could do something like this below?
.db "NES", $1a ;identification of the iNES header
.db $40 ;64 16KB PRG-ROM pages
.db $40 ;64 8KB CHR-ROM pages
.db $30 ;mapper 3 and horizontal mirroring only
.dsb 9, $00 ;clear the remaining bytes
I forget where exactly I read this but I thought I had so that each KB of CHR-ROM holds 64 tiles (8x8) so if I used the above example that would mean I'd have 32,768 tiles to work with for graphics?
Any help is greatly appreciated.
Thank you everyone!
Mapper 3 limitations are documented here -- see upper right corner and overview:
https://wiki.nesdev.com/w/index.php/INES_Mapper_003Both of your proposed header definitions are unreasonable for PRG. Your 16KByte PRG count should be either 1 (16KBytes total) or 2 (32KBytes total). You cannot have any more than that with mapper 3.
Still speaking of mapper 3: for 8KByte CHR count, a value of
$40 (64) would get you 64*8 = 512KBytes CHR total.
Mapper 3 lets you swap in/out a full 8KByte bank/page (an entire
pattern table).
The pattern table on the NES consists of 512 8x8 tiles (256 tiles on the "left" (PPU RAM $0000-0FFF) and 256 tiles on the "right" (PPU RAM $1000-1FFF). Thus, 512*64 = 32768 total 8x8 tiles. In short: you did your math correctly.
Summary: mapper 3 will work fine for you if all you need is lots of CHR-ROM. If you need PRG swapping, you're going to need to use a different mapper, and one that simultaneously offers lots of CHR-ROM capacity.
Thank you for the response I appreciate it.
I am primarily looking for CHR space for animations so I'm thinking this is the best option. It looks like there is quite a bit of documentation on this so I'll have to read through that and grind.
If I need more PRG it's looking like Mapper 5 would be the option available but much less documentation on that mapper from what I've gone through.
Some emulators are more restrictive than others regarding the ROM sizes for each mapper. You can only be 100% safe if you respect the official limits of each mapper (check their respective wiki page), but some emulators will accept larger sizes if the mapper registers allow it. Mapper 3 is CNROM, which has a maximum of 32KB of PRG-ROM, the same as NROM (i.e. no mapper), so it doesn't even have any registers for switching PRG-ROM, meaning that there's absolutely no way to access more than 32KB with it. Maybe GNROM (mapper 66) will be enough for you?
Another important thing to note is that ROM chips are only manufactured in sizes that are powers of 2, so you should only use powers of 2 for the number of banks (1, 2, 4, 8, 16, 32, and so on).
Mapper 5 is the most complex mapper there is, it's expensive and hasn't been properly reproduced in hardware for homebrews yet. And it's totally overkill if all you need is more CHR space.
What kind of animations are you talking about?
You can do a lot of animation using something simple like GTROM. Bankswitchable CHRRAM is really flexible.
I'm working on a wrestling game. I just can't see how I would be able to do what I want to do move wise working with Mapper 30 loading at the screen. I think Mapper 3 is the way to go for now, but I'll probably be back on here when the errors start coming.
I'm going to flowchart the programming actions for now then translate them to ASM. I think once I do that I'll be in a better place. I needed to know what I wanted to do was even possible within NES first before attempting it.
I might not be thinking correctly here but I want to create a state for all of the different attacks/hits and bank switch the animations in at the change of state.
But does GTROM go up to 1 MiB? I ask because 32,768 tiles means 512 KiB, leaving nothing for maps and program, which means the majority of the ROM space would be compressed tiles that have to be streaming-decompressed at runtime. I've done streaming decompression before (Haunted: Halloween '85 backgrounds) and cel streaming without decompression (Haunted: Halloween '85 backgrounds), but doing so continuously would take a lot of CPU time and video memory bandwidth away from other tasks, such as animating background tiles.
Bank-switchable CHR RAM is flexible if switched in small units. But I don't see how that's the case if it's switched in whole-address-space chunks, as it appears to be with CNROM, GNROM, "UNROM 512" (mapper 30), and GTROM.
How large are your characters in pixels, and at how many cels per second are they animated? For example, if they are animated "on fives" (one cel for each five 60 Hz frames, which corresponds to "on twos" in traditional film animation), answer 12 fps. This should help us figure out whether cel streaming, with or without decompression, is right for you.
Mapper 3 is not a good option for sprite animation, because you can only change the whole 8KB of CHR-ROM at a time, you can't change just one character's graphics.
The 32K tiles was just me checking my math.
Right now I'm thinking about 9000 tiles would be needed for all the animation I'm planning. I don't know if it's going to be that high yet, I'm still doing the animation so I can run all the checks for duplicate tiles yet.
The backgrounds I don't think I will need much because I'm really only planning on a title screen, game screen, entrance screen, victory screen and defeat screen. The last two will be pretty minimal. If I have room I might attempt a vs. screen as well.
I hope I don't have to do decompression, I'm shooting for something along the lines of Nekketsu Kakoutu Densetsu for look and feel just with grappling.
What I'm saying is that the maximum number of tiles a ROM chip can hold is not the only limitation... You can't simply select any of the 9000 tiles at any time, there are rules for when you can access which tiles, and the mapper can affect that too.
In a wrestling game, you must be able to mix and match characters, as well as different animation frames for each character, and CNROM simply won't let you do that. CNROM can only change the entire 512 tiles at once, so if the sprites you want to display don't share the same 8KB CHR bank, you simply can't show them together.
You either need a mapper that can switch CHR-ROM in finer chunks (e.g. MMC3, which can do 1K/64 tiles or 2KB/128 tiles at a time), or CHR-RAM. With CHR-RAM you have complete freedom of what goes in each of the 512 tiles, but putting the graphics there is not instantaneous, it has to be done byte by byte manually. Without any special tricks, you can update around 200 bytes per frame, which equates to about 12 tiles. At 60Hz, that's 720 tiles per second.