nesdev.com

I'm not sure if this is known, but it doesn't hurt to post it.

I have been working on a hack of ghostbusters for the NES. I have a title screen and there seems to be some problem with how I build it (I'm using the game's original routines for drawing it). When testing the hack on an everdrive the bottom of the screen looks garbled. But no emulator shows this. Every emulator shows a perfect title screen. Fceux is the only one that doesn't show a perfect screen, but it doesn't come close to showing the same result as NES hardware.

Nestopia, punes (screen as it should be):


Fceux (top of the head missing):


Everdrive n8 running on a NES AV:


Attached to this post is a rom of just the new title screen with the bug present (no game at all). It runs in fceux (it was generated using strip data). Funny, if this is run on punes it shows the same bug as in fceux. So fceux in some way altered the game's code? Also attached is the full ips for the (U) rom.
I'm going to see what's going on and fix the problem, but I figured it would be a good idea to report this here.

_________________
http://nesrocks.com/blog/superpitfall30th/

All tiles after "2017" in video memory are probably intended to be blank. It looks like two things are happening:

1. EverDrive is not clearing RAM. Emulators do, in various ways. The hardware doesn't. Trust EverDrive in this respect.
2. Your stripe compression tool is failing to include the last run of the body of the nametable, the one from "2017" to the end of the title screen.

Does the NES emulator in higan have a mode to scramble RAM?

Alright, thanks! That makes a lot of sense. So the everdrive is the culprit here then. Though it probably doesn't explain why sometimes the top of the ghost's head is missing, but I'm going to follow these instructions (which Workss didn't) and see if it solves the problem: https://wiki.nesdev.com/w/index.php/Init_code

About higan, I looked and couldn't find an option for scrambling ram. If it exists it's in the form of command line args.

_________________
http://nesrocks.com/blog/superpitfall30th/

NDX has an option for randomizing RAM on Hard Reset (Debug -> Debug Extensions -> Randomize Memory).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

The top of the head not being drawn is due to a fceux cheat that was turned on for another section of the game that got transfered to the nam. I have no idea how that got transfered from a cheat to stripped rom data.

NDX is hanging for a looooong time (several minutes) when I try to open it. After that it runs fine. It seems to scramble ram by default, nice.


I'm optimizing the game's code to free some rom space. I've written a loop to replace a huge piece of code that was repeated 120 times. Not sure if they did that because it would run faster... Then I'll be able to write proper clear routines.

_________________
http://nesrocks.com/blog/superpitfall30th/

Just FYI, Mesen also has a random ram init option, and displays similar glitches when it is turned on.

Mesen is another emulator that hangs for a long time here when I open it. Windows 8.1 64 bit here. Edit: replaced it with the newest version and now it runs fine. Thanks! (side note: that real time assembler looks like a time saver, awesome)

_________________
http://nesrocks.com/blog/superpitfall30th/

Might be because it's spamming "uninitialized RAM access" warnings to the Debug Information window (although that only takes a few seconds on my machine). You can turn those off in Debug -> Debug Extensions -> Memory Warnings (or close the Debug Information window from Debug -> Status Window).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Good to know that fixed it! The next release will also contain a number of changes done specifically to improve the emulator's & debugger's boot-up times as well.
I think you're the first person I've heard say they tried the assembler out, so if you ever have issues with it, let me know. :p

I wouldn't put it like this... "culprit" implies it's doing something wrong, which it isn't. No programs should rely on RAM being 0 or any other value, they must always initialize all RAM they use.


Be careful when doing stuff like this. I'm sure that the guys who programmed a full NES game know how to code a simple loop, but since they went for the unrolled version, there probably is a reason for it. Slower code might not be a problem in the middle of the game logic, but if this is for VRAM updates, slower code could mean going past the end of vblank, causing visual glitches.

In general, this technique of repeating to avoid spending cycles in branches is called loop unrolling. For example, my Popslide VRAM updater includes versions that are not unrolled, unrolled by a factor of 16, and unrolled by a factor of 64, as a size/speed tradeoff.

But just because it's unrolled doesn't mean it's efficient. I imagine that many NROM- and CNROM-era programmers lacked 6502 experience and instead literally translated idioms from their favorite assembly language to 6502, resulting in inefficient code. And there are a bunch of useless PPU writes in Super Mario Bros. and other games because programmers hadn't yet figured out how scrolling really works.

Could you paste a short snippet of the code that has been unrolled by a factor of 120?

Yup, lesson learned. I've just finished writing a RAM clear and it is now displaying the correct title screen on the everdrive.


True, I've been learning about this just recently. My loop costs 1799 cycles while the verbose version costs only 960. But in the case of this game it seems safe to redo anything that looks weird (and then test it, of course), because the game isn't really well made, to say the least. I believe they may have done this particular section like this "just to be safe".

@tepples:


I converted to...


Or this for readability? Making x start at #$28 and end on #$9F seems more intuitive.

_________________
http://nesrocks.com/blog/superpitfall30th/

As expected, the code is a VRAM transfer. You should carefully debug this to make sure your slower code isn't ever running during rendering.

If the slower routine causes problems, here's a semi-unrolled compromise version that takes 131 bytes and 3+6*(20*8+2+2+2+2+3) = 1029 cycles if I counted it right:

I don't know guys, vblank code is serious business... Even if it does appear to work at first, how can you guarantee that in a later point in the game it won't try to do more work during vblank?

This is not the kind of thing you change and do a quick test to see if anything looks broken... You have to debug this kind of change thoroughly, analyzing the entire vblank handler to know for sure the maximum amount of work the game will try to fit there.