It is currently Sat Jul 22, 2017 11:44 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 116 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8  Next
Author Message
 Post subject: Glad to see this
PostPosted: Sat Mar 05, 2011 12:48 am 
Offline

Joined: Sat Mar 05, 2011 12:38 am
Posts: 1
Hey guys,

I am the guy that came up with FCEUXD's Code/Data logger, the specification for the CDL files, and all of that. That stuff was all my idea back in 2004. My other idea was this exact project - a smart disassembler that produces a reassemblable disassembly using the CDL files (and ALL files - more on that later) as input. I actually implemented the disassembler (calling it xdDasm), but the project was abandoned. I never got it functional enough to be happy releasing it.

One thing I also implemented was an Address Label Logger. Basically FCEUXd would log these *.ALL files that would have ASCII lines that tell which instruction in the rom accessed which address in the rom. It was very useful for making labels work correctly across banks since if you see a JMP $8097, you don't know which bank that references and hence don't know where to put a label. It would only log accesses that went across banks.

Anyway, I am very happy to see someone else has done the disassembler. I know of a few other people that attempted this. _hyde_ had special logs he outputted from his own emu, and made his own unreleased disassembler - he did a lot of games with it. I don't know what snowbro used to make disassemblies for metroid and King's Quest 5 - he may have implemented something like this for it. Disch wrote his own smart disassembler and used his own logs from his emulator to do one for Final Fantasy 1. It's a pretty solid idea, just no-one has made a generic disassembler to do it.

You can find most of the disassemblies here that were produced by the above mentioned people.
http://gilgalad.arc-nova.org/vgscr/nes.html
(megaman 3 is the only one there that is xdDasm output. It was the only game I really got xdDasm to working with before I abandoned it)

There are a few cases I know of where this kind of smart disassembly won't work. There are games like Zelda which copies much of it's code to RAM. It won't be logged as code if it's being copied to RAM. Also, Fester's Quest has an annoying random number generator that likes to read random data from the ROM causing lots of crap to be logged as data (you have to hack that random number generator to be *nicer* before logging that game)

bbitmaster


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 06, 2011 11:57 pm 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 298
I couldnt get the address label logger to work in any version of FCEU* that i used

still got a few more features i want to add to this :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 12, 2011 3:30 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Nice, but I split two files, a Chase HQ NES file and a pure program BIN....Why is the program full of "illegal opcode"s? That'd be a nice fix. And also, this tool is pretty nice, but truthfully still isn't good enough to use to me and probably others, since it runs into so many illegal opcodes in normal code. I cxan't even find intructions like a read from $4016 when I know there is one that I need to change. Hopefully this gets fixed in the next version. :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 14, 2011 4:20 am 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 298
the illegal opcodes are usually data. but the program assumes everything is code unless you specifically tell it what is code and what is data, using a code/data log (CDL)

A CDL can be generated using most branches of FCEUD. Even incomplete CDL logs will give much better results


oh.. btw Chase HQ uses a mapper, so you have to tell the disassembler where to start and end.. it probably didn't show the code you were looking for because it wasn't in the first 8k, which is what will get read if you don't tell it otherwise.

you have to manually do the mapper stuff because the disassembler is has no concept of mappers... just like the NES console itself doesn't have a concept of mappers.. it just reads the 8k of prg memory


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 14, 2011 9:23 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Okay, I'll try that later. So this only reads 8K of data? Didn't realize that! -facepalm-


Top
 Profile  
 
PostPosted: Wed Feb 27, 2013 8:46 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Yeah that's right, resurrecting a thread from almost a year ago!

What's the status of this project? There seem to be bugs/etc. which are supposedly fixed in 1.5 (unreleased?) and so on, so I was hoping to get my hands on such, or at least find out how the project's coming along.

If it's one of those "I've lost interest" things, that's perfectly okay too! Just let us know.

Thanks!


Top
 Profile  
 
PostPosted: Sun May 12, 2013 1:41 am 
Offline

