Common problems when running on an actual NES?

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

djcouchycouch
Posts: 97
Joined: Sat May 28, 2011 10:30 am

Common problems when running on an actual NES?

Post by djcouchycouch » Mon Jun 13, 2011 3:56 am

What are the common problems encountered when running homebrew code on actual NES hardware? Is there a faq or document somewhere?

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru » Mon Jun 13, 2011 4:37 am

Common problem is that something simple and well documented that works well in every emulator, just does not work on the hardware (and rarely vice versa too). Problems I had were related to the vertical scroll after a split (still is mystery what was wrong) and to working with OAM without using OAM DMA (it just was a bad idea).

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Mon Jun 13, 2011 6:04 am

In my game, I was still updating the PPU after the end of VBlank, but before any visible scan lines were rendered. None of the emulators caught this (fceux, nintendulator, nestopia, nesicide). Yet on real hardware this caused serious PPU glitches.

In my mind, this is also a bug in the emulators. They were not emulating real hardware accurately. I assume that someone could construct a test for this, like Blargg's test roms. I thought about reducing my problem to a demo rom and releasing it, but a) I needed to use my time on other things and b) Blargg is gone, so idk if he or anyone would updating his test roms. "Clueless's test rom" would most likely be forgotten / ignored, as I lack the serious cred that Blargg has.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jun 13, 2011 6:22 am

clueless wrote:"Clueless's test rom" would most likely be forgotten / ignored, as I lack the serious cred that Blargg has.
That's what the wiki is for. If you make the test ROM, and I can verify that it runs differently on my PowerPak and on one of the big three emulators, I will promote it.

albailey
Posts: 177
Joined: Thu Jul 13, 2006 3:15 pm

Post by albailey » Mon Jun 13, 2011 9:18 am

One problem that hit me and tool me a while to fix was related to doing a Sprite DMA late in vblank.

It was invoked during VBlank, but AFAIK the entire operation did not complete during VBlank.

On real hardware (and Nintendulator) my sprites did not show up.
On FCEU, which was my default emulator, things appeared fine.



Another huge gotcha for me was mistakely using palette entry '0x0D'.
On emulators everything looked good. On my old CRT TV everything looked good.
On my newer LCD TV, the graphics scrolled and jumped around like nuts.

Al

User avatar
Dwedit
Posts: 4354
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Jun 13, 2011 9:32 am

Don't turn off the screen early during HBLANK time, otherwise you get screwed up sprites.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Mon Jun 13, 2011 10:14 am

The mistake I made when I was making some NES homebrew was using sprites without DMA. On emulator it looked fine. I think I used FCEU. This was a long time ago though. Later when more accurate emulators came about I tried the program again and saw it fail and like only 1 sprite even appeared on the screen.

It just shows the important of testing on real hardware. Even though the PowerPAK isn't spot on for something like mapper IRQ behavior of the MMC3, for other boards without IRQ it's a great tool. I know some mentioned you don't get the raw power-up state but that's a minor issue if you just be sure to initialize everything as you should.

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Mon Jun 13, 2011 11:53 am

Just to break the combo, I've not run into anything that worked on a good emulator and failed on hardware. My game doesn't do anything complex with the PPU though, it's only clever CPU code.

Sometimes I run into things that break differently on hardware and an emulator, though. But they've always been shown as clearly broken by an emulator. For instance, now my screen updates are running a little too long. On FCEUX this occasionally caused the scrolling to jump, but on an actual NES it was actually crashy.

User avatar
Dwedit
Posts: 4354
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Jun 13, 2011 11:59 am

I've always turned off the PPU when entering vblank, and turned it back on when leaving. This lets you use the prerender scanline as vblank time, so I see no reason not to do it, as long as you also do full 2005/2006 writes to set scrolling. It also makes the scrolling merely jump if your code is too long, instead of crazy corruption.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Mon Jun 13, 2011 12:09 pm

Dwedit: This is a great idea! I can still optimize my NMI routine to at least not go FAR over in the Vblank time, but if it ever still does by a little this seems like a GREAT catch. :D

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Jun 13, 2011 12:19 pm

I never has upates getting too close to the end of VBlank. If I'd have them overflow into the frame I'd rather see it happen and see a completely bugged screen than leaving it as it and then having occasional jumping on the screen.

But it's just a personal choice.

When it comes to sprite updates without using DMA, I just ask, why ? Even if it worked, there would be absolutely no point in it since it would just be a huge waste of CPU time. Maybe if you never use all 64 sprites it would save a little RAM but really it's not worth it.
Useless, lumbering half-wits don't scare us.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jun 13, 2011 12:22 pm

The only application I see for OAM updates without DMA involves trying to play audio through timed writes to $4011 and move sprites at the same time.

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Mon Jun 13, 2011 1:17 pm

Dwedit: That's a great idea! I stopped doing that when I stopped trying to extend vblank, but I didn't think about that nice side effect.

Now keep in mind that I've only executed one program on an NES (last night) but I did run into an issue. I cleared my OAM RAM to all 0xFF's, but I was not executing a sprite DMA after that. This was fine on an emulator (not sure why...) but on the hardware this resulted in random sprites all over the screen.

This would not be noticeable if your NMI handler does a sprite DMA every frame, but my engine uses an "OAM Updated" flag to trigger this, which in my test ROM was never getting set as it does not use sprites.

User avatar
tokumaru
Posts: 11864
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Jun 13, 2011 2:02 pm

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.

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Jun 13, 2011 2:02 pm

This would not be noticeable if your NMI handler does a sprite DMA every frame, but my engine uses an "OAM Updated" flag to trigger this, which in my test ROM was never getting set as it does not use sprites.
I do exactly that, and I think it's a good idea, because if for some reason your frame didn't finish in time (and a NMI happens), the OAM page is half-updated, and you probably don't want to do any sprite DMA, because sprites would flicker (as if there wasn't enough sprite flicker with the 8-sprites-per-line limitations...)

However it works fine at startup because in my routine that clears OAM with $f0's (I guess I use $f0's although $ff might work just as well) I set the "OAM updated" flag.
Useless, lumbering half-wits don't scare us.

Post Reply