nesdev.org

1. wiki http://wiki.nesdev.com/w/index.php/MMC3 said MMC3 PRG Banks layout as following:
(-1) : the last bank, in a proper MMC3, the 63rd
(-2) : the penultimate bank; properly the 62nd
How to understand 62nd or 63rd?
For example, SMB3 has 16 INES 16KB-PRG Banks, wiki said PRG ROM bank size: 8 KB, so 8KB-PRG Banks are 16x2 = 32 that far less than 63.

2. Many games write mapper requesting a out of bonds PRG num and/or CHR num.
For example, Babel No Tou (J) can occur this problem when launch it.Following is my emulator's stdout:
8KB PRG 请求12越界 一共4
请按任意键继续. . .
8KB PRG 请求13越界 一共4
请按任意键继续. . .
2KB CHR 请求29越界 一共16
请按任意键继续. . .
2KB CHR 请求28越界 一共16
请按任意键继续. . .
2KB CHR 请求28越界 一共16
Above translate to
8KB PRG request 12 total 4
Press any key to continue...
8KB PRG request 13 total 4
Press any key to continue...
2KB CHR request 29 total 16
Press any key to continue...
2KB CHR request 28 total 16
Press any key to continue...
2KB CHR request 28 total 16
Press any key to continue...

Of course, I press again, emulator will cause Windows dialog popup and terminal process.

Mask against the bank total in the rom in question.

For instance, if you have 32 prg banks in a particular rom, then you mask all prg bank numbers with 31:

63 & 31 = 31
62 & 31 => 30

That should answer both of your questions.


In general, this matches the real hardware behavior of ignoring high address lines when an undersize chip rom chip is used.

natt wrote:Mask against the bank total in the rom in question.

For instance, if you have 32 prg banks in a particular rom, then you mask all prg bank numbers with 31:

63 & 31 = 31
62 & 31 => 30

That should answer both of your questions.


In general, this matches the real hardware behavior of ignoring high address lines when an undersize chip rom chip is used.

1. Most of games run properly through that manner.
But there are few games still abnormal, Mighty Final Fight (J) status bar's tiles are incorrect, other games' problem like Mighty Final Fight.
2. I find a second problem, Mighty Final Fight (J) is 768KB actually, but according ines header the size only 256KB(8 x 16 KB PRGs, 16 x 8KB CHRs). There are many other games that files size are bigger that ines header described ones. What are extra file content ?

Who knows what random crap someone stuffed in afterwards?

That 768KB dump is a bad dump: http://bootgod.dyndns.org:7777/profile.php?id=3745 says it should be only 256KB.

Anyway, the vast majority of NES games should be a power of 2 of PRG and a power of 2 of CHR.

lidnariq wrote:Who knows what random crap someone stuffed in afterwards?

That 768KB dump is a bad dump: http://bootgod.dyndns.org:7777/profile.php?id=3745 says it should be only 256KB.

Anyway, the vast majority of NES games should be a power of 2 of PRG and a power of 2 of CHR.

There is at least 1 mapper out that has a size that is not to the power of 2. It deals in 4 banks but selecting 0-1 selects the same bank.

lidnariq wrote:Who knows what random crap someone stuffed in afterwards?

That 768KB dump is a bad dump: http://bootgod.dyndns.org:7777/profile.php?id=3745 says it should be only 256KB.

Anyway, the vast majority of NES games should be a power of 2 of PRG and a power of 2 of CHR.

Yes, it's random crap stuffed thing we can ignore.
When I went to that page, I found another thing.
ROM Details
Type Label Size CRC32 x !

PRG0 CAP-SD-0 PRG 128 KB 9B74E080 1
CHR0 CAP-SD-0 CHR 128 KB 8BEE0B63 1

ROMs Combined: 256 KB 2B160BF0 1

When I load a rom file how to calculate the CRC32 value?

It's the same CRC32 as what .zip files use. In linux I use the standalone program crc32 (part of CPAN Archive::Zip), but you can find libraries for whatever programming language you're using.

Boolean wrote:

natt wrote:Mask against the bank total in the rom in question.

For instance, if you have 32 prg banks in a particular rom, then you mask all prg bank numbers with 31:

63 & 31 = 31
62 & 31 => 30

That should answer both of your questions.


