This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

MMC5 test program

MMC5 test program
by on (#193059)
Does anyone here have an EPROM burner and an original MMC5 cartridge they're willing to sacrifice? I just wrote a program to test the doubts I have about the MMC5's CHR banking operation. Here's what it looks like running (hopefully--I'm only able to test it on emulators):

Image

You can toggle the NES-side sprite and BG pattern tables and sprite size ($2000 bits 3-5), the MMC5 EXRAM attribute-per-tile mode (the left screenshot has it off, the right has it on), and the order the MMC5 CHR bank registers are written in. Pressing left/right switches between four orders: in order from $5120-$512B; $5128-$512B followed by $5120-$5127; scrambled with $512B last; and scrambled with $5127 last. The value written to each register is the same as the order, e.g. the order shown in the screenshots writes 0 to $5128, 1 to $5129, 2 to $512A, 3 to $512B, 4 to $5120, etc., and finally 11 to $5127.

The way the test works is each 1KB bank of CHR ROM contains an identical copy of the font, the bank number as an 8x8 tile, the bank number as an 8x16 sprite, and the bank number as a data byte that gets read out via $2007 during VBlank. So for every combination of register settings you can see on a single screen what banks end up being used for sprites, for BG, and for data.

It should go without saying that running this test program on a Powerpak or Everdrive or the like defeats its purpose, which is why the attached ROMs are in the form of separate PRG and CHR images rather than a .nes file. When burning, please mirror the data to fill whatever size of EPROMs you're using. The test program should work on any MMC5 cartridge; it doesn't use on-cartridge RAM.

Here are some of the things I'm interested in:

  • Does the MMC5 actually somehow know which sprite size the NES is using? Does toggling the sprite size ever change the banks used for BG or data?
  • Are there any other surprising instances of "crosstalk"? (e.g. toggling EXRAM having an effect on the banks used for sprites)
  • What effect, if any, does the order the registers are written in really have? Are the "mode A" and "mode B" cryptically referred to in the 1990s-vintage translated document by "goroh" actually a thing?

I'd greatly appreciate it if anyone can run this test program on original hardware.

