It is currently Mon Nov 20, 2017 2:01 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Coredump tool
PostPosted: Mon Aug 11, 2014 8:37 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Attachment:
File comment: Screen shot of $0400-$047f after booting this from a powerpak.
coredump-v1.0-screenshot.jpg
coredump-v1.0-screenshot.jpg [ 37.04 KiB | Viewed 3402 times ]

Coredump is a tool that prints the contents of the NES internal ram given a key combo on reset. This is an improved version of the stack overflow screen I did awhile back. When installed at the reset vector this can be use for two things: for debugging games that crash while on a unmodified console, and for scientifically getting data on the initial contents of NES ram. Perhaps even convincing emulator authors to ditch the arbitrary 0x00000000ffffffff pattern.

I hope that even though this compiles to a hefty 485 bytes, that it can be part of NES power-on self-test (POST)


Attachments:
coredump-v1.0.nes [16.02 KiB]
Downloaded 242 times
coredump-v1.0.asm [11.37 KiB]
Downloaded 146 times
Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Tue Aug 12, 2014 1:10 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
43110 wrote:
Perhaps even convincing emulator authors to ditch the arbitrary 0x00000000ffffffff pattern.

I think that would be only FCEUX, though. :)

The test program is nice and simple, I like it!

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Wed Aug 13, 2014 2:07 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Myask wrote:
I wonder how much NES state the PowerPak clobbers between boot and game.

Perhaps you should write a DEADBEEF or other RAM filler, to run before this, and see if RAM is part of it.

Obviously the PowerPak hits PPU registers, CPU status bits, and one register to LD* ST* in order to hit the PPU registers. It must also discard whatever data were in the controllers' shift registers, as it must to read from any of them.
---
[semi-offtopic hunk split off to start another topic]


Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Wed Aug 13, 2014 12:15 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
The split post is relevant.

So I was working on this a bit (misfeature fixes, view nametables before overwriting, and sounds), and you got me thinking. Is it possible to stash the cpu registers by writing to OAM_DATA on reset, and retrieving them two blank frames later by cycling around OAM also with OAM_DATA? I don't plan on preserving OAM since it'll most likely have a mirror in RAM.

Edit: To answer my own question. No. OAM_DATA does not work like I expected. The best I can hope for is a brk with an IRQ vector that pushes A X and Y.


Last edited by JRoatch on Thu Aug 14, 2014 8:37 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Thu Aug 14, 2014 3:53 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Version 1.1 attached.
- $01 and stack pointer are now preserved in idle frames.
- added sounds.

The next version will be very different as I'll have to start using the nameables to store operating state to include the features I'm planning.


Attachments:
coredump-v1.1.asm [12.17 KiB]
Downloaded 104 times
coredump-v1.1.nes [16.02 KiB]
Downloaded 152 times
Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Fri Aug 22, 2014 3:42 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Attachment:
File comment: Screen shot of part of the nametable after booting this from a powerpak.
coredump-v1.2-screenshot.jpg
coredump-v1.2-screenshot.jpg [ 39.85 KiB | Viewed 3167 times ]
Version 1.2 attached.
- This version is separated into a two parts: a boot backend and a GUI frontend. Boot stuffs things into CHR RAM, and GUI reads and prints them to the screen.
- New things now captured at boot are nametables and palette.

CHR RAM was decided to be used as scratch memory since everywhere else (except sram) is internal nes memory.

This will probably be the last version for a long while. If there is a next version, it will most likely be marked 2.0 along with a redesigned GUI.

Sorry if the multiple posts are getting annoying.


Attachments:
coredump-v1.2.nes [16.02 KiB]
Downloaded 127 times
coredump-v1.2.asm [16.34 KiB]
Downloaded 118 times
Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Mon Oct 26, 2015 6:26 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
As I was chipping away at my framework code (and as a response to this)
I cleaned up the code a bit, and improved modularity.
The source is embedded in the rom, and will also come with an update to my framework code later.


Attachments:
coredump-v1.3.nes [16.02 KiB]
Downloaded 96 times
Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Wed Feb 03, 2016 1:31 pm 
Offline

Joined: Fri Aug 29, 2014 1:45 pm
Posts: 62
Hmm, could a clever use of serial outputs avoid using even CHR-RAM?

_________________
Idealogical
From: I have an idea. It seems logical. Thus everyone must agree.

Fail, fail, fail again. Keep trying, then maybe this damn thing will work. Eventually you might even know why it worked.


Top
 Profile  
 
 Post subject: Re: Coredump tool
PostPosted: Wed Feb 03, 2016 8:20 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Probably.
Every version of coredump except v1.2 could technically use CHR-ROM, but the stack pointer needs to be restored from somewhere like the nametable because I use the stack pointer able to save byte $01.

There's also an issue of code size with simply using the same approach coredump does. Since one of the original goals was to preserve RAM, we can't use subroutines. So everything has to be duplicated inlined. While copies of the nibble printing code is OK, I wouldn't want to duplicate the multi-layered loops of bit banging serial output.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 7 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