6502.org

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

Arne

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.
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.

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. Thanks for your help White Flame.

Martin

Hi Martin,

I´ve just used White Flames very fine disassembler with your .bin file and say it´s start @ $C000 :
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

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

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

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.

I believe the R6501 is a 64-pin QUIP.

Mike B.

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.

is exists instruction set for testing disassembler?

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.

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