Hi all,
I'm a complete beginner.

Any pointers on what to use as a disassembler for R6501?
I tried an online one for 6502 but there were a few too many ???. I would like to minimise as much head scratching as possible.

Thanks
Martin

Hi Martin,

the reasons for these ??? may be, that the disasm is trying to decode a (data-)table. It is not unusual that there are sections of data within a program. And of course trying to translate that back into code won´t work.

If you know the starting address of the program you wish to disassemble, start there, disassemble a few instructions. If there occur instructions like JMP, JSR, BCC, BCS, BEQ, BNE than these are places where the program flow might change to some other locations. Bxx instructions are conditional branches, JMP is a JuMP to a new location (new address). A JSR is a Jump to SubRoutine, again a new location where regular instructions should be found, but at there logical end an RTS instruction causes the µP to jump back to the JSR it comes from - well usually, there are ways to change that..

If you disassemble your code piecewise you might figure out what the hack there happens

Good Luck!


Arne

What are the software differences between the 6501 instruction set and the 6502? I think the ROR was non-existent in the very, very beginning, but that would affect both 6501 and 6502. However, that also means software won't be using those opcodes, so their presence isn't much of an issue. The 6501 was just to achieve pin compatibility with the motorola chip sockets it was competing with, but I'm not aware of any software differences. The 6502 and 6501 thusly should be able to use the same disassemblers. It's very vaguely like saying "I want a disassembler for software running on my Core i5-750, but all I can find is x86_64 disassemblers".

To avoid all the ???'s for normal software, one of the magic features to look for is a "tracing" disassembler, which doesn't just disassemble all bytes in a range, but traces which instructions follow others from some starting address. My online 6502 family disassembler here does tracing and some other neat stuff, letting you rename labels and spawn asm traces interactively. For disassembling raw memory dumps, make sure your binary file ends in .rom or .bin, and use shift-A to disassemble from the selected byte. It doesn't yet export .asm files, but you can save the state of the disassembly.

EDIT: Oh, I'm an idiot. R6501 != 6501. My disassembler linked above does support those same RMB/SMB/BBR/BBS bit instructions, from a 65c02 mode. The 65c02 supports even more instructions beyond those, but that model with bit instructions should work for R6501.

EDIT 2: There, I bolted "R6501" into the CPU model selection, assuming it's just 6502 + the 65c02's bit instructions. I don't know any additional quirks about this model, so let me know if something goes screwy. Make sure to refresh the disassembler's page if you visited it in the interim.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

^ I did try your disassembler yesterday but it didn't work because I hadn't named the file to .bin. it works now.
Thank you Arne and White Flame.

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
0003: jmp Lc594
0006: L0006 ldx #$02
0008: rti
0009: L0009 brk
000a: L000a brk
000b: L000b inx
000c: bra Lffab
000e: bit L0000
0010: jsr S0078
0013: nop
0014: bra L0083
0016: stz $90,x
0018: cpy #$00
001a: lsr $12aa
001d: sty L0000
001f: sty $10
0021: ldx #$3c
0023: stp
0024: L0024 bra L004f
0026: nop
0027: bit #$40
0029: sbc $77b6,y
002c: dec a
002d: brk

With your disassembler's R6501 settings I get (I'm guessing the R6501 would ignore the first byte 02 unless it responds to an illegal opcode?)
0000: L0000 02
0001: L0001 sta $1f
0003: jmp Lc594
0006: L0006 ldx #$02
0008: rti
0009: L0009 brk
000a: L000a brk
000b: L000b inx
000c: L000c 80
000d: L000d sta L0024,x
0010: jsr S0078
0013: bbs2 $80,L0083

As opening moves I'm not sure they are correct so maybe it all starts from a different address.

I'm off to read some datasheets now and will probably need to draw a proper schematic up to help me, I only have a rough one.
If it helps my R6501 uses
NMI
[PB7..0]
[PA0, PA2, PA5]
[PC0, PC4]
[PD6..PD0]
and a 27c128 Eprom has OE controlled by A15 of the R6501

Thanks
Martin

If the ROM seems to contain a jump to c594 - and we're not sure that this is code rather than data - there's a fair chance you need to map the ROM to a start address of C000.

Also, a 65xx ROM will often be mapped at the top of memory, so the starting point is to check the last 6 bytes, which are the 3 vectors. If they lead to likely-looking code, that's a good sign. The Reset code will sometimes contain a CLD and TXS, which are both unusual opcodes otherwise.

If placing the ROM at C000 is the same as placing it at the top of memory, that's a good sign!

