[Solved]Split scrolling fine on Nintendulator but wack on...

[mrmmaclean]

I have been reading up (extensively!) on multiple split scrolling, studying the "Skinny" document and any number of forum posts on the topic while I do my own tests. I had been using FCEUX mostly for my testing and debugging, and Nintendulator when I need more precise debugging results, like scanline counting and whatnot.

I was trying out various versions of the simple $2005 mid-frame writes for horizontal split scrolling, and various versions of $2006, $2005, $2005, $2006 for "glitch-free" split scrolls. When I test in FCEUX, the screen goes crazy! I was tweaking things, thinking maybe I wrote it wrong and was missing some key detail, but when I decided to give it a go in Nintendulator, it worked perfectly fine and exactly as I expected... derp.

So now I have a few questions:
1. Is this just simply how it goes? Should I be using Nintendulator exclusively for horizontal split scrolling and similar tests in emulation?

2. Will this work correctly when I start testing on hardware? (I'm thinking yes, because of what people have been saying around here, though I'm unsure)

3. What does this mean for when I eventually release a ROM? Will people who have a preferred emulator other than Nintendulator simply not be able to play my game?

Thanks!

[3gengames]

Test in Nestopia. If it works in Nestopia too, I wouldn't worry about fceux. I've had crap scrolling in FCEUX that works on a console.

[lidnariq]

Are you asking *only* about the single $2005 writes? Galaxian depends on those, so I'd be surprised if any emulator got those wrong.

[mrmmaclean]

Are you asking *only* about the single $2005 writes?

No, it's the alternating writes I'm asking about. $2005 writes work as expected but I would rather have clean scrolling that the slightly glitchy scrolling you get with those. I'll settle for them if that's the only way it'll be consistent across the board, but that makes me sad...

As for running in Nestopia... It's telling me that it's a corrupt file? Which is not true, obviously. I'm guessing Nestopia has some weird quirks?

Edit: The problem with Nestopia might be my header, but that is for another discussion!

[mrmmaclean]

Actually, I just tested it on all the emulators for Windows found on Emuparadise:

JNES - Works fine!
My Nes - Works fine!
VirtuaNES - Works fine!

NesTopia - Corrupt file warning, doesn't open at all
FCEUX - undesired results

And, of course, not found on that site but what I have been using for deeper testing:
Nintendulator - Works fine!

So now my questions become more broad. Aren't Nestopia and FCEUX supposed to be two of the "best", or at least most popular emulators out there? If that is the case, are all these other emulators simply accepting my "sloppy" (it's not actually sloppy) rom and running with it, where NesTopia and FCEUX are picking up something I don't know about? And if that's the case, why is Nintendulator giving me the exact results I want, even down to breakpoint pixel testing precision?

Edit: If it helps shed any light, the program is a 256K UOROM, written for ASM6 compiler using tokumaru's template (viewtopic.php?t=6160), 16 banks, and with the bank-switching code from the programming UxROM page on the wiki (http://wiki.nesdev.com/w/index.php/Programming_UNROM).

[lidnariq]

I've never seen Nestopia give the "corrupted" result unless I've conspicuously screwed something up. As far as I can tell, it should only give you that if your header is somehow broken. What do you have there?

[mrmmaclean]

Code: Select all

	.db "NES", $1a		;identification of the iNES header followed by null
	.db $10				;number of 16KB PRG-ROM pages (4, 8, or 16)
	.db $00				;number of 8KB CHR-ROM pages (0 for CHR RAM)
	.db $20|MIRRORING	;mapper 2 and mirroring (%0001)
	.dsb 9, $00			;clear the remaining bytes	

Just as described in tokumaru's template, with 16 banks instead of 8 (UOROM rather than UNROM).

[thefox]

Is your ROM file size exactly 16*16384+16 = 262 160 bytes?

[mrmmaclean]

Is your ROM file size exactly 16*16384+16 = 262 160 bytes?

Awww, heck yeah! It was 262 158! I had commented out the IRQ word at the end of the program since UOROM doesn't use them, but I hadn't filled the two bytes, leaving the compiled ROM two bytes short!

It now works in NesTopia exactly as expected. Good work, thefox, and thanks everyone!

