It is currently Sat Nov 18, 2017 1:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Thu Feb 28, 2013 2:57 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Subject says it all.


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 3:59 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
I used da65 from cc65.org to recover DPCM Split from the .NES binary on my PowerPak's CF card after a laptop's SSD died.


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 4:33 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Thanks tepples. This actually gives me an opportunity to force myself to learn/deal with ca65 (might as well use the same assembler as the disassembler for the stuff I'm working on, since ca65 has some stuff in it I need which asm6 lacks).

I guess I'd best go read that ca65 tutorial-esque thing on the nesdev wiki.

Edit: Or not, doesn't really go over the details I need. I think there's a forum post here somewhere I need to dig up...

Edit #2: This is what I was looking for, mostly: viewtopic.php?f=2&t=9192


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 5:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
I just found da65's -i flag, which refers to infofile support.

It's too bad NES emulators (e.g. FCEUX) with Code/Data Logger support don't export to that format. Although I'm willing to bet the .CDL format is simple, and one could probably write a converter of some sort. The file format, according to FCEUX:

Code:
CDL log files are just a mask of the ROM; that is, they are the same size as the ROM, and
each byte represents the corresponding byte of the ROM. The format of each byte is like
so (in binary):

For PRG ROM:

+-------------------------------+
| x | P | d | c | A | A | D | C |
+-------------------------------+
 
       C = Whether it was accessed as code.
       D = Whether it was accessed as data.
       AA = Into which ROM bank it was mapped when last accessed:
               00 = $8000-$9FFF        01 = $A000-$BFFF
               10 = $C000-$DFFF        11 = $E000-$FFFF
       c = Whether indirectly accessed as code.
               (e.g. as the destination of a JMP ($nnnn) instruction)
       d = Whether indirectly accessed as data.
               (e.g. as the destination of an LDA ($nn),Y instruction)
       P = If logged as PCM audio data.
       x = unused.

For CHR ROM:

+-------------------------------+
| x | x | x | x | x | x | R | D |
+-------------------------------+

       D = Whether it was drawn on screen (rendered by PPU at runtime)
       R = Whether it was read programmatically using port $2007
               (e.g. Argus_(J).nes checks if the bankswitching works by reading the
                same byte of CHR data before and after switching)
       x = unused.

One thing that still confuses me about FCEUX's CDL feature is that for games that lack CHR-ROM (e.g. pure PRG-ROM and use CHR-RAM), it still prints a "completion" number and is somehow tracking """CHR-ROM""" anyway. Makes no sense how/why.


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 7:59 pm 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
Being a bit of a NIH (not invented here) syndrome person, I wrote my own. http://bisqwit.iki.fi/source/nescom.html
It's an assembler, but includes also two disassemblers. I basically use them for reverse engineering NES ROMs.

Here is an example of the output of clever-disasm, one of the programs included in above:

http://bisqwit.iki.fi/jutut/lunarball.lst
http://bisqwit.iki.fi/jutut/lunarball.map <- using this configuration file.

The other disassembler (disasm) does not attempt to do any separation of code/data, it just provides a disassembly and that's it. It supports headered FDS, IPS and O65 files, though, and knows how to handle them, and will properly treat the symbols in the object files to provide a symbolic disassembly where applicable. It does not support ca65's object files. ld65 can be configured to produce o65 files, but unfortunately they appear to be stripped of fixups / relocations, which would provide the symbol information.


Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 8:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Thanks for that, Bisqwit.

Your assembler looks like something I'd actually prefer to use, but of course do all of my work on Windows (XP) systems, so I'd need native Win32 binaries. Sure, my FreeBSD box (as a server) sits next to me, but I've never particularly liked relying on two separate tools for two different OSes when most of the debugging is to be done on one (Windows).

The feature in ca65 that I needed to rely on was the option called .charmap. minus/Norman Yen's old 65xxx assembler called x816 had this too, via the .asctable directive (not to be confused with the .table directive). I've attached a copy of the x816 documentation (just an ASCII text file, despite named with the .doc extension) in case you wanted to know what those directives did.

What you have there (the clever-disasm bit) is sort of what I had originally intended TRaCER to be back in the day. *claps happily* How... clever. :-) But that leads me to ask: what generated that .map file?

Edit: by the way, I was able to get my stuff up and working (assembling/linking and generating a working image) after reviewing rainwarrior's MOON8 example. I'm still rolling my eyes over the fact that ld65's layout/config file only allows hash (#) as a comment delimiter; sure, semi-colons in the source, but hashes in the config. Three cheers for consistency.


Attachments:
x816.doc [39.81 KiB]
Downloaded 56 times
Top
 Profile  
 
PostPosted: Thu Feb 28, 2013 9:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
I use da65, but that's because ca65 is my preferred assembler, so... might as well keep it in the family.


Top
 Profile  
 
PostPosted: Fri Mar 01, 2013 7:28 am 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
koitsu wrote:
What you have there (the clever-disasm bit) is sort of what I had originally intended TRaCER to be back in the day. *claps happily* How... clever. :-) But that leads me to ask: what generated that .map file?


