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!
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.
Are you asking *only* about the single $2005 writes? Galaxian depends on those, so I'd be surprised if any emulator got those wrong.
lidnariq wrote:
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!
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).
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?
Code:
.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).
Is your ROM file size exactly 16*16384+16 = 262 160 bytes?
thefox wrote:
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?
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.
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.
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.
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.
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.
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.nesPlease 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!
mrmmaclean wrote:
qbradq: I'm not going to convert it to MMC3 because I would like to do a cart release using RetroUSB's printed boards
INL-ROM supports MMC3.
Quote:
and they don't support it.
I think what was intended was a compile-time switch to build as UNROM or TGROM. It'd look like this (untested):
Code:
.proc switch_to_bank_a
.ifdef ::USE_MMC3
asl a
ldy #6
sty $8000
sta $8001
ora #$01
iny
sty $8000
sta $8001
.else
tay
sta identity,y
.endif
rts
.endproc
Anyway, I have it running, and I see a still top status bar and a smoothly scrolling playfield below that. It works the same way on NES + PowerPak, FCEUX 2.1.5 SDL (old and new PPU), FCEUX 2.2.0 Wine (old and new PPU). What weirdness are you seeing?
Alright, I was running it on FCEUX 2.2.1 and getting the weird glitch. I decided to check for a new version and there's now v2.2.2 and it works correctly!!
Sorry for all the trouble. I'm sure anyone who tried the ROM and is not a fool probably didn't know what I was talking about. Note to self: check for the newest version of emulators to test...
Thanks for testing, tepples! There must be something about the 2.2.1 release that had something weird to it, as I can see you're testing with older versions.
As for not supporting MMC3, I'm talking about their reproPak boards (
http://www.retrousb.com/product_info.ph ... c14e71dc37), which only support mappers 0, 2, 3, and 7. I can't buy MMC3 chips from a retailer so I don't want to use them. Unless I'm missing something.
Edit: the glitch was the whole scrolling section also scrolling vertically, which made no sense at all and I simply could not pinpoint the issue.
Edit: I just checked version 2.2.0 and it works fine. I redownloaded v2.2.1 to have a clean folder and tested, and the glitch is there. The problem is definitely that specific version!
mrmmaclean wrote:
Thanks for testing, tepples! There must be something about the 2.2.1 release that had something weird to it, as I can see you're testing with older versions.
Yeah, I skipped 2.2.1 because it broke support for mapper 28, which
STREEMERZ: Action 53 Function 16 Volume One uses.
Quote:
As for not supporting MMC3, I'm talking about their reproPak boards, which only support mappers 0, 2, 3, and 7.
And 34, as bunnyboy clarified in #nesdev. Use the mirroring instructions for 0, 2, and 3, and the banking instructions for 7. (The Action 53 menu engine was originally designed for #34.)
Quote:
I can't buy MMC3 chips from a retailer so I don't want to use them. Unless I'm missing something.
What you're missing is
MMC3-compatible INL-ROM boards from a different retailer.
tepples wrote:
And 34, as bunnyboy clarified in #nesdev.
Interesting. Though, while it doesn't effect my own project, it's kind of annoying that the website is not updated to account for that. Not all of us are lurking in irc channels.
tepples wrote:
You officially blew my mind! Thanks for the link.
However, a nearly $10 production cost increase per cart is not exactly a small matter, especially considering the negligible cost of discrete parts. Though the ease of use of those boards (pre-built, more compatibility, etc) could be worth it in the end.
Actually, scratch that. With CIC chips already in there and an option to make them flashable, these boards become a definite option! Thanks again!
I only mentioned MMC3 because that's the only dev cart I have available
Also, while we're on the subject, you might want to check out forum member Infinite NES Lives'
product page. He offers a CPLD-based development cart that supports a wide range of mappers (basically every mapper used in a licensed US cart) and a USB-based in-cart flasher to go with it!
Full disclosure: INF doesn't pay me, but I'd have his babies if I could
Edit: Woops, missed the whole second page
As a matter of fact, I must thank you for mentioning the MMC3 and both yours and tepples' links! I ordered his flasher and a couple of upgraded boards already!
I have converted my code over to MMC3, and while it was an interesting learning experience to write and test a generic scanline counter for splits, having a built in counter that doesn't waste my cycles is already a boon. And with battery backed RAM in addition to double the ROM size, everything I require for sweet NESsing is on the INL board! Pretty pumped.
That's great to hear! For a long time there was a thought within the community that there would be no MMC3 development cart until someone made an MMC3 homebrew worth publishing. I'm glad to see that the presence of an easily accessible MMC3-based development board is promoting it as a target
Well, it is catch 22/chicken'n'egg problem with things like that. Linux for example wasn't considered platform for gaming because no one made games for it and no one made games for it because no one was gaming on Linux. Until recently.
It'll take some time until major players except Valve goes to Linux as target, but I'm digressing.
I guess what I'm trying to say is that lack of ability to do something often inhibits any tries to do so. And often it's the other way around than you might think. Like with Linux gaming.
darkhog wrote:
Well, it is catch 22/chicken'n'egg problem with things like that.
One way I've found to break chicken-and-egg in the NES scene is to make a test ROM. It at least helps get support into emulators, as I showed with my test for the Action 53 mapper.
But the problem with making something that uses MMC3 is that a game big enough to need MMC3 is usually big enough to need more art, and
programmers have had trouble finding artists.
The attitude that you don't need MMC3 if you don't have gobs of CHR data, or that you don't need anything more than UxROM unless you absolutely have to have WRAM, and that you don't need WRAM and can do everything in system RAM unless you want to provide battery-backed saves, and that you don't need saves because you can use a password system, is unproductive. If that attitude were the norm we'd still be using stone hand axes to strip raw meat from the carcasses of sickly bison.
The simple fact is we now have a reliable source of pre-assembled MMC3 development carts. Unless you're targeting NROM there's no reason not to target MMC3 (or MMC1 or FME7 for that matter).
/rant
You could argue that the attitude that you should make your game for NES instead of PC is unproductive by exactly the same logic.
And yes, there's a zillion valid reasons not to target MMC3, but I'll just state the most obvious one here:
You intentionally chose to work with this platform because of its limitations. Don't denigrate others for choosing a slightly different set of limitations than you did. This is silly.
qbradq wrote:
The simple fact is we now have a reliable source of pre-assembled MMC3 development carts. Unless you're targeting NROM there's no reason not to target MMC3 (or MMC1 or FME7 for that matter).
That depends on whether INL can produce UNROM boards (74161+7432) or UNROM + WRAM (74161+7432+7420) cheaper than MMC3 boards (one or two CPLDs depending on the functionality subset). True, having MMC3 boards available is a good thing, but big games still need more effort, and beyond a certain point, artists want to be compensated in some manner. That and there's a fixed overhead of making each cart, and small games on discrete mappers make it easier to take advantage of
bundling efficiencies in much the
same way as the sections of a newspaper by building a multicart.
Cost is definitely a huge thing, if not the biggest thing when it comes to the actual product and production. I am a jack-of-all-trades who needs a lot of graphics for this project, so something like the MMC3 is ideal, and I don't have to pay an artist because I'll be doing it myself. But discrete parts are super cheap (like 20 cents per chip) and if all you need is 8 kb of CHR ROM or something then using MMC3 "just because" is just throwing your money away. Not only that, but when I was working with the UNROM format, I learned a lot while trying to tackle the various issues I was having with its limits, which of course is invaluable.
The main reason I am developing a new game for the NES is BECAUSE of the limitations. I find they force me to think in ways that I otherwise would never have given the virtually unlimited freedom of, say, PC development or Flash/Air. The constraints are what drive me to push the limits of the console as well as my own limits of creativity and problem solving.
Either way, at the end of the day, Super Mario Bros is NROM. Enough said.
rainwarrior wrote:
You could argue that the attitude that you should make your game for NES instead of PC is unproductive by exactly the same logic.
And yes, there's a zillion valid reasons not to target MMC3, but I'll just state the most obvious one here:
You intentionally chose to work with this platform because of its limitations. Don't denigrate others for choosing a slightly different set of limitations than you did. This is silly.
Yea but...
I mean...
Great point
Either way I'm super-happy that we have more options than ever before, and that MrMmaClean now has a dev platform he's happy with. I'd also like to mention I've never release a darn thing, and that my entry for the 2014 compo will likely be NROM