MMC5 exact timings

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

rainwarrior wrote: Sun Dec 11, 2022 1:28 pm So the speculation is that some CPU address signals, propagated through the MMC5, might be weakly overriding the open bus in the $6000-7FFF range?
Well I'm not sure exactly. I ran the TAS again, and while I consistently get the rectangular pattern (indicating it is only the upper bit of data bus that is being overwritten) I get different sprites than when I ran it previously.

The speedruns of this game all use the wrong warp setup, so I looked at the top 5 runs on speedruns.com, and they all have inconsistent results. The first place run looks like pure open bus for some parts and various random bits at other parts. Other runs look simply chaotic.

At least on my NES I always seem to get only the upper bit effected, but I also have the TAS replay device plugged in instead of a standard controller, not sure if might effect anything or not.

It might not even be MMC5 related at all, maybe some analog effect that varies between consoles?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Is it only reading $6000-7FFF or other places too? Out of bound reads to $2000-3FFF can affect the PPU in lots of different ways, and there's especially a lot of OAM corruption edge cases I don't think we know enough to emulate.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

rainwarrior wrote: Sun Dec 11, 2022 3:15 pm Is it only reading $6000-7FFF or other places too? Out of bound reads to $2000-3FFF can affect the PPU in lots of different ways, and there's especially a lot of OAM corruption edge cases I don't think we know enough to emulate.
The game loads sprite data from the address pointed to by address $0A in RAM. In the glitchy area, the address here seems to change between $6918 and $A20A and $0AB6, I'm not seeing anything in the $2000-$3FFF region.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Well, here's a quick test of the "not-quite-open-bus" theory:

Edit: ROM deleted, it had a bug. See below for the fixed one.

Run this ROM on a flash cart. Pull out the cart. Put in an MMC5 ELROM cart. Press START. It will show you memory at $6000. Left/right to select another memory page. Up/down to select a character set.

The character set options are to work with all 4 ELROM games: Castlevania III, Gunsight, Metal Slader Glory, Uchuu Keibitai SDF.

As with all hotswap tests, if you're at all worried about damaging something by doing it... please don't do the test. I've done it a lot with my famicom carts, and I've never discovered a problem, but I don't want to be responsible for anyone else's risk.

I don't have CV3 but I do have Uchuu Keibitai SDF, and here's a few pages of the result:
Edit: pictures removed to avoid the confusion caused by the bug. See below instead.

So... it's definitely more complicated that normal open-bus. (I haven't taken any time to work out a pattern.)
Last edited by rainwarrior on Sun Dec 11, 2022 11:49 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

More troubling... the pages seem to change a little bit when I go back and forth. Here's another variation of $6000...
Edit: picture deleted to avoid confusion due to a bug in test.

So, I think it's going to be more complicated than just being based on the read address, unfortunately.
Last edited by rainwarrior on Sun Dec 11, 2022 11:56 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

A few other notes, looking at $4000-7FFF:

Edit: this was a bug in my program, see below.

Almost every page ends with 3 bytes FF FF FF. Except:
  • $7FFD has: F4 8C 39
  • $5FFD has: 60 E0 60 (or 60 F0 60, or 60 60 60...)
  • $5BFD has: 00 00 00


$5C00-$5FFC is all 00.


Everything else seems to be open-bus-ish but with some extra bits set in mostly consistent patterns, but can be slightly different from read to read.

Edit: one more picture showing some patterns at $4000, since it maybe reveals some tendencies that are hidden by higher addresses.
Edit: removed, don't want the bug to spread confusion.
Last edited by rainwarrior on Sun Dec 11, 2022 11:47 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Had a bug in the test above, the results were being shifted back a few bytes (sorry). Fixed it in this revision. So, the results are slightly less weird now, but still inconsistent.
elrom_mem.zip
(21.49 KiB) Downloaded 19 times
Also realized that when the carts had 8k or 32k WRAM we could still get to open-bus by selecting the second chip, so I've added EKROM and EWROM support to this test. So, any of the following should work:
  • Castlevania III
  • Gunsight, Laser Invasion
  • Metal Slader Glory
  • Uchuu Keibitai SDF
  • Aoki Ookami to Shiroki Mejika - Genchou Hishi
  • Gemfire, Royal Blood, Romance of the Three Kingdoms II, Sangokushi II
  • Just Breed
  • Nobunaga no Yabou - Bushou Fuuun Roku
  • Shin 4 Nin Uchi Mahjong - Yajuman Tengoku
