R6501 Disassembler?

[GaBuZoMeu]

Ah OK, very well. Then perhaps you can post the last 6 bytes using a hex viewer/editor ?

Arne

[GARTHWILSON]

martin8or wrote:

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

Code: Select all

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)

Code: Select all

d000: Sd000         lda #$00
d002:               sta $14
d004:               lda #$04
d006:               sta $14
d008:               lda #$10
d00a:               sta $12
       <snip>

(I added the [code] and [/code] tags to get your white space back.)

The reset vector is D7BD. What do you get, starting at that address? (BTW, I suggest capitalizing A-F in hex numerals to make them easier to read, mixing with 0-9 which are never lower-case. Also, a lower-case "f" appears so narrow on my monitor it looks like a 1, so your first vector looks like D071 instead of D07F.) 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.

In looking at my Rockwell data book, I was surprised to find that in this non-CMOS part, they added the SMB, RMB, BBS, and BBR instructions without the other CMOS instructions. I never knew they did that; so I was wondering why they had RMB2 but used LDA #0, STA instead of STZ. Now I know.

[White Flame]

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.

[martin8or]

Did the site have a little meltdown then? I couldn't post.

Hi Garth,
If you mean starting at D7BD as in loading the code from that location then It doesn't disassemble anything. I think because there's an $02 in the way?
Sorry about the formatting, it wasn't the disassembler's fault, honest.

If it's OK to post the rom here I will.

TL12.zip

(4.66 KiB) Downloaded 125 times

Thanks for your help White Flame.

Martin

[GaBuZoMeu]

Hi Martin,

I´ve just used White Flames very fine disassembler with your .bin file and say it´s start @ $C000 :

Code: Select all

d7b0:               97 d8 85 66 bd 98 d8 85 67 6c 66 00 
d7bc: Ld7bc         rts 
d7bd: Reset_Handler lda #$04
d7bf:               pha 
d7c0:               plp 
d7c1:               ldx #$fe
d7c3:               txs 
d7c4:               jsr Sd000
d7c7:               jsr Sd02b
d7ca:               jsr Sd484
d7cd:               cli 
d7ce: Ld7ce         jmp Ld7ce
d7d1: Ld7d1         stx $cd
d7d3:               lda $53
d7d5:               bne Ld7f1
d7d7:               lda $65
d7d9:               eor #$80
d7db:               sta $65
d7dd:               bmi Ld7ed
d7df:               sty $cf
d7e1:               jsr Sd336
d7e4:               jsr Sd1f1
d7e7:               ldy $cf
d7e9:               ldx #$00
d7eb:               beq Ld801
d7ed: Ld7ed         ldx #$04
d7ef:               bne Ld801
d7f1: Ld7f1         clc

Just the first few instructions after RESET looks very well. Init Flags, init Stack, then 3 subroutine calls probably do further inits.
At $D7CE it looks as if the program enters an infinite loop - perhaps it is ok, if all further action is event driven (due to timer interrupts or external irq´s) - BUT THIS INVESTIGATION IS UP TO YOU

Good Luck

Arne

p.s.: nice piece of SW this disassembler

[White Flame]

No, thank YOU guys for using it. That's what makes it better.

[martin8or]

I'd like to thank everyone for their help and interest.
The disassembler looks nice with the labels (Thanks White Flame).

It makes sense that it enters a loop. It's waiting for two things, either a command from the Atari software which makes the R6501 output SMPTE timcode, or a SMPTE timecode input which makes the R6501 output a Roland sync pulse and synchronise the midi sequencer software on the Atari to the incoming SMPTE stream.

The R6501 is constantly outputting a clock of around 15.75khz on one of its pins. (which is an old video horizontal scanning frequency, wonder if this is deliberate?)
This clock drives one of the PAL16R8 chips that the SMPTE comes into (the straight SMPTE signal also goes into the R6501), and inside the PAL16R8 there is some counting etc that takes the bi-phase signal and splits a clock signal away from the bits. If there's a stream of 1's an output pin on the PAL goes high and this along with the split off clock go to the second PAL16R8 were if the correct input conditions occur a count of 0 to 79 occurs and this is output to the R6501. 80 bits is how many bits there are in a packet of SMPTE data. (I think that's how it works anyway).

Thanks
Martin

[martin8or]

I tried to make a schematic and footprint symbol for the R6501 using kicad. If you use it you will have to check it's OK because I gave up trying to use that dreadful software. I'm going to try geda or orcad386.

[GARTHWILSON]

martin8or wrote:

I tried to make a schematic and footprint symbol for the R6501 using kicad. If you use it you will have to check it's OK because I gave up trying to use that dreadful software. I'm going to try geda or orcad386.

For something as simple as a 40-pin DIP, it should only take a jiffy to make a new component—at least my 22-year-old Easy-PC Pro does which runs under DOS. Is OrCAD 386 as old as the name makes it sound? I wonder if that's the one we used in my last job which I left in 1992. It had more bugs than an ant hill. There certainly was no temptation to take home a bootleg copy. But then, what can you expect from a company which after 30 years still hasn't learned the correct schematic symbol for a resistor. There's a comparison of EDA software at https://en.wikipedia.org/wiki/Compariso ... A_software . Most of it is free. I'm sure others will be interested to hear what you experience with whatever else you try.

[barrym95838]

GARTHWILSON wrote:

... For something as simple as a 40-pin DIP, it should only take a jiffy to make a new component—at least my 22-year-old Easy-PC Pro does which runs under DOS ...

I believe the R6501 is a 64-pin QUIP.

Mike B.

[GARTHWILSON]

Yes, I forgot. So it should take 1.6 jiffies.

[GARTHWILSON]

GARTHWILSON wrote:

There's a comparison of EDA software at https://en.wikipedia.org/wiki/Compariso ... A_software . Most of it is free. I'm sure others will be interested to hear what you experience with whatever else you try.

There's even a GEOS-based CAD from 1997 to run on the Commodore 64, AIUI. See pages 6 & 7 of http://6502.org/documents/publications/ ... 97_jun.pdf . It apparently does not produce gerber photoplotter and excellon drill files, but instead only prints our your design to transfer to copper-clad board when you make your own boards. Most here won't consider this a serious alternative at this point, so I mention it mostly for comic relief. I'm sure a decent CAD could be done with a C64 and a 512KB REU though, as my CAD ran on a 16MHz '286 with only 1MB of RAM and I did very complex boards without running out of memory.

[dwesti]

is exists instruction set for testing disassembler?

[White Flame]

The instruction set is just 6502, without 65c02 extensions, but with the bit operations that other 6502 variants have had (SMB, RMB, BBS, and BBR).

The link to the data sheet above doesn't work anymore, probably because the ID in there ended up being a session ID, not a document ID. Look at the 2nd section of this page to get a fresh link to the datasheet again.

If you want a binary to test out disassembly, martin8or's TL12.zip attachment up higher in this page is one. You can compare your output to using the disassembler in my signature link below, just make sure to set the CPU Model to R6501 first.

[whartung]

The best test of a disassembler is to disassemble code that you have the source code to and check that it matches.