What's going on with the MMC5 counter?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Well I'm glad I was able to help point you in the right direction at least.

Congrats on getting it running, I might have to pick your brain when I get around to my implementation of MMC5. :)
User avatar
TmEE
Posts: 1033
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Post by TmEE »

That is very very awesome :D
Drag
Posts: 1645
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Post by Drag »

Bregalad wrote:Oh okay. I didn't think this thread was all that serious but apparently it ended this way.
I know this is an old post, but why did you think this thread wasn't meant to be serious? Or did I just misinterpret what you wrote?
Bregalad wrote:Back on the subject about how MMC5 detects the VBlank/Frame, I don't know but I have some feeling that it's something dead simple nobody ever thought.
Like a particular fetch the PPU does at the beginning which simply enables the "frame" mode - which would be easy to replicate by reading $2007 during VBlank and trick the MMC5 into thinking the frame has begun.
I believe the prerender scanline makes the same triple-fetch that other scanlines do, so I'd hypothesize that the MMC5 looks for the first triple-fetch to see when the PPU starts rendering.

The only other way to triple-fetch an address (aside from how the PPU naturally does it) is to do it intentionally, by writing the same address to 2006 three times (reading from 2007 each time), so it seems plausible to me. It'd even be easy to implement the in-frame flag this way; whenever the scanline counter is clocked, set the in-frame flag.

That's how it could detect the start of a frame, but how it detects the end of a frame is beyond me. Krzysiobal's earlier post mentioned that he watches for a read from CPU$FFFA, which would happen when the vblank NMI happens. Right now, I'd be most willing to wager on that being how the MMC5 does it. :P

This is all just speculation though. I don't have the same amount of free time I did when I first made this thread, otherwise I'd be more gung-ho about testing things. :\
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Drag wrote:
I know this is an old post, but why did you think this thread wasn't meant to be serious? Or did I just misinterpret what you wrote?
He was talking about this thread I believe:
loopy wrote:http://home.comcast.net/~olimar/NES/mmc5.zip

I didn't link to it on my webpage because it's not complete. It was mentioned over in this thread.
User avatar
Bregalad
Posts: 8115
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Yes, the thread I didn't think it was serious was the "OMG I invented the MMC7" one, not this thread.

I guess I'd had to say "I didn't think that thread ..." instead of "this thread" to be more precise - in french (my language) we only have a single word for "this" and "that" so it's hard for me to know which one to pick when I'm writing in english.

When it comes to deteting the end of the frame, wouldn't it be as simple as counting 240 scanlines ? Of course it you enable rendering late (Battletoads style) it will not work, but who ever said the MMC5 counter worked properly in this setting ?

Detecting reads from $fffa can be clever, but it will only work if NMI is enabled. We all agree it's almost always the case, but you could decide for some reason not to always use NMIs, and then this would make the MMC5 counter fail as well ?

I think there is at least a NROM game, Portopia, which relies entirely on $2002 pooling and never uses NMI. This game hardly uses any animations so randomly missing VBlanks has no visible effects on the game.

Anyways this should be extremely simple to test by reading $fffa manually. If the MMC5 however looks for a $fffa read followed by a $fffb read on the next cycle we can't do that with code so we'd have to test this by disabling NMIs and see if the counter still works or if it's stuck in its "in frame" state.
Useless, lumbering half-wits don't scare us.
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Post by loopy »

The in-frame flag ($5204.6) also goes low goes low if you disable screen rendering. I suppose you could also watch $2001 writes in addition to $FFFA+FFFB reads, but this seems unnecessarily complicated.

On Powerpak, it's detected when the CHR RD pin goes inactive (low for X cpu clocks).
Drag
Posts: 1645
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Post by Drag »

loopy wrote:The in-frame flag ($5204.6) also goes low goes low if you disable screen rendering. I suppose you could also watch $2001 writes in addition to $FFFA+FFFB reads, but this seems unnecessarily complicated.

