6500/1 test mode

Topics related to older 6502-based hardware and systems including (but not limited to) the MOS Technology KIM-1, Synertek SYM-1, and Rockwell AIM-65.
Post Reply
User avatar
Konrad_B
Posts: 27
Joined: 11 Sep 2007
Location: Pruszków/Poland

6500/1 test mode

Post by Konrad_B »

Hi !

I have a dozen or so of 6500/1 MCUs from the Commodore 1520 plotter. I'm wondering if anyone knows something about the mysterious "test mode" mentioned in the MOS/CSG 6500/1 datasheet.
I would like to dump the internal ROM, maybe it is possible to do this with this whole "test mode" ? ;)
Practice safe HEX !
smilingphoenix
Posts: 43
Joined: 20 May 2006
Location: Brighton, England

Post by smilingphoenix »

I believe test mode makes the processor execute reads from successive addresses, effectively making the address bus function as a counter. The only way to get the processor out of this mode is a reset - it won't respond to interrupts. The instruction that causes this behaviour is HCF (for Halt and Catch Fire :twisted: ) Unfortunately, I don't know the hex opcode for this instruction.
Shift to the left, shift to the right,
mask in, mask out,
BYTE! BYTE! BYTE!
User avatar
Konrad_B
Posts: 27
Joined: 11 Sep 2007
Location: Pruszków/Poland

Post by Konrad_B »

Well, the datasheet says something about the possibility of "downloading" some code into 6500/1's RAM (64 bytes) and this is probably done via Port C. There are no timings though. No information about any strobe lines either :(
Practice safe HEX !
Jope
Posts: 1
Joined: 14 Apr 2009
Contact:

Post by Jope »

So, did you manage to load anything in there? I'm interested in this myself.
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Post by BigEd »

I found the datasheet (here:

http://web.archive.org/web/%2A/http://h ... s_6500.pdf

- see page 8 or the snippet below)

Sounds like pulling \RES to 10v overrides all memory reads directing them to port C. So you feed opcodes and operands into port C as if it was a 6502 data bus. (At minimum you'd need something like an EEPROM with a counter driving the address pins.) But those instructions can't read ROM because all reads are redirected. Why can't you just bring \RES down to 5v for the cycles where the ROM is read?

Perhaps you can, but if you're aiming to test the chip, you'd learn more if the code running from port C writes a secondary program into the 64 bytes of page 0 RAM. To run that program, it must be possible to feed in a JMP #0000 to port C and then bring \RES back to 5v in time for the next access.

Code: Select all

TEST LOGIC
Special test logic provides a method for thoroughly
testing the 6500/1. Applying a +10V signal to the \RES line
places the 6500/1 in the test mode. While in this mode, all
memory fetches are made from Port PC. External test
equipment can use this feature to test internal CPU logic
and I/O. A program can be loaded into RAM allowing the
contents of the instruction ROM to be dumped to any port
for external verification.
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: 6500/1 test mode

Post by BigEd »

(See also here
viewtopic.php?p=60478#p60478
Jim Brain succeeded in dumping code from these microcontrollers.)
User avatar
Konrad_B
Posts: 27
Joined: 11 Sep 2007
Location: Pruszków/Poland

Re: 6500/1 test mode

Post by Konrad_B »

BigEd wrote:
(See also here
viewtopic.php?p=60478#p60478
Jim Brain succeeded in dumping code from these microcontrollers.)
Yes, I know this was done - I am on the CBM Hackers mailing list as well.

I need to figure out where do I have all of these piggyback R6500/1-s, I guess last time I saw them it was when I was sending one of them + 1520 MCU to Silver Dream (that was before he put up this nice page about 1520 ROM dump process).
Practice safe HEX !
Post Reply