nesdev.org

- My $0.02 if that matter... In my CPU emulator, I use a syntax that helps me to identify the opcode and its addressing mode. In short words, it's opcode string + addressing mode number. So, you have LDA1, STA1 or LDA6 etc..

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!

Hamtaro126 wrote:even if it isn't portable!

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"

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?

ok, thanks, i'll change it any other "OCD" stuff like that is very welcome!

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 )

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?

tepples 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?

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 too

btw can you name an example of a Mapper 0 game which uses RTS Tables?

Why can't it specify LDA $0088,Y? The Zero Page,Y form of this instruction does not exist, so there's no conflict.

Dwedit wrote:

Code: Select all

            .hex b9 88 00                    ; $e45f: b9 88 00  Bad Addr Mode - LDA $0088,y

Why can't it specify LDA $0088,Y? The Zero Page,Y form of this instruction does not exist, so there's no conflict.

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 bytes

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

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

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.

EDIT: Will explain further below

cool thanks.. and since i'm feeling lazy, could you tell me the location of one of the RTS tables in one of your games?

edit.. nm, i see the source for concentration room is included so i can just use that

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.

the WORDs specified in my CDL turn to BYTEs.

And I think (I read) the next version should fix it,

EDIT: Sorry if I reminded you, but aren't you still going to add minimal NSF support?

You can use CDLs with the NSFs using FCEUX Code/Data Logger!