Thanks. I did, in iterative steps over successive runs of the disassembler with the previous configuration file, beginning with an empty one. The disassembler can simulate the CPU (at approximate level) and track mapper access (mappers 0, 2, 3 and 24) to some extent, and it begins the disassembly from the reset, NMI and IRQ vectors. As I gain understanding on what the code does, I add more labels to the configuration file. Some labels are added for corrective purposes, because especially in the first steps, before all jump tables are discovered, a lot of code may be mis-identified as data, and rarely the other way round. The disassembler automatically discovers some pointer tables (both jump and data pointers), through simulating the CPU and tracking how those memory regions are used, but not all. At later steps, the corrective labels can be removed.

Also, here are Win32 binaries of the programs, current development version snapshot: http://bisqwit.iki.fi/src/arch/nescom-1 ... -win32.zip


Top
 Profile  
 
PostPosted: Fri Mar 01, 2013 10:52 am 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
Quote:
One thing that still confuses me about FCEUX's CDL feature is that for games that lack CHR-ROM (e.g. pure PRG-ROM and use CHR-RAM), it still prints a "completion" number and is somehow tracking """CHR-ROM""" anyway. Makes no sense how/why.


It's actually because of my recent edits... previously it has check for this case, and doesn't log VRAM data at all. But previous implementation was incompatible with the unif format, which is loads different way. So I fixed this, but still don't come to the accurate solution for VRAM case, sorry ;) I'll fix that for sure.

As for your question, I'm not sure if my way is good for you, it's involving IDA Pro, which is costs too much for most, if you do not accept WAREZ... ;)
But I'm using my own iNES loader plugin, which is supports bank separation based on the mapper number (IDA allows you to make cross-bank reference, but can't do it automatically of course, so I do it manually, so here bisquit's way is much better). And of cource I can load CDL file from emulator and autogenerate most of executed code and accessed data, just I need after that, is make names and link calls between banks... So, here another problems of course ;) CDL file contains info only about EXECUTED and accessed code/data, so it can't fully disasm all possible code cases, like bisquit's does... In my case, it's exact;y what I need, while I'm disasm something only to find some secrets ;)


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 8:17 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
CaH4e3 wrote:
Quote:
One thing that still confuses me about FCEUX's CDL feature is that for games that lack CHR-ROM (e.g. pure PRG-ROM and use CHR-RAM), it still prints a "completion" number and is somehow tracking """CHR-ROM""" anyway. Makes no sense how/why.


It's actually because of my recent edits... previously it has check for this case, and doesn't log VRAM data at all. But previous implementation was incompatible with the unif format, which is loads different way. So I fixed this, but still don't come to the accurate solution for VRAM case, sorry ;) I'll fix that for sure.

Should I send you a PM with a list of all the bugs/issues I've encountered in FCEUX? :-) The more I use it the more stuff I find.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 8:35 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
Zeromus recommended signing up for SourceForge and posting problems and feature requests to the issue tracker.


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 9:02 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
tepples wrote:
Zeromus recommended signing up for SourceForge and posting problems and feature requests to the issue tracker.

Thanks for that -- guess I'll keep a file that documents each one I come across. Whee...


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 1:36 pm 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
tepples wrote:
Zeromus recommended signing up for SourceForge and posting problems and feature requests to the issue tracker.


yep, that's the best ;) btw, I fixed VRAM issue with CDLogger today...


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 3:02 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
CaH4e3 wrote:
tepples wrote:
Zeromus recommended signing up for SourceForge and posting problems and feature requests to the issue tracker.

yep, that's the best ;) btw, I fixed VRAM issue with CDLogger today...

Thank you! By the way, are there any tie-ins between the CDLogger and the disassembler? The more I reverse-engineer some bits, the more I realise that the disassembler being able to discern what's code vs. data would be extremely useful. The same goes for being able to manually tell the debugger what's code vs. data (similar to what IDA Pro has, which you're already familiar with), e.g. "$C202 to $C26F is data".


Top
 Profile  
 
PostPosted: Sat Mar 02, 2013 10:19 pm 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
koitsu wrote:
Thank you! By the way, are there any tie-ins between the CDLogger and the disassembler? The more I reverse-engineer some bits, the more I realise that the disassembler being able to discern what's code vs. data would be extremely useful. The same goes for being able to manually tell the debugger what's code vs. data (similar to what IDA Pro has, which you're already eady familiar with), e.g. "$C202 to $C26F is data".

As I told before, I load cdl files, generated by the CDLogger, directly to Ida and make disasm based on the code/data info from it. It's just a simple idc script for that.

http://cah4e3.shedevr.org.ru/misc/ines_loader_src.rar
http://cah4e3.shedevr.org.ru/misc/ines_loader_bin.rar
http://cah4e3.shedevr.org.ru/misc/cdl.idc


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

All times are UTC - 7 hours


Who is online

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