Hey all, been a while since I have posted but had a question. Recently, I was watching videos on castlevania III and came across this video:
https://www.youtube.com/watch?v=CJhwNRaOb0gFast forward to around to the 3:32 and look at the bottom of the status bar. It starts to bounce around uncontrollably. After watching a few vides of it in action on the real nes, it seems as if this is something that not supposed to happen. It seems to really rear it's head when going up and jumping up. It causes the bottom to shake harder.
Is this accurate behavior? I fired up nestopia 1.40 and undead to check it out, and indeed, it still does this and really does it on the clock tower level as you work your way up. Can someone confirm is this is supposed to happen? IS CIII one of those harder to emulate games?
I just played it on a real NES.
This video is different from what I saw. There is some slight jitter on the screen split, but not this much.
Thanks for doing that dougeff. I guess something is obviously off somewhere. Maybe the irq perhaps?
Does anyone else have these issues with their emulator?
EDIT**
I looked at the image info in Nestopia, and noticed the mirroring is set to Horizontal, I changed it to Vertical like the mapper list said. No dice, it still bounces like crazy when going up on the first level and the clock tower level. Prob others too.
Here is a 60p capture from actual hardware. I actually find emulators' artifacts to be less objectionable. Emulators seem to just reveal the screen underneath the status bar at different points between frames, while on actual hardware, mysterious white lines appear. I wonder how that happens.
I don't think it's that big an issue in this case. The Bandai Dragon Ball games have
far dirtier screen splits on actual hardware.
MMC5 has mapper-controllable mirroring. Altering the mirroring bits in the iNES header won't affect emulation.
Some emulators may use the mirroring bits in the rom header as a hint for their initial state though. This matters more for DxROM games misassigned as MMC3.
Thanks for all the responses guys. In this case though, is this accurate emulation or an issue that needs to be corrected?
Just ran another test using the famicom version. The Japanese version does not do this on nestopia. Is the Japanese version doing something different?
Japanese version is VRC6, not MMC5.
Ahh yes. Correct. Thank you Dwedit. It is my assumption that possibly something is off in the MMC5 irq scanline counting. Are there any test roms available to validate this assumption?
Last time I looked over the MMC5 IRQ counter documentation, it was "black box that just works, timing unknown".
edit: Seems to trigger on the two end of line tile fetches?
I'm guessing it's the same problem of the MMC3 IRQs, related to $2006. You must verify if writes to $2006 occur before the IRQ; otherwise, an extra clock is triggered... and the shaking you just see.
We know that the MMC5 counts scanlines by checking for three reads from the same address as long as PPU A13 is high (well, really, PPU /A13 is low). So access to $2006 shouldn't trivially screw it up the same way it screws up the MMC3.
We also know it knows when display is active or not.
Looking at the
diagram on the wiki, those three reads should happen during dots 338, 340, and 2 ... Nestopia appears to trigger its counter on dot 0.
I don't think two dots of error should cause this much of a difference, but ???
Thanks guys for helping me look into this matter.
Is there a particular place I can be looking in the Nestopia MMC5 code to look for this? Hopefully a subtle change makes all the difference. I'll be the first to admit some of the more technical aspects are a little over my head, but hopefully the solution for this won't be too difficult.
It def seems like IRQ misfiring, not unlike the mickey's safari in letterland issue nestopia used to have.
NestopiaUE source code:
https://github.com/0ldsk00l/nestopiaFile an Issue at
https://github.com/0ldsk00l/nestopia/issues so that the author can fix it, or people interesting in contributing code/fixes can submit pull requests that tie in to said issue. You should reference this nesdev forum thread in the Issue.
Also,
there are multiple revisions of MMC5, differences unknown. I only mention this because with MMC3
the IRQ counter differs based on revision and HW manufacturer. I also don't know if "MMC5" means "MMC5A" or not, because
some have MMC5 silkscreening, while
others have MMC5A (I didn't find any with MMC5B, but I believe it). Maybe more has been discussed off-board
since then?
Thanks Koitsu. I am very familiar with rdanbrook but figured id post this here since it seems this community is really awesome when it comes to helping others er noobs like me hahah.
I know this isn't a nestopia forum but figured id see what everyone who has more knowledge than I could say as to what the issue might could be. Quite frankly, I am astounded this was never noticed until now. Its been around a VERY long time in nestopia, I tested versions going back to 1.20 or something and the bug is still there.
MMC5 is still to this day one of the less-understood mappers (compared to others). Keep in mind the variance in MMC3 IRQ counter behaviour literally took years to figure out (over the course of almost 2 decades). Just some context. What I'm saying is, it doesn't surprise me that a quirk of this nature would exist for a long period of time.
I'm not interested in Nestopia fixes though.
As I said, check $2006 writes x IRQ clocking/triggering. Stuff at $52xx registers might be interesting too.