On Powerpak, it's detected when the CHR RD pin goes inactive (low for X cpu clocks).
If it watches for CHR RD to settle down, then the in-frame flag should go low before the NMI fires, because there's supposedly an idle scanline before the PPU actually sends the NMI.

Also, continually alternating between reading 2007 and 5204 would hypothetically cause the in-frame to stay high (since reading 2007 would generate activity on CHR RD), even when it's supposed to be low.

Again, speculation, but easily testable. :P
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Bregalad wrote:I guess I'd had to say "I didn't think that thread ..." instead of "this thread" to be more precise - in french (my language) we only have a single word for "this" and "that" so it's hard for me to know which one to pick when I'm writing in english.
English used to have three: this, that, and yon. Spanish still does (este/esta, ese/esa, aquel/aquella), as does Japanese (kore, sore, are). I think this merger might have something to do with the process that turned the Vulgar Latin words that became Spanish ser and estar into French être.
Anyways this should be extremely simple to test by reading $fffa manually. If the MMC5 however looks for a $fffa read followed by a $fffb read on the next cycle we can't do that with code
Not even JMP ($FFFA)?
User avatar
tokumaru
Posts: 12559
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

tepples wrote:English used to have three: this, that, and yon. Spanish still does (este/esta, ese/esa, aquel/aquella), as does Japanese (kore, sore, are).
Just wanted to add portuguese to the list: it also has 3 in theory (este/esta, esse/essa, aquele/aquela) but "este" is hardly used in spoken form, where "esse" is used in both cases.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

tepples wrote:
Bregalad wrote:Does the 2 dummy fetches at the end of each scanline always read the same adress as the actual fetch that was before it ?
I think that's the key. The fetches at x=337 and x=339 of one line have the same address as the fetches at x=1 of the next line.

Now we just need to figure out how to do the same thing with fewer I/Os. I'd bet just watching for several consecutive reads with bit 13 set ($2000-$3FFF) would do it. The most consecutive fetches you get from $2000-$3FFF during a scanline is two, and the end of a scanline has four: x=337, x=339, x=1, x=3.
Did some probing around with my logic analyzer to try and prove the validity of your idea Tepples. It might be even easier that that, I'll have to test this at some point but it appears that a simple flipflop could sense scanlines if the timing was properly established.

Watching the CHR A13 line you see the four consecutive reads like you discussed. Below the blue trace is CHR A12 where you can see the sprite fetches for the scanline. Yellow is CHR /RD, Red is CHR A13, and Green is CHR /WR (not much to see). This is coming from the intro of "To the Earth" for anyone curious.

[EDIT: attaching photo at bottom since Dropbox changed link urls and nesdev image attaching has improved...]

But looking at the traces above one other thing sticks out. CHR A13 and CHR /RD always rise WITH eachother, but there's ONE exception. Between scanlines CHR A13 falls low for a small period of time, and when it rises again for the 3rd read CHR /RD has 'hung' for that same period of time. So it almost looks like you could just have a counter that was allowed to be clocked when CHR /RD was high and then clocked with CHR A13. This looks like a great solution with the above discrete traces. In actuality CHR A13 lags CHR /RD slightly as expected, which wouldn't allow the idea above to work if the logic was reasonably fast. One way to get around that would be to add some extra delay to CHR /RD with a few gates or something. I wouldn't expect this to be to stable, just thought it was interesting how CHR A13 toggling could be taken advantage of.

Your idea to merely check for 4 consecutive writes seems pretty sound. You could even reduce the counting logic from 3 to 2 bits and just check for 3 consecutive reads I'd think. The IRQ's would be delayed compared to MMC3 but you'd loose the mess of goofing things up with $2006/7 only using TWO inputs. BEAUTIFUL :D
Attachments
blue trace is CHR A12 where you can see the sprite fetches for the scanline.  Yellow is CHR /RD, Red is CHR A13, and Green is CHR /WR (not much to see).
blue trace is CHR A12 where you can see the sprite fetches for the scanline. Yellow is CHR /RD, Red is CHR A13, and Green is CHR /WR (not much to see).
Post Reply