Compromises with the character sets:
  • Aoki Ookmi / Nobunaga no Yabou use U-Z in place of A-F
  • Just Breed uses the bottom half of 2-tile tall numbers/letters. (It had no 1-tile tall set of characters.)
  • Shin 4 Nin uses: 0 1 2 3 4 5 P US SH S + AR T 6 7 8 9. (Seemed the best I could do with what's there.)
Again, because it's a hotswap test, please don't do it unless you think it's worth the risk to your hardware. (For me it is, and I've done it a hundred times, but I'm still OK with the possibility something will break.)

.

So... The only other MMC5 card I have to test on-hand is Just Breed.

The results are still variable, but seem far less random. The deviations from open bus are almost always only in the last 4 or 5 rows, on the last of group of 8... e.g. 65C7, 65CF, 65D7, 65DF, etc. shows E5 and almost entirely the rest of the page shows 65.

It's almost always the bottom 3-4 xxx7 and the bottom 4-5 xxxF that get the extra bit set, though the height varies up and down 1-2 rows frequently. Sometimes xxFB also flips. Sometimes one or two expected column entries don't have the extra bit.

$5C00-5FFF is all 00.

.

Retesting Uchuu Keibitai SDF it's not as consistent as Just Breed, but with the bug in my program fixed it's at least a little less weird than before. There's no strangeness at the end of a page anymore (the special value at $7FFD etc. was just accdidentally reading the ROM area at $8000).
$5C00-5FFF is all 00.

There are patterns in columns (especially at 2^n or 2^n-1), and more bits tend to be set the further to the right and down in a page. It still varies from read to read, though. A few photos of SDF's test below.

.

So... to summarize how it seems:
  • Open bus, but with some extra bits set high.
  • Most often flips bits in the high nibble, but sometimes affects the low one.
  • Strongly patterned tendencies correlated with the address within the page.
  • Further right and down seems more likely to have flips.
  • Not entirely deterministic, as far as I can tell.
  • Different tendencies on different MMC5 carts?
Attachments
sdf6000.jpg
sdf4100.jpg
sdf7F00.jpg
Last edited by rainwarrior on Mon Dec 12, 2022 2:05 am, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Just to satisfy a question of whether the order of reads matters: no, it doesn't seem to.

I made the A/B/SELECT/START buttons choose the read increment pattern:
  • A +1
  • B -1
  • SELECT +15
  • START +127
elrom_mem.zip
(21.82 KiB) Downloaded 18 times
It was an experiment with a null result, i.e. the observed patterns are correlated to address, not to the order of reading.

A nice side effect is you can press A repeatedly to re-read and watch the inconsistent bytes change each time.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

Cool thanks for the test ROM. I don't have a flash cart to test with, but your results are consistent with what I see in the TAS.

Out of curiosity, has a similar test ever been done with plain NROM? Maybe it's not MMC5 related at all.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

I think you could just swap an NROM cart instead of an MMC5 one and it would still do the test. All the MMC5 code should just be ignored register writes. I'll give it a try later when I'm at the machine again. (Just have to add another entry for the target cart's CHR to make the numbers readable.)

I'm fairly certain this is MMC5 specific though... we do have past ROMs like JRoatch's Coredump, or tepples' allpads investigation where it should likely have been observed already if it were applicable to all carts... but it won't hurt to try this one too.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

So, I don't have any NROM cartridges. Maybe I can build one later, but for now the simplest cart I seem to have is a 4-glob Super Mario Bros + Duck Hunt cart.

It seems to have a mild version of the same behaviour! It's always the last 4 rows, and it's always just the high bit, but the pattern is similar. Columns of the modified values might be 1 higher or 1 lower than in this picture from read to read, but it's always pretty much this.

So... yeah, maybe this is a more general feature of the open bus behaviour? (All these tests have been done with my Famicom, BTW. My two NES machines are harder to hotswap, but if I build an NROM test maybe I can try them with that later.)
Attachments
mhrom_mem.zip
(4.64 KiB) Downloaded 14 times
smbdh_4400.jpg
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Alright, managed to resurrect my EPROM programmer and did an NROM-ish test.
nrom_mem.zip
(4.63 KiB) Downloaded 17 times
I guess this can hotswap too, but requires the target NROM to have relevant ASCII characters in the $0000 CHR page. (Though as long as the tiles are unique it can be worked out what they are.)

I put this on a ReproPak board in BxROM configuration with the CHR duplicated to 32k and PRG to 256k, and a 74HC161 for banking.

The results with this are consistently just the high byte of the address, with no variation. Completely deterministic. The same on both my NES and Famicom.

So... I guess the known "open-bus" behaviour is probably correct and reliable for NROM, but subject to some variability depending on the cart/mapper?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

Very interesting results, thanks again for testing. Any speculation on what might be the cause, or why it's mostly the upper bit effected?

Thinking back, maybe this is the cause of why some TASes seem to mysteriously need an extra controller latch to sync on console. Paperboy is one example, and it needs to see $41 in the return byte, but maybe some effect is causing the upper bit to be set and the read is being ignored? It would make sense, though I don't have any idea what the underlying physical cause would be. Extra latch seems to be needed when the ppu is first being turned on for rendering, so maybe it's drawing some extra voltage or something that effects open bus somehow, I don't know.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Alyosha_TAS wrote: Wed Dec 14, 2022 5:46 amVery interesting results, thanks again for testing. Any speculation on what might be the cause, or why it's mostly the upper bit effected?
It seems to be only D7 with my MHROM cart (SMB+DH). With my ELROM cart (UK-SDF) it seems like all of the upper nibble flips frequently, especially D5, but even the lower nibble was affected less frequently. With my EKROM cart (JB) I think it was mostly D7 but still with some variation. I guess the $4000 page gives the best chance of information, since it has the fewest address bits set, but I can't even test D6.

I don't have very good theories about this. Like, with MHROM, D7 shouldn't even be connected to anything but the PRG-ROM, at least in theory.

Since the theory for open bus behaviour in general is that the data lines have a residual capacitance, I'd have to guess that it's weak enough that crosstalk from physically adjacent things can affect it?

While each cart seems to have its own tendency, I don't think we can expect consistency even from the same mapper. When I was just looking at MMC5, there was an extremely faint hope that it might still be deterministic based on some hidden internal state of the MMC5, but I don't think there's any way that MHROM could store enough internal digital information to be this complicated.

With MHROM it might even be more to do with the mask ROM, rather than the "mapper" latch? I don't think the latch should be connected to relevant stuff here. For its pattern A7 and A6 = 1 seems required for a flip (i.e. only on the last 4 rows), and then within that range it seems like the probability of a flip is almost directly how many bits of A0-A5 are set. Maybe I'd guess each bit makes a contribution, A7 and A6 most of all, and with enough 1s together it becomes enough to override the open bus capacitance? It could be that other address lines make a contribution too, but it'd be hard to determine from the range we have access to.
Alyosha_TAS wrote: Wed Dec 14, 2022 5:46 amThinking back, maybe this is the cause of why some TASes seem to mysteriously need an extra controller latch to sync on console. Paperboy is one example, and it needs to see $41 in the return byte, but maybe some effect is causing the upper bit to be set and the read is being ignored? It would make sense, though I don't have any idea what the underlying physical cause would be. Extra latch seems to be needed when the ppu is first being turned on for rendering, so maybe it's drawing some extra voltage or something that effects open bus somehow, I don't know.
What does "an extra controller latch" mean? Like you add an extra frame of input to the TAS data, or...?

Though, I guess if the goal is TAS on hardware, if the hardware is unknowably non-deterministic, maybe the games could be patched for determinism. For Castlevania III, I dunno what kind of patch would keep the needed behaviour for the exploit. Something I've done with an in-progress PowerPak OS revision is pre-load WRAM with open-bus-ish values where there's no save. This is imperfect (e.g. doesn't handle page-crossing) but does fix a few games that relied on it with bugs, though I'm not sure if it would be enough to duplicate this CV3 bug? With Paperboy you could patch the input poll, or Loopy's PowerPak CNROM mapper put in an open bus simulation state specifically for $4016/4017, which should also make it deterministic.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

rainwarrior wrote: Wed Dec 14, 2022 5:09 pm What does "an extra controller latch" mean? Like you add an extra frame of input to the TAS data, or...?
The bot reacts to polls from writes to $4016 just like a real controller, but I have to add in an extra such poll for Paperboy in the data the bot uses for it to work on console compared to what I get from the emulator. It's as if the game is polling the controller one extra time after power up, for unknown reasons. There are no DMC DMAs happening during this time either. This isn't the only game where this happens, in Bad Dudes for example, I have to add an extra poll after every level for it to work on console, not just at power up. Low G Man also encounters this issue. I haven't looked at the latter two games to see if they read controller data similarly to Paper Boy, maybe I should check that to see if there is a connection.

For Castlevania III, I already checked that my 'bit 7 of data follows bit 2 of address' implementation is good enough for the TAS to sync on console. This worked for 3 out of 3 trials, even though the exact sprites aren't the same each time. So this is good enough for me. It does mean things will be somewhat fine tuned to my personal cart/console, but oh well.
Post Reply