Joined: Sun May 12, 2013 1:37 am
Posts: 1
Run with the -lc option reduces the number of passes.
Just me?


Top
 Profile  
 
PostPosted: Tue Jan 28, 2014 7:40 pm 
Offline

Joined: Thu Jan 09, 2014 10:09 pm
Posts: 2
frantik, are you still maintaining disasm6? I made a few minor improvements to v1.4 and I'm including them in here as a patch file. All the changes have to do with handling transitions between code and data in the .cdl file. The changes are:

1. If a location is marked as both code and data in the .cdl file, then it should be treated as code (right now it's treated as data). This can happen when writing PRG-ROM to setup the mappers. For example, the North American Tetris uses "INC $8000" to reset the MMC1 mapper, but location $8000 contains valid code as well.

2. When something is decoded as hex data, disasm6 automatically reads 4 bytes at a time without checking ahead in the cdl to see if any bytes are marked as code. Once again in Tetris there are cases where a "JSR" is immediately followed by two data bytes which are a pointer for the subroutine to read. The subroutine then returns two bytes after the pointer, so the raw bytes in the .cdl file are: "code code data data code code ...". Right now, disasm6 will decode all four "data data code code" bytes as if they were data only. The logic I added to handle this is in the same loop that already checks for a label somewhere in the middle of those 4 bytes which would correctly cause us to read less than 4 bytes for this line of output.

3. When using one of the "JumpTable" or "RTSTable" labels, disasm6 starts to decode all data as table pointers until it encounters some user defined label. With my patch, the first byte marked as code will also end the decoding of the table. Otherwise, for each jump/RTS table you would need to manually add a dummy label to stop decoding any further.


Attachments:
File comment: Patch file for disasm6.php v1.4
disasm6.patch.txt [1.8 KiB]
Downloaded 103 times
Top
 Profile  
 
PostPosted: Tue Jan 27, 2015 1:11 am 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 298
Found this old thread and saw there was some interest in this disassembler

Here is version 1.5

* incorporates the changes suggested by ThVortex
* corrects the uc bug pointed out by mkmr
* option to stop writes to PRG from creating labels
* option to enable (experimental) mapper 2 support
* disabled the code handling the "branch out of range" bug

Please let me know if you find any bugs


Top
 Profile  
 
PostPosted: Fri Feb 06, 2015 8:29 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Yeah, this is a great tool, frantik. I'd love to convert it into C (and I might just do that) sometime. I dunno, when I see good tools like this, I just feel inclined to help and make them better in some way. Might even be a worthwhile github.com project between a bunch of us. (I already have some of my own projects up there)

Anyway rambling aside, I did find a bug:

Code:
D:\Console\bin>disasm6

Warning: gzinflate(): data error in C:\__OldXP-80GB\WinBinder\binaries\phpack\exe_bootstrap.php on line 95

DISASM6 v1.5 - A NES-oriented 6502 disassembler - Created by Frantik 2015
-------------------------------------------------------------------------------
Usage:
...

I'm not sure what's going on there with the gzinflate() call. I see no such thing in the .php script, so I'm lead to believe the PHP-to-executable compiler being used may have an actual bug. I should also note that the C:\__OldXP-80GB etc... directory is nothing on my system -- this looks to be something on the author's system.

Finally: what license is this code released under? I don't see any copyrights or licenses in the source or binary, so...


Top
 Profile  
 
PostPosted: Sun Feb 08, 2015 5:59 pm 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 298
Hey koitsu

Thanks for pointing out that bug. It seems to be caused by the PHP "compiler" I used called "PHPack". The path mentioned does exist on my machine. I will look into it. The program still works though it seems?

Technically there is no license. Feel free to do anything you like with the code, though I'd appreciate at least some credit if anyone decides to release a new or ported version


Top
 Profile  
 
PostPosted: Mon Aug 24, 2015 6:19 pm 
Offline

Joined: Mon Jan 23, 2012 11:27 pm
Posts: 137
So I tried this against a CNROM game and it seems to run into trouble right away:

Code:
reset:      ; irq/brk vector
;-------------------------------------------------------------------------------
irq:        lda $2002          ; $b814: ad 02 20 
            bmi Array          ; $b817: 30 fb     
__b819:     lda $2002          ; $b819: ad 02 20 
            bpl __b819         ; $b81c: 10 fb     
            lda $15            ; $b81e: a5 15     
            pha                ; $b820: 48       
            jsr __e2f5         ; $b821: 20 f5 e2 
            pla                ; $b824: 68       
            .hex 85            ; $b825: 85        Suspected data
__b826:     ora $20,x          ; $b826: 15 20     
            inc $20eb,x        ; $b828: fe eb 20 


that .hex 85 business is obviously not data- should be STA $15
I tried feeding a CDL from fceux in but that doesn't seem to have any affect.

Is there something else I should be doing? I've also never used the CDL thing so maybe I'm doing that wrong?

I've been running like so: disasm6 "elfland (unl).nes" -cdl "elfland (unl).cdl"


Top
 Profile  
 
PostPosted: Mon Aug 24, 2015 6:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5915
Location: Seattle
It's marked as "suspected data" because something's reading or writing to the $15 at $B826. (Hence why the __b826: label appeared)

This is kinda hard to address. For now, the easiest thing for you to do is change the code to treat the CDL parser's "was executed" as taking priority over "was read/written" (Search the source for "newCdlByte")


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 3:45 pm 
Offline

Joined: Mon Dec 26, 2016 8:58 am
Posts: 17
Hi, newbie here.

In referenc to this post:

irq:        lda $2002          ; $b814: ad 02 20 
            bmi Array          ; $b817: 30 fb     
__b819:     lda $2002          ; $b819: ad 02 20 
            bpl __b819         ; $b81c: 10 fb     
            lda $15            ; $b81e: a5 15     
            pha                ; $b820: 48       
            jsr __e2f5         ; $b821: 20 f5 e2 
            pla                ; $b824: 68       
            .hex 85            ; $b825: 85        Suspected data
__b826:     ora $20,x          ; $b826: 15 20     
            inc $20eb,x        ; $b828: fe eb 20 

and this response:

"This is kinda hard to address...."

In the interest of a possible bug report, I notice this in my code: (2 examples)

This code
LSR ; $8c15: 4a
LSR ; $8c16: 4a
LSR ; $8c17: 4a
TAX ; $8c18: aa
LDY __8c20,x ; $8c19: bc 20 8c
.hex 4c e2 ; $8c1c: 4c e2 Suspected data
__8c1e: .hex 8c ; $8c1e: 8c Suspected data
__8c1f: RTS ; $8c1f: 60


SHOULD BE

LSR ; $8c15: 4a
LSR ; $8c16: 4a
LSR ; $8c17: 4a
TAX ; $8c18: aa
LDY __8c20,x ; $8c19: bc 20 8c
JMP __8ce2 ; $8c1c: 4c e2 8c
RTS ; $8c1f: 60


SIMILARILY
LDA ($26),y ; $8d96: b1 26
STA $3b ; $8d98: 85 3b
.hex 4c ; $8d9a: 4c Suspected data
__8d9b: EOR ($8d,x) ; $8d9b: 41 8d

SHOULD BE
LDA ($26),y ; $8d96: b1 26
STA $3b ; $8d98: 85 3b
JMP 8d41: ; $8d9a: 4c 41 8d

Not sure if this is the same issue. Like I said, newbie.

Thanks


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 9:08 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1636
Location: DIGDUG
I don't believe frantik is maintaining this anymore... it's been almost 2 years.

What happens, is that some games use a base address for an indexed mode that actually is code (not data). The disassembler marks that point as the start of data, even though it is clear to a human that it is code.

It is a bug...BUT, it will technically reassemble correctly, if that counts for anything.

It's more annoying to me that illegal opcodes are assumed to be code, when that is rarely the case.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 116 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: zeroone and 10 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:  
cron
Powered by phpBB® Forum Software © phpBB Group