Congrats on getting it running, I might have to pick your brain when I get around to my implementation of MMC5.

Moderator: Moderators
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:Oh okay. I didn't think this thread was all that serious but apparently it ended this way.
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.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.
He was talking about this thread I believe: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?
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.
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.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).
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.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.
Not even JMP ($FFFA)?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
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.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).
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.tepples wrote: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.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 ?
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.