Common problems when running on an actual NES?

[3gengames]

One thing everyone has to understand is that FCEU(XYZαβγ) is extremely forgiving with badly written code. It's far from accurate, and is probably much closer to Nesticle than to a real NES. Don't ever rely on it as your only emulator.

I do. It's not forgiving with PPU stuff at startup, just found some glitches in the beginning or my games program. It's the best emulator for development though with all the tools, sadly. If another emulator came up with a hex editor and name table viewer and maybe a debugger, and didn't start with error messages or multiple boxes of crap I don't want, I'll gladly switch.

[tokumaru]

I use FCEUX all the time too, because of its great debug capabilities, but it will not catch a large number of PPU problems your code might have. So even if FCEU(X) is your main development emulator, you should still give your programs a spin in Nintendulator and Nestopia at least, because those are much less forgiving.

[Shiru]

Would be really cool if someone made a dev emulator that not forgives any known problems. Even if it slow, with just few mappers popular for homebrew, and without nice UI.

[3gengames]

I do, but neither meet the criteria of not erroring or having random boxes on startup.

[tokumaru]

neither meet the criteria of not erroring or having random boxes on startup.

Then there's probably something wrong with your setup, because that doesn't happen to me.

[tepples]

I took "random boxes on startup" to refer to the Nintendulator window whose title is Debug Information.

[koitsu]

What are the common problems encountered when running homebrew code on actual NES hardware?

In my case, my intro code used for the Neo Demiforce FF2e (FF2j in English) translation didn't properly reset the necessary PPU addressing bits when I did certain VRAM writes. The result was corrupted graphics while fading text (palette adjustments). You can see videos of the incorrect and correct behaviours. Folks like Bregalad and others provided details (and had actually patched the ROM to fix the problem).

The reason I didn't notice the problem was because 1) at the time there was no PowerPak and no easy way to make a dev cart, and 2) all the emulators available at the time didn't show the bug. What the nesdev community knew of the PPU back then (circa 1997) differs from what's known today.

You can read about the technical stuff if you want, or the convo I had with Bregalad discussing the details and the history. Be sure to read the full thread from that point forward, as the details get worked out from that point onward.

[thefox]

Would be really cool if someone made a dev emulator that not forgives any known problems. Even if it slow, with just few mappers popular for homebrew, and without nice UI.

I agree, I started to add diagnostic features like this into my modified version of Nintendulator couple of weeks ago. Messages about 1) using uninitialized memory 2) writing to/reading from 2007 during rendering 3) writing to certain PPU regs when PPU hasn't warmed up etc. I'll gladly take any suggestions if somebody can think of more helpful diagnostics like that.

[Celius]

I've noticed some odd behavior on the console that emulators didn't catch. This thread contains a bug that I actually noticed on the console:

http://nesdev.com/bbs/viewtopic.php?t=4 ... sc&start=0

In my game when the screen gets turned off between switching rooms or levels, I would disable rendering mid-frame, and sometimes it would get disabled when the player or an enemy was on that scanline. This would cause sprite glitches the next time sprites are re-enabled, which would often screw up sprite #0, which means my game would get caught in an infinite loop waiting for sprite #0 to change the scroll at the bottom of the status bar.

[tokumaru]

Yeah, that's a very nasty thing that no emulator appears to emulate. disabling sprites mid-frame is pure evil. I still don't know when it's safe to do this. Enabling rendering late however appears to have no side effects, and I've been doing this in my game with no problems.

[Dwedit]

One thing everyone has to understand is that FCEU(XYZαβγ) is extremely forgiving with badly written code. It's far from accurate, and is probably much closer to Nesticle than to a real NES.

Comparing something to Nesticle is not the kind of claim you throw around lightly. Nesticle doesn't even understand that there are 262 scanlines, and that there are 341 PPU cycles per scanline. Open the NES Timing window and see how horrible the numbers look there. Nesticle can't even scroll correctly.

(I know, 6-day late reply...)

[tokumaru]

Heh, I didn't mean to offend FCEU. It's just that I've personally seen it ignore some pretty serious mistakes. Anyway, I didn't say it was as bad as Nesticle, just that it's probably closer to it than to a real NES, which doesn't necessarily mean it's close in absolute terms.