Support extended 6502 opcodes

[notxvilka]

See the list here: http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes

More documentation is available at https://csdb.dk/release/?id=248511

NoMoreSecrets-NMOS6510UnintendedOpcodes-20242412.pdf

See files:

• librz/arch/p/asm/asm_6502.c
• librz/arch/p/analysis/analysis_6502.c
• librz/arch/isa/6502/*

[ashutoshsao]

hey, i am new to low level programming and dont use ai for coding, i was tring to figure out and work on this issue but as i read through the docs and pdf for opcodes, it was very hard to get a graps of what to write, as there was mostly symbols what were't making any sense to me like the intermediate language, but it helped me learn a lot of new things :)

[amanthatdoescares]

Hi, I’ve been looking into this issue.

I found that most extended / undocumented 6502 opcodes (e.g. SLO, RLA, SRE, RRA, DCP, ISB, LAX, SAX, etc.) are already present in librz/arch/isa/6502/6502dis.c, so disassembly works.

However, in librz/arch/p/analysis/analysis_6502.c these opcodes are currently handled under the generic ILL case and have no analysis semantics (cycles, ESIL, flags, memory effects).

My proposed approach is to add proper analysis support only (no assembler changes), implementing these opcodes incrementally:

remove them from the ILL block,

reuse existing addressing-mode helpers,

and implement ESIL semantics based on NMOS 6502 “unintended opcode” documentation (e.g. SLO = ASL(mem) then ORA A).

I plan to start with one opcode family (SLO variants) in a small PR and expand from there if the approach looks good.

Does this sound like the right approach for this issue?

[KabiRJoshi1]

@notxvilka I'm interested in working on this. I've reviewed the NoMoreSecrets PDF and the ffd2 list. Should I start by adding the mnemonics to the disassembler (asm_6502.c) first, or would you prefer I tackle the analysis logic simultaneously?