[Pikachumanson]

I tried winzip, winrar, rarzilla... even magic iso. But I can't figure it out. How do you do it?

edit: nvm all you gotta do is change the extension apperantly but it won't play on my emu. So I tried another assembler and got a whole bunch of illegal opcodes. I am using dasm6-1.2, the latest version of asm6 which makes the bin file, and nesasm which gives me a whole bunch of illegal opcodes. I thought the process of disassembling and assembling was pretty straight but it's turning out to be a lot tougher than I thought. How the heck do you guys get disassembled asm filed to assemble the right way? I'd like a detailed explanation, please. Is it because when a file is disassembled it's not really assembled right and I have to do it bank by bank?

[henke37]

You have to disassemble correctly in the first place. Even being off by one byte can lead to issues. And of course, not all data stored in instruction memory is a valid program. You can find all sorts of things there, level data, graphics, audio, plain old nonsense and more. The disassembler doesn't know what is and isn't executable code. And trying to interpret data as the wrong format will lead to garbage that might not even assemble back to the original data.

[Pikachumanson]

How do i disassemble correctly?
Do I need a code data/log from FCEUXD to do it? Does that mean I have to beat the whole game first to get a a correct code/data log?

[STARWIN]

That is up to the disassembler you are using, and what service it actually provides you. There seems to be a newer version of dasm6: http://acmlm.kafuka.org/board/thread.php?id=6701

Code: [Select]

Usage:

disasm6 <file> [-t <file>] [-o #] [-l <file>] [-cdl <file>] [-cdlo #] [-d] [-i]
         [-h] [-c] [-p #] [-r] [-lc] [-fs #] [-cs #] [-fe #] [-ce <#>] [-len #]

  <file>                The file to disassemble
  t     target <file>   Target output filename (default is input filename.asm)
  o     origin #        Set the program origin.
                           (default: 0x8000 for 32k roms, 0xC000 for 16k roms)
  l     labels <file>   Load user defined labels from file
  cdl   cdl <file>      Use a code/data log generated by FCEUX
  cdlo  cdloffset #     Set the offset of the cdl file
  d     nodetect        Disable 16kb prg size detection
  i   ignoreheader    Do not look for iNES header
  h     noheader        Do not include iNES header (if found) in disassembly
  c     chr             Export CHR-ROM as file and include in disassembly
  p     passes #        Maximum number of passes (default: 9)
  r     registers       Use default NES registers
  lc    lowercase       Use lowercase mnemonics
  fs    filestart    Start reading at a specific file location
  cs    codestart    Start reading at a specific code location
  fe    fileend         Stop reading at a specific file location
  ce    codeend         Stop reading at a specific code location
  len   length    Number of bytes to read

If you only need to do a small hack, you can do it manually as FCEUXD SP 1.07 has an interactive disassembler in the debugger. Assembling would then simply mean editing the ROM with a hex editor. Can't blame anyone for using tools though.

[Klarth]

How do i disassemble correctly?
Do I need a code data/log from FCEUXD to do it? Does that mean I have to beat the whole game first to get a a correct code/data log?

Do you really need a full code and data disassembly?  It can be a long, painstaking process.

[Pikachumanson]

@starwin or anyone who knows for that matter, would dte count as a small hack? If so FCEUX SP is just just what the doctor ordered!

@Klarth I was just experimenting learning how to use the disassembler and assembler together by just taking an unaltered rom, disassembling and then assembling it to see if I got the hang of the programs before I attempted any actual ASM work on it. All I get is 991 kb of asm code from 256 k nes rom then when I use asm6 on it I get a 32k bin file. So in essence disasm6 1.4 makes five passes to disassemble the rom and asm6 make two passes to assemble it. So I'm not really understanding what is going in that regard. But no I don't want the whole code. I just want access to it so I can make a few changes and then reassemble the rom back together.

[Klarth]

@Klarth I was just experimenting learning how to use the disassembler and assembler together by just taking an unaltered rom, disassembling and then assembling it to see if I got the hang of the programs before I attempted any actual ASM work on it.  But no I don't want the whole code. I just want access to it so I can make a few changes and then reassemble the rom back together.

Yes, DTE is generally a small hack.  I mentioned that a full reassembly is a long, painstaking process so you should avoid it if possible.  What I recommend for your situation is to use a code tracing debugger to isolate the routine you're trying to modify.  Then you can use a program like xkas to write small bits of assembly code and patch it into your ROM.

[LostTemplar]

I was just experimenting learning how to use the disassembler and assembler together by just taking an unaltered rom, disassembling and then assembling it to see if I got the hang of the programs before I attempted any actual ASM work on it. All I get is 991 kb of asm code from 256 k nes rom then when I use asm6 on it I get a 32k bin file. So in essence disasm6 1.4 makes five passes to disassemble the rom and asm6 make two passes to assemble it. So I'm not really understanding what is going in that regard.

What you are trying to achieve is pretty much impossible. The disassembler can't* differentiate between data and code, so it ends up disassembling data as well, meaning that a) reassembling the whole mess won't work and b) you will be missing the data. On the other hand, manually creating a full disassembly that can be reassembled into the original game is, as Klarth said, a very long task and probably not suited for beginners.

That's why you should focus on the routines you actually want to change. You can for example find them by setting adequate breakpoints, or by tracing all executed code for a few frames and look for things like VRAM accesses in the trace logs.

*even with sophisticated code analysis it can't be 100% perfect

[henke37]

Of course, older consoles don't clearly separate code and data at execution either. There are loads of games out there which use the same data as both executable instructions and something else. Sometimes even intentionally.