nesdev.com

Hello, i have a little slight problem that happens on any emulators "not named" fceux, like nestopia nintendulator, bizhawk, etc.

It's reguarding the MMC5's ex attributes (5C00-5FFF RAM) where your only allowed to update it during rendering. First of all, i have the routine for it set at the very end of the NMI "after" the music engine JSR which ensures 99% of the time that it will only be run outside of vblank time past scanline 0 right ??

But, sometimes there are times where it is possible the music engine will finish before vblank time has ended, and the EX Attributes updating routine starting around scanline 257 to 260. Like in a couple spots in rapid man seen here ...Nestopia on top, fceux on bottom



My question is, how do i check for "vblank is finished" ?? to get to scanline 0. i tried every single type of "LDA $2002, branch back to LDA forever until the loop breaks.

i tried bpl, bmi, bvs, bvc .... and then with BIT 2002 like the nesdev wiki page's talk about, but not a single one of these methods works ...or will just freeze the game forever at certain times.

Do i have to use an IRQ set for scanline 0 ?? i really hope that's not the solution. i don't have any idea.

Well, given the MMC5, just set an IRQ for the first scanline.

I don't think there is any way to know if vblank is over unfortunately. lidnariq solution with IRQ seems the most likely one.

love that hack, looks great! I think I need to ask you someday how MMC5's ex attributes works since I cannot wrap my head around it (yet) by just reading the wiki. I guess I need to test it, that's the only way.

Other options.

If sprite zero hit in the last frame, it is cleared at the end of v-blank.

If 8 Sprite overflow in the last frame, it is cleared at the end of v-blank.

Also, you could cause a sprite zero hit on line 1, and you could cause an 8 Sprite overflow on line 1...or, actually... at the end of line 0, when sprites are evaluated.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Is this really that bad?

If the wiki is to be believed, bit 0x40 of the value read from $5204 indicates whether or not the PPU is currently rendering a scanline - it won't tell you the instant the frame starts, but it ought to work for what you're trying to do.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Well i was a little worried about doing the IRQ scanline 0 thing because, well im not really sure exactly how to because, i set the IRQ line in NMI every frame (whenever a level needs it) -- but i dont have it write the IRQ number on lag frames, cause most of the NMI needs to be skipped -- uhhh, im not sure how to explain it sorry.

Also i was just trying to the 5204 thing ...doing all those things like before with the 2002 ..like LDA 5204, and #40 bne back to it ...or beq, bvs, bvc ...bit 5204
and well, apparently the only thing i've seen is that it will break the loop on scanline 239

Why the heck is it only going forward on 239, i never set the 5203 register to EF or anything like that, even if i try to set the IRQ to 0-10 or just whatever, it still always is 239. I dont know what's up with that.


-------------------------
edit: wait, i think i got it. changed it to BEQ this time again, and well, fceux always still breaks the loop before vblank is finished, at scanline 260 ---

but nintendulator debugger shows it's always starting at scanline 1 ..and none of the emu's are showing those tile glitches anymore!! (about updating EX ram before vblank was finished)