DISASM6 v1.5 - Nes oriented disassembler producing asm6 code
Moderator: Moderators
How high can Fortran RICH?
With the Fortran comment, I was almost expecting someone to pull out PUSH START TO RICH. Is Dian Shi Mali part of the corpus?clueless wrote:And the FORTRAN thing.. I'm sorry if I touched a nerve. I was just teasing (just a little).
Don't be astounded; it's expected. Normal person + pseudonymity + audience = dick (NSFW language).cartlemmy wrote:I'm sometimes astounded by the negativity that is thrown about on these forums.
Who's buying? Linus Torvalds originally wrote Linux in part so that he wouldn't have to pay for Unix.koitsu wrote:IDA Pro
I got it to create all labels, but now i've run into a new problem.. it seems ASM6 forces ZP mode for things such as AND $0023,x .. in the original code it's 3D 23 00 but after using ASM6 it generates 35 23, basically the same thing as AND $23,x
is there a way to avoid using ZP mode in ASM6?
edit: heh looks like i'm not the 1st person to experience this
is there a way to avoid using ZP mode in ASM6?
edit: heh looks like i'm not the 1st person to experience this
This looks like a bug in asm6. Some people might argue it's a "funny way of doing auto-optimisation", but I disagree.frantik wrote:is there a way to avoid using ZP mode in ASM6?
The parser appears to turn 16-bit absolute addresses with a high byte of zero ($00) into ZP. The assembler does use the correct opcode for the ZP mode, but that isn't what the user wants.
I also confirmed that tricks like "LDA $00ff+0" and "LDA 0+$00ff" do not work around the bug. Parens don't help either.
Loopy et al, can you comment on this?
It (asm6) seems to do this with any absolute addressing mode (including indexed ones) where a 16-bit value is provided and the high byte is $00. So you'll need to use .DB workarounds for all the opcodes that have that addressing mode. I haven't checked things like JMP ($00FF) yet, but you can do so by writing the code and using "asm6 -l blah.asm", then looking at "blah.lst" to see what gets generated.
Here's how I understand it working in assemblers such as ASM6 and ca65: The values $23, $0023, and 35 all get turned into the same data type (integer). If the assembler can determine that the integer is smaller than $100 at compile time, it emits a zero page instruction; otherwise, it emits an absolute instruction. Why would you want to force absolute indexed over zero page indexed addressing, except A. to join the end of zero page with the beginning of the stack, or B. to program the Super NES (with its movable zero page) instead of the NES?
(Rereading) You mean C. to make NESASM-assembled code round-trippable, as NESASM treats all addresses as absolute unless forced with a zero page operator.
EDIT: For that you need whatever counterpart ASM6 has to ca65's a: address size modifier, which forces 16-bit addressing.
(Rereading) You mean C. to make NESASM-assembled code round-trippable, as NESASM treats all addresses as absolute unless forced with a zero page operator.
EDIT: For that you need whatever counterpart ASM6 has to ca65's a: address size modifier, which forces 16-bit addressing.
it's to make all code "round-trippable".. i just used .hex instead, though it would be nice if ASM6 allowed a way to force it to use the specific opcode that is implied by the code.tepples wrote:(Rereading) You mean C. to make NESASM-assembled code round-trippable, as NESASM treats all addresses as absolute unless forced with a zero page operator.
This is a bit ironic, as some Japanese recently released a hacked version of NESASM, that you can force it to have the same behaviour as ASM6 when the -autozp option is used.
I now think about it though, apart from the other problematic quirks of NESASM, due to its origin as PCEAS, the "non-auto zero page" aspect of it was actually mandatory, since ZP for the PCE is located at $2000, so if you somehow want to code for both systems, especially when you want to reuse portions of codes in projects for both platforms, it will always be a good practice to manually specify when ZP addressing has to be used.
I now think about it though, apart from the other problematic quirks of NESASM, due to its origin as PCEAS, the "non-auto zero page" aspect of it was actually mandatory, since ZP for the PCE is located at $2000, so if you somehow want to code for both systems, especially when you want to reuse portions of codes in projects for both platforms, it will always be a good practice to manually specify when ZP addressing has to be used.
i updated the disassembler to version 1.1.. updated the first post but here is the link:
Download Dasm6 v1.1
it's now a multi-pass disassembler, usually taking between 4-5 passes for the labels to "stabilize", with an add'l pass needed to generate the output. you can specify how many passes you want with -p or -passes, or just let it run its course.
i've not tested it with a ton of roms but so far every mapper 0 rom has assembled into a 1:1 copy of the original. For 16k games that have 2 copies in in the .nes file, it will tweak the iNes header from 2 prg banks to 1 unless you disable 16k checking
If you use the new -c or -chr option it will export the CHR data and include it from the assembly file so you can instantly check if the disassembly is valid. The -r or -registers option aliases the common nes registers with their text names instead of their memory addresses.
next i want to add support for custom external memory location/label names (should be easy) and also support the data/code mapping from fceudx.. the code mapping also tells you which bank the code was loaded in so that might be essential for automatic disassembly of more complex roms.
Download Dasm6 v1.1
it's now a multi-pass disassembler, usually taking between 4-5 passes for the labels to "stabilize", with an add'l pass needed to generate the output. you can specify how many passes you want with -p or -passes, or just let it run its course.
i've not tested it with a ton of roms but so far every mapper 0 rom has assembled into a 1:1 copy of the original. For 16k games that have 2 copies in in the .nes file, it will tweak the iNes header from 2 prg banks to 1 unless you disable 16k checking
If you use the new -c or -chr option it will export the CHR data and include it from the assembly file so you can instantly check if the disassembly is valid. The -r or -registers option aliases the common nes registers with their text names instead of their memory addresses.
next i want to add support for custom external memory location/label names (should be easy) and also support the data/code mapping from fceudx.. the code mapping also tells you which bank the code was loaded in so that might be essential for automatic disassembly of more complex roms.
Last edited by frantik on Fri Feb 11, 2011 10:50 pm, edited 1 time in total.