It is currently Fri Oct 20, 2017 11:15 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: MMC5 test program
PostPosted: Tue Apr 11, 2017 11:38 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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.


Last edited by AWJ on Fri Apr 14, 2017 3:27 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:16 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:25 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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)


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:30 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
Image


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:33 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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)?


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:40 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Wed Apr 12, 2017 2:51 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Thu Apr 13, 2017 6:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Thu Apr 13, 2017 7:24 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Fri Apr 14, 2017 1:43 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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 56 times


Last edited by AWJ on Fri Apr 28, 2017 2:02 am, edited 2 times in total.
Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Fri Apr 14, 2017 2:51 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
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).


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Fri Apr 14, 2017 3:33 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Fri Apr 14, 2017 11:35 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6287
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Fri Apr 14, 2017 11:50 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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.


Top
 Profile  
 
 Post subject: Re: MMC5 test program
PostPosted: Sun Apr 16, 2017 4:03 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], keldon and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group