27C128 is 16KB so it should range from C000..FFFF. Then at FFFC and FFFD the low and the high byte of the address of the first instruction after reset is stored.
If you use a load address C000 and look at FFFC,FFFD pick up these values and start disassembly from that address.

As BigEd says, one of the very first instructions after reset is setting the stackpointer to something known (usually FF) with a sequence LDX #$FF, TXS (A2 FF 9A) and resetting the D-Flag (CLD = D8). If these instruction occur there, you are on track .

Arne

Welcome, martin8or, and good luck with your project. Um... What exactly is your project?!!

I ask simply out of curiosity. But I would be interested in more details. A description, maybe a schematic, some photos perhaps... if you're willing and have time, that is.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

If I go to the last 6 bytes at 3ffa..3fff
I see
7f d0 bd d7 4a d0
If I use the R6501 settings in the disassembler I get

3fba: L3fba brk
3fbb: 00 00 00 00 00
3fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3ff0: 00 00 00 00 00 00 00 00 00 00
3ffa: L3ffa bbr7 $d0,L3fba
3ffd: smb5 $4a
3fff: bne L0000

If I load using address C000 a load of things happen of their own volition. C000 looks like hex but D000 has this (a small sample)
d000: Sd000 lda #$00
d002: sta $14
d004: lda #$04
d006: sta $14
d008: lda #$10
d00a: sta $12
d00c: lda #$ff
d00e: sta L0000
d010: sta $01
d012: lda #$ff
d014: sta $02
d016: rmb2 $10
d018: lda #$d0
d01a: sta $18
d01c: lda #$07
d01e: sta $19
d020: lda $1c
d022: lda #$3e
d024: sta $1c
d026: lda #$00
d028: sta $1d
d02a: rts
d02b: Sd02b ldx #$9f
d02d: lda #$00
d02f: Ld02f sta $40,x
d031: dex
d032: bne Ld02f
d034: sta $40
d036: jsr Ld38e
d039: lda #$3e
d03b: sta $1c
d03d: sta $56
d03f: sta $5e
d041: lda #$ff
d043: sta $cc
d045: sta $ba
d047: jmp Ld453
d04a: IRQ_Handler pha

Thanks
Martin

Hi Jeff,
The project is called a Steinberg Timelock. It synchronises a Midi sequencer on the Atari ST with SMPTE time code ( a bi-phase synchronising signal, says the interwebz )
Inside there are 2 x protected PAL16R8 devices doing some counting etc to decode the bi-phase signal into clock and data 1's and 0's. It's taken me about 3 months to reverse engineer those 2 PAL chips with my HP 1661 and ABI Boardmaster 4000 so I might as well go the whole hog and see what the rest of it is doing . I'm feeling confident for a change.
Thanks
Martin
If the photo works it will show my replacement PAL16V8 devices.

A belated welcome,Martin! Thanks for sharing your project, it's always good to hear about what people are building... or debugging... or reverse engineering.

Thanks everyone for showing some interest.

Hi Martin,
ok, this could be more complex. The 27C256 is a 32KB EPROM, it could range from $0000 to $7FFF or $8000 to $FFFF.
Because the narrow space there, it is possible that some of the address and (!) even some of the datalines are connected out of order. (say µP_A0 is connected to EPROM_A2, µP_D0 is EPROM_D4 or so). This would be no problem for the designer (he uses a special wired adaptor) but to you it twists up things even more.
So you should use an ohmmeter to figure out how addresslines and datalines are connected between µP and EPROM.

Good luck!

Arne

Hi Arne,

I stuck that 27C256 in there so it would use less power than the 27128 that was in there before. I didn't have a spare cmos 128. They are more expensive than a C256. The original was a 128.
All the eprom data pins correspond to the correct R6501 pins and addresses A12..0 are correct and A13 is correct for Full Address Mode.
Thanks
Martin

Hi Martin,

ok, then 16KB. You mentioned earlier A15 is used for OE - well OE is active low => A15 == 0 which means the EPROM could only be accessed in the range $0000..$7FFF. Perhaps there is an inverter for A15, that would make more sense to me.

If you take a look at the last 6 bytes - do not disassemble them, just use a hex viewer, these 3x 2 bytes are NMI-vector / RESET-vector / IRQ|BRK-vector.
A vector is just a 16bit address in lo/hi sequence as always in the 65xx world. The RESET-vector should reference to the beginning of a program that set up everything, starting with stack setting, decimal mode, then most probably the bus mode and the peripherals.

Once you have this RESET entry address the disassembler should give you reasonable code. To figure out the meaning is of course ways more complex

Good Luck again!

Arne

Hi Arne,

Yes A15 goes through a 7404 and the output of that goes to OE.

Thanks
Martin