From: Christian Krüger (christian.krueger_at_pace.de)
Date: 2003-09-04 11:11:15
> For the 65C02 not all opcodes are defined. There are still > undefined opcodes > which will be executed as a NOP by the CPU, but they're nevertheless > undefined. But also the defined 65C02 opcodes produce byte literals: (output snippet from da65 with --cpu 65C02) ... and $2038,y .byte $34 ... ...where '$34' should translated to 'BIT zpx'! BTW: As you allready know, I would like to differ between 65C02 and 65SC02 *especially* when I have to disassemble something... > $FB will never get disassembled as NOP (the disassembler will > use .byte $FB > instead). And I cannot see the real reason behind this > switch. Maybe you can > tell me why you want this option. When I have binaries for the 65C02 where I cannot differ between code and data, it would help very much if I can detect invalid instructions by inspecting such comments. Because there are no invalid instructions for the 65C02, the occurrence of 'unusual 6502 instructions' would be a good indicator... Maybe someone like to have support for undefined 6502 opcodes (like 'LAX' etc.), where the same feature would be nice. Annother feature I like to have is commenting the code with the characters which are represented with the binary code to differ data efficient from code. I think this is quite usual for disassemblers. (Even if I know that support for different char-code-pages would make this feature even more usefull.) BTW2: After you mentioned the generated *.dis file I found it. (I never looked for it before - at least a generation msg from da65 would be nice...) regards chrisker ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-09-04 11:13:13 CEST