The only bummer to all of this is that FCEUX was actually my personal fav emulator until now... Mainly for the hex editor feature which allowed me to see all of the RAM at once in real time. I can't even count how many times I've popped that thing open to see if my frame counter was incrementing! Is there a similar feature in Nintendulator?

[qbradq]

It's quite possible that FCEUX is emulating an edge-case behavior of the PPU that other emulators do not. If you can convert it to work on MMC3, or if it's simple enough that I could convert it myself and you'd share the code, I can test it on (clone) hardware for you.

[tepples]

I have a PowerPak and am also willing to test. The PowerPak emulates mappers, but something as simple as UNROM, with no IRQs or CHR funny business, is probably emulated perfectly.

[rainwarrior]

Are you willing to post a ROM?

Nintendulator has a reputation for getting these things correct, so I would tend to suspect FCEUX is in error (though obviously we should verify).

If there is a bug in FCEUX I'd recommend reporting it here: http://sourceforge.net/p/fceultra/bugs/

Have you tried switching FCEUX from Old PPU mode to New PPU mode? (Config menu > PPU.)

I've seen FCEUX do lots of splits correctly, but maybe you've exposed a new problem for it. There is probably an alternative way to do what you're doing that is robust enough to work with FCEUX regardless.

[tokumaru]

Historically, FCEUX isn't among the most accurate emulators out there. Last time I checked, low level details like sprite evaluation and sprite pattern fetching weren't emulated correctly, and were most likely abstracted. This may or may not have changed in the "New PPU" mode, which is apparently becoming more accurate with time. Personally, I find FCEUX great for debugging, but I don't trust it for edge cases involving timed register writes and hardware quirks.

I do try, however, to support all the emulators I use, which includes FCEUX. When developing special effects that rely on non-trivial use of the hardware, I first make everything work on accurate emulators (e.g. Nintendulator), with periodical checks on an actual NES. When I'm done and I see that FCEUX has trouble with my code, I try to find why by tweaking the code a bit to see if I can get it to work in that emulator as well. As long as said tweaks don't compromise the stability of the effect in the more accurate emulators and on the real system, I keep them. There will be times when FCEUX will simply be wrong, and there's nothing you can do then besides report the bug.

FCEUX *should* support $2005/$2006 scroll splits without much trouble, so even though it works in Nintendulator you should investigate why it doesn't in FCEUX. You might have to tweak the timing a bit, but as long as supporting FCEUX doesn't break the game in other emulators and on real hardware, I think you should give it a try. It might even make your code more robust in the end.

[Dwedit]

FCEUX is crazy aggressive about simulating bus conflicts. Make sure you aren't encountering any of those when you bankswitch. Or in other words, make sure the byte in ROM you are writing to has the exact same value as what you're writing.

[mrmmaclean]

qbradq: I'm not going to convert it to MMC3 because I would like to do a cart release using RetroUSB's printed boards and they don't support it. While I'm sure the knowledge would be interesting, I would rather not get into programming habits this early on for hardware I won't be using, especially proprietary parts I can't purchase myself. Perhaps in the future when I have a full grasp of NROM and UxROM programming first!

tepples and rainwarrior: https://dl.dropboxusercontent.com/u/108 ... dness1.nes
Please excuse that it looks like total garbage! These tests are unrelated to my actual game graphics or code, and I like to test things and fully understand them in an isolated state before incorporating them into my project and moving on. I simply made a colorful mess in NES Screen Tool so I could see the scrolling happening.

tokumaru: Yes, ideally I would want support for all emulators, that way people can choose their favorite and not have to worry about downloading anything but my ROM. I tried some timing tweaking but it simply breaks the effect, which is unacceptable. I too spent many hours running Nintendulator step by step and learning all of the op-code times and banging my head against that "Skinny" doc to let something like this keep me down though! lol

Dwedit: I haven't yet used bank-switching other than to ensure that it worked and to understand the mechanism, otherwise everything is in the main bank at $c000 and the default bank 0 (which I also ensure is the bank being initialized in the warm up code, just in case of emulator weirdness).

Sorry for the late reply, but last post was 4 in the morning and I slept in!