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

MMC5 exact timings

Post by Alyosha_TAS »

I'm trying to do console verification of Castlevania III which uses the MMc5 chip, but have been unsuccessful. I've tried the simple things of moving the scanline IRQ +/- a few ppu ticks but that didn't seem to help.

Are there any kind of quirks I need to be aware of?

Is anyone interested in making a test ROM that exactly times scanline IRQ compared to say vblank?

Or if anyone can think of any kind of strange interactions that might be happening I'm open to suggestions, I'm all out of ideas.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 exact timings

Post by Ben Boldt »

The scanline detection of MMC5 is quite complicated and not particularly well understood. The wiki attempts to explain it 2 ways, one with text and one with a diagram. I made the diagram and the first part of the text and I believe that newrisingsun made the pseudo code text. I don’t think everything necessarily fully agrees with each other in that section. It has been a while since I worked on that so I don’t want to say too much at this point. A lot of effort went into that section back then so I would tend to trust it more than what I may think or say now.

Ultimately, we like to decap the MMC5 eventually and maybe figure more out about it. Rest assured, there are a lot of secrets to be found in that chip. It seems to be a newer style chip that may be more difficult to decap than others. I don’t know any technical reasons to back that up though.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

Ben Boldt wrote: Wed Oct 26, 2022 8:03 pm Ultimately, we like to decap the MMC5 eventually and maybe figure more out about it. Rest assured, there are a lot of secrets to be found in that chip. It seems to be a newer style chip that may be more difficult to decap than others. I don’t know any technical reasons to back that up though.
Is decapping something that is actively being pursued? Anything I can do to help advance the process (money, chips)?
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 exact timings

Post by Ben Boldt »

Org, quietust and others have decapped and analyzed some stuff lately. They do this on the nesdev discord, in the research section.

viewtopic.php?t=16576
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

I did some more testing here, and it seems the correct timing is that the cpu sees an IRQ on ppu cycle 8. With some additional DMC details on the NES side this gives correct console playback for Castlevania III.

EDIT: Well the playback is correct until a wrong warp that has a lot of crazy stuff happening in it. Could be lots of things going wrong there, so probably still need to improve MMC5 emulation to narrow down the options.
User avatar
dink
Posts: 157
Joined: Sun Jan 12, 2020 8:42 pm

Re: MMC5 exact timings

Post by dink »

Speaking of MMC5, I'm curious about a flashing line in CV III which happens in nearly every emulator (Nintendulator, Nestopia, my emu..) I can think of except Mesen.
It's the first line after the HUD on the second floor of the stairway section after going up a little bit. I did some logging, Mesen increments the mmc5 scanline counter at the first ppu cycle, but just incrementing at the first ppu cycle isn't enough - because that will break Laser Invasion (causing a bouncy HUD). I think something else is at play here, but right now it's a mystery.
Curiously, are you getting that blinking line at all?
Attachments
cv3_line.png
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: MMC5 exact timings

Post by NewRisingSun »

The blinking line occurs on real hardware as well.

https://youtu.be/2BqgDXO_KoY?t=204
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

Yes I see a glitched line on emulator (BizHawk) in certain circumstances in that area (not exactly where your arrow is though, a little further up.)

I also tried on my nes (original cart and original NES) and also see a glitched line in the same way.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Strange Sprites

Post by Alyosha_TAS »

I'm still getting desyncs on console so I compared the wrong warp area to console to see if I could spot any differences.

The first thing I noticed is that sometimes the game loads sprite data from what would be the WRAM region (there is none in Castlevania III.) It loads data from there into RAM at $0200 then DMAs it from there. I assume this just returns open bus, which is the same value everytime because the game uses indirect Y increment to read out the data.

But this does not give a result that matches console. Why could this be?

In the attached images, the one with only 1 sprite is from emulator. The one with 4 in a rectangular pattern is from console.

Note that this isn't something that happens only on a single frame or something, it occurs consistently throughout the wrong warp area whenever sprite data is read from WRAM. It always produces a rectangular pattern, but the size / shape of the rectangle is not always the same. What could the MMC5 be returning besides open bus?
sprites_emu.png
sprites_console.png
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: MMC5 exact timings

Post by Fiskbit »

Do you know anything about the source of the video the image is from? Is it definitely a real MMC5 cart on an official system? Could it instead be a flash cart?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

Fiskbit wrote: Sat Dec 10, 2022 3:29 pm Do you know anything about the source of the video the image is from? Is it definitely a real MMC5 cart on an official system? Could it instead be a flash cart?
The image is from video I captured myself from my own cart and my own NES. NES is unmodified, same one I use for all my other testing. Cart is original and I opened it up just now to verify it's not a pirate copy or something and it does contain an original MMC5 PCB.

It looks like the upper 2 bits of the returned byte are being set / cleared based on some unknown pattern. this seems to give the correct bounds for the rectangle anyway.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

Is there an easy way to set up that exact moment in an emulator? Is there a password or something that goes there?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

rainwarrior wrote: Sat Dec 10, 2022 5:20 pm Is there an easy way to set up that exact moment in an emulator? Is there a password or something that goes there?
Well you can download BizHawk 2.8 from here: https://tasvideos.org/BizHawk/ReleaseHistory

and then play the movie file from here: https://tasvideos.org/4895M?handler=Download

and it will play through until it reaches that point at about frame 37600.

Outside of BizHawk I don't know, it's a pretty convoluted set up.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC5 exact timings

Post by Alyosha_TAS »

It seems like if the upper bit of the returned byte follows bit 3 of the address, then I get a pattern pretty close, though not exactly matching, what I see on console.

I'm not sure why the address and data bits would relate to each other, this is just an example of what makes a similar pattern. Another way that gets an almost correct pattern is setting the upper bit of the return byte in the pattern of the bits in 0x96.

At any rate the extra sprites are enough to cause a desync in the TAS same manner as on console, so it seems like figuring this out will hopefully allow the TAS to finally work.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: MMC5 exact timings

Post by rainwarrior »

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?

Edit: Video of TAS @ 10:26 - this seems to be where the exact moment of that screenshot takes place.
Post Reply