MMC3: Glitches when data are in bank 13 or higher

[DRW]

Today, I encountered a strange issue in my game:

I have an MMC3 ROM with 32 x 8 KB PRG ROM and 8 x 8 KB CHR ROM.

My meta tile definitions (simple data arrays that define what tiles to fetch) are all in the same bank.

When the meta tile definitions are in bank 0-12, then everything is fine. But as soon as I put them into bank 13-28, graphical glitches happen.

(The banks from 0-28 are all declared as start = $8000, size = $2000.
Bank 29 is start = $A000, size = $2000 and bank 30-31 are the fixed bank.)

Have a look at the red object in the screenshots. Left is the fine version, right is the glitchy version:

Glitch.png (10.9 KiB) Viewed 4231 times

The strange thing is that everything works fine in one part of the banks, but not in another.


Since the red object on the screen is declared in one C array, we can exclude the fact that it is declared exactly at the border between two banks, so that the first part is still read correctly while the other part is from a non-active bank. That's definitely not the case.
Also, in the moment, all of the meta sprite data is merely 61 bytes and it's located at the start of the bank.

Furthermore, I use a constant for bank numbers, so the idea that I set the wrong bank value in one location can also be excluded. If I did that, I would probably have much more issues and not very rare tile glitches that only manifest exactly in bank 13-28 while they work fine in bank 0-12.


The glitchy tile is background tile number 0. I included a little test code that plays a sound when this specific meta tile is drawn and when a 0 is read. And the game indeed reads a 0 from ROM.
But I don't understand it. I mean, look at this:

Code: Select all

PRG_ROM_BANK_12: type = ro, start = $8000, size = $2000, file = %O, fill = yes;
PRG_ROM_BANK_13: type = ro, start = $8000, size = $2000, file = %O, fill = yes;

Later:

Code: Select all

META_TILES_BMTL: load = PRG_ROM_BANK_13, type = ro;

And then I have the array:

Code: Select all

#pragma rodataseg(push, "META_TILES_BMTL")
static const byte MetaTileCastleDoor_bMTl[] =
{
	MT_INIT(1, 4, 4, Solid),
	0x1A, 0x1A, 0x1A, 0x1A,
	0x1A, 0x1A, 0x1A, 0x1A,
	0x1A, 0x1A, 0x1A, 0x1A,
	0x1A, 0x1A, 0x1A, 0x1A,
};
#pragma rodataseg(pop)

If I change the meta tiles bank and the calls to that bank to 12 or lower, then everything is fine. But with 13 or higher, glitches happen.

The glitches are even a bit arbitrary. Depending on from where you come, that red door has more or less 0-tiles, even though the ROM data should always be the same.

I even included a check to see whether my current pointer that reads the data actually equals the address of the array in ROM. And yes, it does. So, it's not even that my pointer is somehow off by a few bytes. (If the door consist of different tiles, then the ones that are displayed with non-0 are always in the correct location, so it's not that the pointer starts to read at the last tile row and fills everything else with zeroes.)

And I even had an emulator savestate from one screen before this screen. And when I load it and enter the screen, then the glitchiness can vary, even though it's the same savestate.


So, does anybody know what this is? Are there any known issues regarding certain banks within MMC3?

[Banshaku]

I already have more than 30 banks with an MMC3 and there is no such issue. The first thing I would check is if you sized your rom as power of 2 for PRG/CHR data (8/16/32/64/128k etc) in the ines header. I had a similar bug in the past and this was the issue.

If this part is fine, it could be the way you uses bank in the C code but that would take some time to figure out. In the latest part of the bank (13+) I have 100k of music data and no songs are affected.

[lidnariq]

And I even had an emulator savestate from one screen before this screen. And when I load it and enter the screen, then the glitchiness can vary, even though it's the same savestate.

This unambiguously means at least one of these two things:
* You are not initializing something you need to
* The emulator is not restoring the save state correctly

[koitsu]

Time to see what the 6502 code is doing via an emulator with a debugger, preferably one that easily show you what current PRG ROM banks are mapped to what regions of addressing space (i.e. Mesen).

[DRW]

O.k., forget it. It was a stupid oversight, nothing more:

In my game, the first byte of every bank contains its own number, so that a bank switch in NMI can restore to the previous bank afterwards by reading that value first.
(Because music is even played during a lag and since the screen buildup is done while the game stands still anyway, a lag in this situation isn't a problem here and I didn't try to optimize it away yet.)

And when I doubled the banks recently and moved stuff to the later banks, I forgot to set the IDs for the new banks.
So, it looks like the music code in NMI was started right in the middle of fetching some array data in the regular code. And reading the ID from bank 13 before switching to the music bank simply returned whatever was in the first byte of bank 13, so after the music code it jumped back to some random bank and continued copying its array data from there.

AAAH!

I should have seen the little green pixel in every bank of NES Space Checker. This would have tipped me off.

Well, nevermind and thanks anyway.