It is currently Tue Oct 17, 2017 2:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Aug 31, 2017 8:08 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 111
Location: Rio de Janeiro - Brazil
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:
File comment: 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.
gb_nesrockshack_wip.ips [21.4 KiB]
Downloaded 11 times
File comment: 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.
gbtitlebug.nes [64.02 KiB]
Downloaded 12 times

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


Last edited by nesrocks on Thu Aug 31, 2017 11:45 am, edited 1 time in total.
Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 8:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 8:50 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 111
Location: Rio de Janeiro - Brazil
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.

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


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 9:01 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2961
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 9:28 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 111
Location: Rio de Janeiro - Brazil
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.

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


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 9:51 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 10:01 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 111
Location: Rio de Janeiro - Brazil
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)

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


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 10:07 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2961
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 10:19 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 11:15 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 11:25 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 11:32 am 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 111
Location: Rio de Janeiro - Brazil
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:
 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:
 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:
 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

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


Last edited by nesrocks on Thu Aug 31, 2017 12:13 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 12:06 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 12:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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:
ldx #0
clc
loop:
  .repeat 20, I
    lda $0328+I,x
    sta $2007
  .endrepeat
  txa
  adc #20
  tax
  cpx #120
  bcc loop


Top
 Profile  
 
PostPosted: Thu Aug 31, 2017 12:37 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group