Report: no emulator can replicate this bug (edit not really)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
nesrocks
Posts: 460
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Report: no emulator can replicate this bug (edit not really)

Post by nesrocks » Thu Aug 31, 2017 8:08 am

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):
Image

Fceux (top of the head missing):
Image

Everdrive n8 running on a NES AV:
Image

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.
Attachments
gb_nesrockshack_wip.ips
This is the ips for the (U) version of the game. It is an incomplete work in progress of the hack, but the title screen can be tested on different hardware and emulators.
(21.4 KiB) Downloaded 106 times
gbtitlebug.nes
This is stripped data generated from fceux data logger and contains just the title screen. Added for quick visualization. Only meant for testing on fceux.
(64.02 KiB) Downloaded 107 times
Last edited by nesrocks on Thu Aug 31, 2017 11:45 am, edited 1 time in total.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

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

Re: Report: no emulator can replicate this bug

Post by tepples » Thu Aug 31, 2017 8:22 am

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?

User avatar
nesrocks
Posts: 460
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Report: no emulator can replicate this bug

Post by nesrocks » Thu Aug 31, 2017 8:50 am

tepples wrote: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.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Report: no emulator can replicate this bug

Post by thefox » Thu Aug 31, 2017 9:01 am

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

User avatar
nesrocks
Posts: 460
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Report: no emulator can replicate this bug

Post by nesrocks » Thu Aug 31, 2017 9:28 am

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.
Image

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.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Report: no emulator can replicate this bug

Post by Sour » Thu Aug 31, 2017 9:51 am

nesrocks wrote: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.
Just FYI, Mesen also has a random ram init option, and displays similar glitches when it is turned on.

User avatar
nesrocks
Posts: 460
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Report: no emulator can replicate this bug

Post by nesrocks » Thu Aug 31, 2017 10:01 am

Sour wrote:
nesrocks wrote: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.
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)
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Report: no emulator can replicate this bug

Post by thefox » Thu Aug 31, 2017 10:07 am

nesrocks wrote:NDX is hanging for a looooong time (several minutes) when I try to open it.
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

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Report: no emulator can replicate this bug

Post by Sour » Thu Aug 31, 2017 10:19 am

nesrocks wrote: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)
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

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

Re: Report: no emulator can replicate this bug

Post by tokumaru » Thu Aug 31, 2017 11:15 am

nesrocks wrote:So the everdrive is the culprit here then.
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.
nesrocks wrote:I've written a loop to replace a huge piece of code that was repeated 120 times.
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.

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

Re: Report: no emulator can replicate this bug

Post by tepples » Thu Aug 31, 2017 11:25 am

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?

User avatar
nesrocks
Posts: 460
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Report: no emulator can replicate this bug

Post by nesrocks » Thu Aug 31, 2017 11:32 am

tokumaru wrote: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.
Yup, lesson learned. I've just finished writing a RAM clear and it is now displaying the correct title screen on the everdrive.
nesrocks wrote: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.
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:

Code: Select all

 00:841C:AD 28 03  LDA $0328 = #$00
 00:841F:8D 07 20  STA $2007 = #$FF
 00:8422:AD 29 03  LDA $0329 = #$00
 00:8425:8D 07 20  STA $2007 = #$FF
 00:8428:AD 2A 03  LDA $032A = #$00
 00:842B:8D 07 20  STA $2007 = #$FF
 00:842E:AD 2B 03  LDA $032B = #$00
 00:8431:8D 07 20  STA $2007 = #$FF
 00:8434:AD 2C 03  LDA $032C = #$00
 00:8437:8D 07 20  STA $2007 = #$FF
...
 00:843A:AD 2D 03  LDA $039F = #$00
 00:843D:8D 07 20  STA $2007 = #$FF
I converted to...

Code: Select all

 00:841C:A2 00     LDX #$00
loop:
 00:841E:BD 28 03  LDA $0328,X @ $03A0 = #$0F
 00:8421:8D 07 20  STA $2007 = #$00
 00:8424:E8        INX
 00:8425:E0 78     CPX #$78
 00:8427:D0 F5     BNE loop
Or this for readability? Making x start at #$28 and end on #$9F seems more intuitive.

Code: Select all

 00:8337:A2 28     LDX #$28
loop:
 00:8339:BD 00 03  LDA $0300,X @ $03A1 = #$10
 00:833C:8D 07 20  STA $2007 = #$00
 00:833F:E8        INX
 00:8340:E0 A0     CPX #$A0
 00:8342:D0 F5     BNE loop
Last edited by nesrocks on Thu Aug 31, 2017 12:13 pm, edited 1 time in total.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

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

Re: Report: no emulator can replicate this bug (edit not rea

Post by tokumaru » Thu Aug 31, 2017 12:06 pm

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.

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

Re: Report: no emulator can replicate this bug (edit not rea

Post by tepples » Thu Aug 31, 2017 12:10 pm

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:

Code: Select all

ldx #0
clc
loop:
  .repeat 20, I
    lda $0328+I,x
    sta $2007
  .endrepeat
  txa
  adc #20
  tax
  cpx #120
  bcc loop

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

Re: Report: no emulator can replicate this bug (edit not rea

Post by tokumaru » Thu Aug 31, 2017 12:37 pm

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.

Post Reply