nesdev.com
http://forums.nesdev.com/

MMC5 test program
http://forums.nesdev.com/viewtopic.php?f=2&t=15788
Page 1 of 2

Author:  AWJ [ Tue Apr 11, 2017 11:38 pm ]
Post subject:  MMC5 test program

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.

Author:  loopy [ Wed Apr 12, 2017 2:16 am ]
Post subject:  Re: MMC5 test program

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

Author:  AWJ [ Wed Apr 12, 2017 2:25 am ]
Post subject:  Re: MMC5 test program

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)

Author:  loopy [ Wed Apr 12, 2017 2:30 am ]
Post subject:  Re: MMC5 test program

Image

Author:  AWJ [ Wed Apr 12, 2017 2:33 am ]
Post subject:  Re: MMC5 test program

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)?

Author:  loopy [ Wed Apr 12, 2017 2:40 am ]
Post subject:  Re: MMC5 test program

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

Author:  AWJ [ Wed Apr 12, 2017 2:51 am ]
Post subject:  Re: MMC5 test program

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.

Author:  Bregalad [ Thu Apr 13, 2017 6:19 am ]
Post subject:  Re: MMC5 test program

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.

Author:  Sour [ Thu Apr 13, 2017 7:24 pm ]
Post subject:  Re: MMC5 test program

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.

Author:  AWJ [ Fri Apr 14, 2017 1:43 am ]
Post subject:  Re: MMC5 test program

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.

Attachments:
File comment: MMC5 test v2
mmc5test_v2.zip [4.85 KiB]
Downloaded 57 times

Author:  Bregalad [ Fri Apr 14, 2017 2:51 am ]
Post subject:  Re: MMC5 test program

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).

Author:  AWJ [ Fri Apr 14, 2017 3:33 am ]
Post subject:  Re: MMC5 test program

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.

Author:  lidnariq [ Fri Apr 14, 2017 11:35 am ]
Post subject:  Re: MMC5 test program

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.

Author:  AWJ [ Fri Apr 14, 2017 11:50 am ]
Post subject:  Re: MMC5 test program

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.

Author:  loopy [ Sun Apr 16, 2017 4:03 pm ]
Post subject:  Re: MMC5 test program

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.

Page 1 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/