I have a MMC3 game that needs 3 banks of PRG (16k each). However, when I build a iNES rom with 3 banks, it doesn't work. Different emulators give me different problems: Nintendulator jumps to a bad reset vector, the graphics are wrong in Nestopia, and other various things. But when I add an extra blank 16k prg and change the iNES header to 4, all these problems go away. If I remove one of the levels (ie one of the 16k banks) and build a rom with 2 banks, everything works as expected as well. Is there some weird issues with having an odd number of banks? My setup is most of the code is in the last 16k bank which should be mapped to $C000-$FFFF, and the other banks contain all the level specific code which gets mapped to $8000-$BFFF as needed. I also have 32k of CHR. This is for the PDRoms competition so if I can't figure out the problem quickly I'm just going to submit with 16k of wasted space, which I don't like at all.
On a somewhat related note, can anyone test my game on real hardware?
All roms have a prg size of 2^n (32k, 64k, 128k, etc) so many emus use "0xFFFF & (prg_banks - 1)" to refer to the last bank. I know I do, at least.
In your case, it would mean that the third bank is ignored and the second bank is used as if it were the last one.
Yeah, just watch the pinout of an EPROM. You have X pins of adress imput, adding one pin will double the size of the ROM, removing one pin will half it. You'll definitly need to have a 64kb PRG rom. The only way to have odd ROM size would be to combine two different ROM chip with two different sizes, I know that many SNES games does that.
Suggested layout for your PRG:
16 KB bank 0: bankswitched stuff.
16 KB bank 1: bankswitched stuff.
16 KB bank 2: instructions on how to build an atomic bomb.
16 KB bank 3: hardwired stuff.
Just stick a random text file in there as an easter egg; that's what was done for The New Tetris on N64.
[quote="tepples"]16 KB bank 2: instructions on how to build an atomic bomb.[quote]
That would be very, very dangerous. You'd better let it free and reserve it for any future usage, like a third stage or a sound code.
I think that it would be possible to make a boad that uses two PRG rom chips, with one additionnal 74HC04 hex inverter to switch the /OE pins of the two roms, so there would be always one of them that will be enabled and the other one will be disabled. But imagine the price of :
- One big ROM
- One discrete logic chip
Compared to :
- Two small ROMs
- Two discrete logic chips
For sure, the segond solution is much more expensive, that does matter a lot when you're producing 100'000 games cartidges. Also, the first solution has more PRG space, so the segond is definitely stupid.
For the SNES, it was different. 4MB chips doesn't exist on the market, so Nintendo had to make their own chip design for 4MB and 6MB games. But, before they actually relese thoose chips, that aren't just a standard chip with minor modifications (as far I know), the only solution to have a game above 2MB was to cobine two chips.
I knew that when I put it on a real cartridge I'd have to pad it out, but it seemed like a waste to bloat the ROM file. Anyways it turned out that in my final version some of the code in the last 16k bank overflowed, so I needed to move some things into that 3rd bank anyway. Also, I was able to bring my CHR needs down to 24k, and I thought I'd be able to use just 3 8k banks, but it turns out that some emulators want there to a power of 2 number of CHR banks as well.
Hum, I'm not sure that you got it.
Unless you're re-inventing a new mapper like I said above, you can't have ROM size that isn't 2^n, so this is **NOT** possible with MMC3. Just look at all games and demos out there, they all have a 2^n PRG chip and 2^n CHR chip. May some old stupid demoes of the same style as "junkdemo" does, but if any does this is just gabrage.
This is just a glich in the iNES header, they could decide to input "number of times you have to double the size of a 16kb PRG-ROM" instead of "number of 16kb PRG-ROM bank". Also, there is not always 16kb banks, but also 8kb or 32 kb from the various mappers. The smallest ROM possible is still 16kb.
Bregalad wrote:
This is just a glich in the iNES header, they could decide to input "number of times you have to double the size of a 16kb PRG-ROM" instead of "number of 16kb PRG-ROM bank".
That would
not work with various multicarts - for example, "Action 52" uses only 1536KB of PRG (four ROM sockets, each capable of addressing 512KB, but only 3 with actual ROMs in them).
No I do understand. On real hardware you'd have to a power of 2 sized ROM. But there's no reason why my iNES files has to have unused banks in it. I have 24k of CHR, there's no reason an emulator can't load my iNES file with 3 banks, and emulate a blank 4th bank to make the running size a power of 2. In fact, most emulators did work like this. Likewise for PRG, an emulator could replicate the last 16k bank until it was a power of 2 size as well. It would make my iNES file smaller, but I guess it's not really that much memory.
A lot of emulators can take .nes.zip files. If you have a bank of all $FF bytes somewhere in PRG or CHR, it will compress down to nearly nothing and then decompress on load.
Quote:
That would not work with various multicarts - for example, "Action 52" uses only 1536KB of PRG (four ROM sockets, each capable of addressing 512KB, but only 3 with actual ROMs in them).
Ah, so I didn't know about that. Multicards are a bit special scince they need much more space to store data.
Anyway, this don't apply to the MMC3. If it's written in the competition requirements that you should reduce the size as possible, just do as tepples said.