It is currently Sat Dec 16, 2017 1:53 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: NVRAM Corruption
PostPosted: Mon Aug 23, 2010 12:59 am 
Offline
User avatar

Joined: Tue Apr 28, 2009 4:12 am
Posts: 469
I've got this really, really annoying bug in my project (Pulsar, my new tracker) where very occasionally I get a bit of the NVRAM (three or four bytes) filled with rogue values (strangely, all $01).

I tried to set up a breakpoint based on writes to the addresses (they're always in the same area) but so far I've not managed to make it happen in FCEUX - it only seems to do it in Nestopia.

I've spent the weekend going through all the code and I can't see any possible places that I could be writing to the NVRAM with rogue indexes (all writes to that particular area of the RAM are done with (indirect),y

I was wondering though if doing too much DMA or going over a frame with the background code loop (which does happen occasionally) could cause this kind of corruption? If so, do you have any advice or safeguards?

I'm clutching at straws. :(


Last edited by neilbaldwin on Mon Aug 23, 2010 1:24 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 1:20 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
Run Nestopia in an x86 debugger so you can see when the emulator code writes to memory?

I've played around with Ollydbg, it's easy enough to use.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 1:29 am 
Offline
User avatar

Joined: Tue Apr 28, 2009 4:12 am
Posts: 469
Dwedit wrote:
Run Nestopia in an x86 debugger so you can see when the emulator code writes to memory?

I've played around with Ollydbg, it's easy enough to use.


I'll have a look at that Dwedit, thanks.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 4:22 am 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 924
Location: Japan
Could it be, I don't know, a mapper write going to the wrong location?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 5:17 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
You're using 32K WRAM in this, correct? Could you be in the wrong 8K bank? Since the bank is controlled by some CHR bank bits, could you be in 4K CHR mapping mode by mistake, and have it randomly switching as the PPU reads from alternate CHR 4K banks? e.g. if you enable 4K CHR banking, set the WRAM bank bits differently in each CHR bank, enable PPU rendering, then start executing code from $6000, you can get some really crazy crashes. :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 9:59 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
If what blargg described turns out to be the root cause, Neil should rename the memory to HVRAM (Highly Volatile RAM). ;D


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 23, 2010 11:25 am 
Offline
User avatar

Joined: Tue Apr 28, 2009 4:12 am
Posts: 469
Grrrrr. I've just found the bug. I always suspected it was human error (the pattern of corruption was too similar each time).

One absent "cpy, bne" branch caused all that fuss. I must've stared at that code a hundred times over the weekend.

Thanks for your inputs though - I still learned a couple of tricks.

:)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot], Yahoo [Bot] and 6 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