DISASM6 v1.5 - Nes oriented disassembler producing asm6 code
Moderator: Moderators
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
a suggestion with this program, frantik:
add an NSF disassembler, as an option or as a seperate program with at least minimal-to-no bankswitching support!
see the NSF file format on the wiki for more info:
http://wiki.nesdev.com/w/index.php/NSF
but is a great tool otherwise, should be a good FREE alternative even if it isn't portable!
add an NSF disassembler, as an option or as a seperate program with at least minimal-to-no bankswitching support!
see the NSF file format on the wiki for more info:
http://wiki.nesdev.com/w/index.php/NSF
but is a great tool otherwise, should be a good FREE alternative even if it isn't portable!
AKA SmilyMZX/AtariHacker.
it's "portable" in the sense that it can be used on any major OS.. though for mac/linux you will have to install PHP first. just think of it as a "dependency"Hamtaro126 wrote:even if it isn't portable!
the windows EXE in the zip file is mostly the PHP interpreter with the script packed inside of it.. it's possible to do the same thing with a unix executable, just no one has done it
actually.. it would be super trivial to make a web-based form for this so i might do that as well.. then it can even be used on CromeOS
btw, check out the output of excitebike.. i used a code/data log that was 94% complete as well as a couple dozen user defined labels. i think the disasm looks pretty nice when using the c/d logs, if an unknown area is encountered, it just assumes that it's probably the same type as the previous byte, unless the address is a known program code label created by a jump or branch. using this method, you don't have to have 100% complete logs to generate good output
this tool should really simplify the initial stages of creating completely documented disassemblies like doppleganger's SMB disassembly
Minor change (my OCD is kicking in):
This is technically the IRQ/BRK vector. Most games would use this for hardware IRQs. Naming it "break" and "break vector" is a bit misleading. Possibly naming the label "irqbrk" and the comment as "IRQ/BRK vector" would be better?
Code: Select all
;-------------------------------------------------------------------------------
; break vector
;-------------------------------------------------------------------------------
break: .hex 83 00 ; $fff0: 83 00 Invalid Opcode - SAX ($00,x)
.hex 04 14 ; $fff2: 04 14 Invalid Opcode - NOP JoyMirrorGame
.hex 04 14 ; $fff4: 04 14 Invalid Opcode - NOP JoyMirrorGame
.hex 04 14 ; $fff6: 04 14 Invalid Opcode - NOP JoyMirrorGame
.hex 04 d4 ; $fff8: 04 d4 Invalid Opcode - NOP $d4
;-------------------------------------------------------------------------------
; Vector Table
;-------------------------------------------------------------------------------
vectors: .dw nmi ; $fffa: 3b c2 Vector table
.dw reset ; $fffc: 84 c1 Vector table
.dw break ; $fffe: f0 ff Vector table
made some changes, mostly to do with how the output is displayed, but one cool thing is support for jump tables.. if a user defined label ends with "JumpTable" then all of the following pairs of bytes are assumed to be labels (until the next label is encountered)
Version 1.3
and again, the RAW output of excitebike from the program (using a code data log and fair amount of user defined memory and PRG labels, .. i've been disassembling excitebike for a bit now )
Version 1.3
and again, the RAW output of excitebike from the program (using a code data log and fair amount of user defined memory and PRG labels, .. i've been disassembling excitebike for a bit now )
good suggestion .. i was already planning on adding support for pointer tables (where all the low bytes are listed first then the high bytes) but RTSTable sounds like a good idea tootepples wrote:Nice idea. Would it be too hard to add support for labels starting with RTSTable, where the following two-byte values are assumed to be one less than a label?
btw can you name an example of a Mapper 0 game which uses RTS Tables?
Last edited by frantik on Mon Feb 21, 2011 4:57 pm, edited 1 time in total.
Code: Select all
.hex b9 88 00 ; $e45f: b9 88 00 Bad Addr Mode - LDA $0088,y
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
thanks, i added a check for that addressing type in the next version.. now exicitebike is "bad addr mode" free.. i thought it was weird that the original code seemed to be waste a few bytesDwedit wrote:Why can't it specify LDA $0088,Y? The Zero Page,Y form of this instruction does not exist, so there's no conflict.Code: Select all
.hex b9 88 00 ; $e45f: b9 88 00 Bad Addr Mode - LDA $0088,y
working out some bugs... now it's faster and can produce valid output in only 2 passes with a complete CDL file.
tepples do you (or anybody) have an example of an NROM game which uses the RTS trick? from my searches so far i think i've just heard of final fantasy using it. i have the code implemented to disassemble it but i need a test case
tepples do you (or anybody) have an example of an NROM game which uses the RTS trick? from my searches so far i think i've just heard of final fantasy using it. i have the code implemented to disassemble it but i need a test case
Two of my NROM-128 games use it. LJ65 uses one RTS dispatcher for the playfield's state and calls it once for each player (I think the variable was called curTurn). Concentration Room uses three: one for the title screen menu, one for the game state, and one for the CPU opponents' state.frantik wrote:tepples do you (or anybody) have an example of an NROM game which uses the RTS trick? from my searches so far i think i've just heard of final fantasy using it. i have the code implemented to disassemble it but i need a test case
EDIT: Will explain further below
Last edited by tepples on Tue Feb 22, 2011 11:59 am, edited 2 times in total.
In LJ65
src/t.s#game_cycle
In Concentration Room
src/litemain.s#titleDispatch is a really tricky one: it pushes the address of a handler for a title screen menu item, and then instead of RTSing directly into the handler, it JMPs to a routine that clocks the random number generator, and that RTSes into the handler. src/aidiocy.s#doAI and src/memorygame.s#stateDispatch are more straightforward. Notice that every time you build these in ca65, the addresses of these routines will change. By default, Concentration Room is preprocessed by a shuffler so that I can 1. more easily find buffer overflows and 2. trace leaks should I ever make an enhanced version of the game for selling copies on carts. You can disable this by changing shufflemode in the makefile.
src/t.s#game_cycle
In Concentration Room
src/litemain.s#titleDispatch is a really tricky one: it pushes the address of a handler for a title screen menu item, and then instead of RTSing directly into the handler, it JMPs to a routine that clocks the random number generator, and that RTSes into the handler. src/aidiocy.s#doAI and src/memorygame.s#stateDispatch are more straightforward. Notice that every time you build these in ca65, the addresses of these routines will change. By default, Concentration Room is preprocessed by a shuffler so that I can 1. more easily find buffer overflows and 2. trace leaks should I ever make an enhanced version of the game for selling copies on carts. You can disable this by changing shufflemode in the makefile.
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm