martin8or wrote:
I don't know what the load address is so I just used 0000.
I think my binary might be able to work with 2 different processors. The first bytes are 02 85.
02 as far as I can tell doesn't do anything for the R6501 but does with the 65c02. With settings for 65c02 I get this ( I used 'A' on selected bytes instead of 'Shift A' )
0000: L0000 nop #$85
0002: nop
As others have mentioned, if it's a bare ROM image then it most likely butts up against $ffff so that it can contain the hardware vectors at the top of memory, which would be necessary for startup. WFDis will automatically start disassembling from where the RESET, NMI, and IRQ vectors point, if those memory locations are covered.
I can't always make that assumption about the ROM location, though, because when disassembling cartridge ROMs the host machine can have its own ROM at the top of memory, and the cart ROM is elsewhere. But butting it up against the top of memory smells like a good default value for the load address prompt.
Opcode $02 is undefined in the base 6502 and R6501, but the 65c02 states that all undefined opcodes become a valid NOP. That's why the R6501 doesn't generate any assembly code starting from a $02 byte, and 65c02 does.
GARTHWILSON wrote:
There are some strange things in the code above, like two LDA's in a row, and LDA #$FF twice without altering A in between.
The R6501 has I/O mapped at $0000-$001f, so superfluous zeropage LDAs likely stroke the latches and clear flags on read. This would especially be common if this is coming in from an interrupt.
As far as LDA #$ff; STA somewhere; LDA #$ff; STA elsewhere, that's pretty common if you're using macros to set registers, or if you have comments between small blocks of code. It's just safer hand-coding to keep code snippets independent of each other, unless you're really cramped for space or speed. The posted code reads sensibly IMO.
Also, I'll note to add an option for uppercase or lowercase hex digits in the disassembler. I personally prefer lowercase.
EDIT: The load address prompt now defaults to placing the ROM at the top of memory.
EDIT2: Added labels for the R6501 zeropage I/O stuff. I'm slightly hesitant as this currently obscures the actual address in the current UI, and the names are a little funky because there's quite a contrast between read & write behavior of the counters. I made up names from the descriptions listed in the
datasheet I found. Better label handling & tooltips revealing the underlying bytes will come later.
By the way, I'd love to get a copy of the ROM you're disassembling for my own testing, if you're willing to share.
Login
Register
FAQ
Search
That's what makes it better.