Edit: Attachment deleted, please download the updated version below.
Re: MMC5 test program
by on (#193064)
AWJ wrote:
Does toggling the sprite size ever change the banks used for BG or data?
Yes.
AWJ wrote:
(e.g. toggling EXRAM having an effect on the banks used for sprites)
No.

Sorry for the crap picture quality. Tell me if you want me to do some specific tests.

on reset:
Image

toggling obj size:
Image

toggling exram:
Image

pushing Right a few times:
Image Image
Image Image

proof not a powerpak :)
Image
Re: MMC5 test program
by on (#193065)
Thanks! Can you do 8x8 sprites with EXRAM on? (that's the configuration Bandit Kings of Ancient China and probably most of the Koei games use)
Re: MMC5 test program
by on (#193066)
Image
Re: MMC5 test program
by on (#193067)
Sorry, can you also do 8x8 sprites with register 5127 written last? (89AB01234567 or the mixed up one that ends in 7) I take it the EXRAM setting never affects anything except the BG banks (making them always CDEF)?
Re: MMC5 test program
by on (#193068)
BANK SET ORDER: 89AB01234567
OBJ: 4567
BG: 89AB
DATA: 456789AB

AWJ wrote:
I take it the EXRAM setting never affects anything except the BG banks (making them always CDEF)?

Correct. The only thing that changes is BG: to CDEF
Re: MMC5 test program
by on (#193069)
And changing the BG and sprite pattern tables doesn't do anything surprising either?

The way it looks like it works to me is:

When sprites are 8x8, $5128-512B are not used at all. Sprites, BG, and data access via $2007 all use the banks selected via $5120-5127.

When sprites are 8x16, sprites use $5120-5127, BG tiles use $5128-512B, and data access via $2007 uses the set that was written to most recently (writing to any of $5120-5127 last makes all data reads come from the sprite banks, writing to any of $5128-512B last makes all data reads come from the BG banks).

Does that look right to you?

Many thanks for your help.
Re: MMC5 test program
by on (#193159)
Quote:
When sprites are 8x8, $5128-512B are not used at all. Sprites, BG, and data access via $2007 all use the banks selected via $5120-5127.

When sprites are 8x16, sprites use $5120-5127, BG tiles use $5128-512B, and data access via $2007 uses the set that was written to most recently (writing to any of $5120-5127 last makes all data reads come from the sprite banks, writing to any of $5128-512B last makes all data reads come from the BG banks).

That means, that the Dish docs as well as the wiki document wrong behaviour (each being based on eachother, it's impossible to tell where the "wrong info" comes from). They say the last set written to is used to display graphics, when in reality it's only used when reading through $2007.

EDIT : Since I imported wiki changes into Dish docs hosted on RHDN, that makes them wrong too. However originally they didn't mention that wrong info I guess.

I think this "new" behaviour makes more sense. Although, I still don't see why the MMC5 would keep track of the last regset being written to - the only point to read $2007 in pattern table range is to store PRG data in the CHR-ROM, and read it during VBlank (possibly forced VBlank). As such, you are typically bankswitching your fake CHR-bank, and switching something with real graphics backs in after VBlank (or forced VBlank). When doing that, they could make it always read from either set, and they don't need to keep track of the last set being written to. The only reason I see to do that is to allow people to use their favourite set when doing this, and make sure they don't mess up.
Re: MMC5 test program
by on (#193227)
AWJ wrote:
When sprites are 8x16, sprites use $5120-5127, BG tiles use $5128-512B, and data access via $2007 uses the set that was written to most recently (writing to any of $5120-5127 last makes all data reads come from the sprite banks, writing to any of $5128-512B last makes all data reads come from the BG banks).
Based on the "large sprites+exram+last bank written is $512B" screenshot, it looks like turning on exram mode makes the $2006 reads always use $5120-5127, no matter which register was last written to? The updated wording on the Wiki doesn't seem to mention this. Am I misinterpreting this?

Thanks for the test rom & the test result's screenshots, by the way - I just finished updating Mesen's behavior to match them.
Re: MMC5 test program
by on (#193243)
Sour wrote:
AWJ wrote:
When sprites are 8x16, sprites use $5120-5127, BG tiles use $5128-512B, and data access via $2007 uses the set that was written to most recently (writing to any of $5120-5127 last makes all data reads come from the sprite banks, writing to any of $5128-512B last makes all data reads come from the BG banks).
Based on the "large sprites+exram+last bank written is $512B" screenshot, it looks like turning on exram mode makes the $2006 reads always use $5120-5127, no matter which register was last written to? The updated wording on the Wiki doesn't seem to mention this. Am I misinterpreting this?

Thanks for the test rom & the test result's screenshots, by the way - I just finished updating Mesen's behavior to match them.


Yeah, you're right. It looks like $5128-512B are only used when 8x16 sprites are selected and extended attributes are not enabled. (ETA: this is wrong, see loopy's subsequent post)

I've been going through the commercial MMC5 games with a debugger to see which features they use, and so far I've found two games that store non-pattern data in CHR ROM (Bandit Kings of Ancient China and Uchuu Keibitai SDF) and both of them access it through the 5120-5127 banks.

ETA: Something I just thought of--how does the "fill mode" nametable interact with extended attributes? Does the fill mode nametable use the per-tile banks from EXRAM or the regular bank registers (and if the latter, which ones?) And are the color attributes taken from EXRAM or from register $5107?

Attached is an updated test program that lets you switch to the fill mode nametable by pressing up. Here's what to test: select the fill mode nametable, and then press Select to toggle extended attributes. Do the hex digits filling the screen change, and do they go rainbow-y or all the same color? Also, this time the zip includes the assembly language source for the test program--however, it's for an old and somewhat personalized version of bass.
Re: MMC5 test program
by on (#193246)
By the way other open questions about the MMC5 :
  • If you enable split screen and ExRAM, what happens in the split screen? Is ExRAM simply used as both tile and attribute data, or is it possible to use ExRAM as "normal" nametable data in the split part ?
  • Is it possible to battery back up the ExRAM (the battery being connected to the MMC5 on my EKROM board I wonder).
Re: MMC5 test program
by on (#193247)
Bregalad wrote:
By the way other open questions about the MMC5 :
  • If you enable split screen and ExRAM, what happens in the split screen? Is ExRAM simply used as both tile and attribute data, or is it possible to use ExRAM as "normal" nametable data in the split part ?
  • Is it possible to battery back up the ExRAM (the battery being connected to the MMC5 on my EKROM board I wonder).


I strongly suspect that Bandit Kings of Ancient China does use split screen and extended attributes at the same time in its ending, and that whatever emulator was used to take the screenshots on GameFAQs doesn't emulate it correctly. That's the only explanation I can think of for this.
Re: MMC5 test program
by on (#193276)
AWJ wrote:
I strongly suspect that Bandit Kings of Ancient China does use split screen and extended attributes at the same time in its ending, and that whatever emulator was used to take the screenshots on GameFAQs doesn't emulate it correctly. That's the only explanation I can think of for this.
I'm about 80% certain that the credits scroll is using all the sprites for the pictures, and using the PPU's normal scroll registers for the letters.
(Here's what I said last time this came up).

It really looks like no MMC5 boards were ever shipped with the SL3-6 jumpers shorted, so no MMC5 games could have used separate Y fine scrolls on a left-and-right split screen.
Re: MMC5 test program
by on (#193278)
lidnariq wrote:
AWJ wrote:
I strongly suspect that Bandit Kings of Ancient China does use split screen and extended attributes at the same time in its ending, and that whatever emulator was used to take the screenshots on GameFAQs doesn't emulate it correctly. That's the only explanation I can think of for this.
I'm about 80% certain that the credits scroll is using all the sprites for the pictures, and using the PPU's normal scroll registers for the letters.
(Here's what I said last time this came up).

It really looks like no MMC5 boards were ever shipped with the SL3-6 jumpers shorted, so no MMC5 games could have used separate Y fine scrolls on a left-and-right split screen.


The mountain could be made of sprites, but the stars are more than 64 pixels wide (compare them with the word "Intellect" on the right side). And the ROM does contain code to set up split mode (search for 8D 01 52 and 8D 02 52, and disassemble around what you find to verify that it's real code)

I wouldn't be surprised if the stars move with the scroll on real hardware.

Has anyone verified that the jumper setting for mapper-controlled CHR A0-A2 actually works? Maybe it was errata'd and that's why no cartridges were shipped that way.
Re: MMC5 test program
by on (#193430)
AWJ wrote:
Has anyone verified that the jumper setting for mapper-controlled CHR A0-A2 actually works? Maybe it was errata'd and that's why no cartridges were shipped that way.

Yes, it works.
Re: MMC5 test program
by on (#193455)
Including attributes? I vaguely recall something about the attributes not correctly shifting on [fine-]vert-split.
Re: MMC5 test program
by on (#194120)
Bregalad wrote:
That means, that the Dish docs as well as the wiki document wrong behaviour (each being based on eachother, it's impossible to tell where the "wrong info" comes from). They say the last set written to is used to display graphics, when in reality it's only used when reading through $2007.

Correct.

AWJ wrote:
Sour wrote:
Based on the "large sprites+exram+last bank written is $512B" screenshot, it looks like turning on exram mode makes the $2006 reads always use $5120-5127, no matter which register was last written to? The updated wording on the Wiki doesn't seem to mention this. Am I misinterpreting this?

Yeah, you're right. It looks like $5128-512B are only used when 8x16 sprites are selected and extended attributes are not enabled.


No, it has nothing to do with EXRAM. When you switch to 8x8, $2006 reads use $5120-27. Switching back to 8x16, it still uses $5120-27 (until 5128-2B is written again) - so being in 8x8 resets what set of registers was written last, apparently. ...Unless there's something else going on in your code I don't know about.

8x16 + EXRAM
Image

Push select (8x16, no EXRAM)
Image

Push start (to 8x8)
Image

Push start again (back to 8x16)
Image

Myask wrote:
loopy wrote:
AWJ wrote:
Has anyone verified that the jumper setting for mapper-controlled CHR A0-A2 actually works? Maybe it was errata'd and that's why no cartridges were shipped that way.

Yes, it works.

Including attributes? I vaguely recall something about the attributes not correctly shifting on [fine-]vert-split.

I don't remember, it's been years since I played with it.
Re: MMC5 test program
by on (#194121)
AWJ wrote:
Attached is an updated test program that lets you switch to the fill mode nametable by pressing up. Here's what to test: select the fill mode nametable, and then press Select to toggle extended attributes. Do the hex digits filling the screen change, and do they go rainbow-y or all the same color?

Yes, toggling extended attributes makes it fill with a rainbow-y "C".
Re: MMC5 test program
by on (#194130)
Thanks once again, loopy.

Now I just have to figure out a ROM patch to jump directly to the ending in Bandit Kings to see what's going on with that mountain/textscroll screen.

Also, I recently noticed that all the Koei games contain identical code to set up split screen mode. In fact they contain a lot of identical code, period. According to some discussion on romhacking.net, it sounds like they're all based on a common engine and the game-specific logic is in some kind of interpreted bytecode.

As an aside, there seems to be some kind of widespread sentiment that MMC5 was "wasted" on Koei strategy games, that those games don't really take advantage of its features, but if you play any of them further than the initial menus or even look at screenshots you can see that's not the case. The "hex" maps on which battles take place in these games (example) use extended attributes so each "hex" can have its own palette (the "hexes" are really 16x16 squares, but they're in staggered columns). Also, the Japanese versions of most of the Koei ExROM games have extensive kanji fonts. The early Koei games on SOROM boards had to use 32x32 "hexes", which sharply limits how much of the battle you can see at once (example) and they can only display a few kanji at a time using CHR RAM. The first Nobunaga's Ambition doesn't use kanji at all, and the first ROT3K only uses them for character and place names, and falls back to hiragana whenever it has to display more than one or two names at once, e.g. when selecting which of your generals to send to battle (Chinese names written in hiragana are not too easy to read or remember...)
Re: MMC5 test program
by on (#194215)
Doesn't Uchuu Keibtai SDF use the split screen mode during the attract mode/demo screens and at the very beginning of stage 1? Surely that would be easier to test than the end of Bandit Kings of Ancient China.
Re: MMC5 test program
by on (#194216)
Yes, but it doesn't have the appearance of having a different fine Y scroll on the left and right sides.

... at least, I'm pretty certain that the objective was figuring out how BKoAC does the credits, rather than just finding an example of left-and-right spit screen?
Re: MMC5 test program
by on (#194297)
Great Hierophant wrote:
Doesn't Uchuu Keibtai SDF use the split screen mode during the attract mode/demo screens and at the very beginning of stage 1? Surely that would be easier to test than the end of Bandit Kings of Ancient China.

Uchuu Keibitai SDF does not use ExRAM "mode 1" and split scrolling simultaneously as far as I know.
Quote:
As an aside, there seems to be some kind of widespread sentiment that MMC5 was "wasted" on Koei strategy games, that those games don't really take advantage of its features, but if you play any of them further than the initial menus or even look at screenshots you can see that's not the case.

I can't speak for everyone else, but I think you misunderstood the reasons being the claims that the MMC5 was mostly "wasted" on Koei strategy games. We don't pretend the MMC5 was not useful to implement those games, in fact it most certainly was very useful for them. What however is sad, is that:
  • Koei strategy games are very much alike to eachother - basically it's just the same game over and over but you're leading a different country in a different time period, but the gameplay is always the same. (Only Gemfire differs significantly I think, and not even by that much)
  • Those games are not specific to the NES - in fact they were released on numerous platforms and their NES versions is just yet-another-port of them, and often an inferior port as opposed to versions released for computer machines. As such they are not really representative to how the MMC5 is used to push the NES to its limit - on the other hand it was just used to port multiplatform games that wouldn't be portable to the NES otherwise. Basically Koei strategy games on the NES are "demakes" before this word was invented.
  • Those games are very difficult to access. Unlike a SMB or a Rad Racer wher you can just insert the game and enjoy playing right away, you need to build your army and learning how the game mechanics works is a long, difficult process. I barely played those games but most of the times I had absolutely zero idea what I had to do, and most often if you don't do the good thing there'll soon be hunger-revolts in your armies and then game over

So while they are not bad games per se, Koei strategy games are difficultly accessible to a very limited public, and their NES version are just demakes of supperior versions for other platforms. While techniqually they might "put the NES to it's limit" in term of computational complexity, they do not do so in fun nor graphical view, and as such, we cannot appreciate it. Fans of the NES console and games in general will find those games weird, bland and uninteresting, and fans of the Koei strategy games themselves will not want to play the inferior NES versions.