In general, this matches the real hardware behavior of ignoring high address lines when an undersize chip rom chip is used.

1. Most of games run properly through that way.
But there are few games still abnormal, Mighty Final Fight (J) status bar's tiles are incorrect, other games' problem like Mighty Final Fight.
2. I find a second problem, Mighty Final Fight (J) is 768KB actually, but according ines header the size only 256KB(8 x 16 KB PRGs, 16 x 8KB CHRs). There are many other games that files size are bigger that ines header described ones. What are extra file content ?

I find another problem about above.
When run loopy's SMB2Jhttp://home.comcast.net/~olimar/NES/smb2j_mmc3.zip, the emulator graphics is totally wrong.
The games is a battery-back ROM.When access CPU memory address $6000 ~ $7FFF, the emulator will save game status to local filesystem, which make emulator FPS very low(1 ~ 2 FPS).
I edit ROM header to make it without battery so that game can be run normal speed, then I find the graphics problem.

About MMC3, my understanding must have problem, please correct me.
1. Write $8000, address $8000-$9FFF(or $C000-$DFFF) is fixed to second-last bank
2. Write $8001, anded $07 with data last write to $8000 as command and switch bank according to command

WedNESday wrote:

lidnariq wrote:Who knows what random crap someone stuffed in afterwards?

That 768KB dump is a bad dump: http://bootgod.dyndns.org:7777/profile.php?id=3745 says it should be only 256KB.

Anyway, the vast majority of NES games should be a power of 2 of PRG and a power of 2 of CHR.

There is at least 1 mapper out that has a size that is not to the power of 2. It deals in 4 banks but selecting 0-1 selects the same bank.

I think you might refer to Action 52 whose cart contain 3 x 512KB chips which are spread over 2MB of memory as follows, chip1 - chip2 - 512KB of 0xff - chip3

other not-power-of-two games are some pirate conversions from FDS, which has 32K (or other power of 2) of PRG + 2K of PRG mapped in the $6000-$7fff range

Boolean wrote:The games is a battery-back ROM.When access CPU memory address $6000 ~ $7FFF, the emulator will save game status to local filesystem, which make emulator FPS very low(1 ~ 2 FPS).

If you're saving SRAM to disk on every write, you're doing it wrong - you should only be doing that when you unload the ROM image (i.e. when you close the emulator, or when you load a different game), and possibly also whenever you pause emulation.

That and save periodically in a background thread in case the operating system or the power company kills your emulator process.

tepples wrote:That and save periodically in a background thread in case the operating system or the power company kills your emulator process.

That can do it. In fact, the emulator is a Win32 Console Application and only has one thread. It hard to controlling multiple threads. For now, you know, the biggest problem is APU emulated and I am doing it.

Quietust wrote:

Boolean wrote:The games is a battery-back ROM.When access CPU memory address $6000 ~ $7FFF, the emulator will save game status to local filesystem, which make emulator FPS very low(1 ~ 2 FPS).

If you're saving SRAM to disk on every write, you're doing it wrong - you should only be doing that when you unload the ROM image (i.e. when you close the emulator, or when you load a different game), and possibly also whenever you pause emulation.

I know what you mean.
Wiki describes $6000-$7FFF = Battery Backed Save or Work RAM.
What I think as following:
1. If ROM has a battery, then ROM must have a Static RAM(SRAM). The SRAM power is proviced by the battery and maintains its data.
2. If ROM has not a battery, then ROM either contains or doesn't contain a SRAM. If ROM accesses $6000-$7FFF, then it must contain a SRAM, otherwise ROM either contains or doesn't contain a SRAM(We can consider it don't contain). If ROM exists a SRAM, then NES board provides power to the SRAM. Once NES power-off, the SRAM data is missing.

Boolean wrote:If ROM accesses $6000-$7FFF, then it must contain a SRAM

There is at least one game that relies on $6000-$7FFF not containing RAM.

lidnariq wrote:

Boolean wrote:If ROM accesses $6000-$7FFF, then it must contain a SRAM

There is at least one game that relies on $6000-$7FFF not containing RAM.

For emulator CPU address $6000-7FFF, I decide to create one RAM no matter if it will be used. If ROMs contain a battery, save RAM to file when game exit or load saved file (if any) to RAM when game launch.