Project to test 6502 on real computer

[stenlik]

I got into a strange situation because I'm a both - little hot-tempered and a little stupid, so please don't judge me:

- I own a 30 MOS 6502 CPUs.
- When arguing with friend of mine over whether they work, I bet I can prove that all CPUs are fine.
- Unfortunately, a NOP tester is not enough.
- I said I would write a short program in assembler (I have some 6502-assembler knowledge from my childhood) and it would demonstrate their functionality.

My idea is to take some 8-bit computer that uses 6502 (I never had one - unfortunately I only have only several C64s). I guess it could be for example BBC Micro or Atari 800XL and one by one I will insert CPUs there and test it.
But I don't want to damage those computers or CPUs, so I thought that if there was one with a socketed CPU (so that I do not need to to solder anything to the motherboard), I would connect the main board with cables to the external ZIF socket and put there CPUs one by one.
In addition, it must be easy to run some simple demonstration program on the target computer that I would ideally upload to that computer from e.g. the SD card.

Can anyone recommend a computer or help with the idea of ZIF?

I am enclosing the picture that illustrate my idea

Code: Select all

Broken external image link
https://gcdn.pbrd.co/images/xwHOLETUsV9J.png

[BigEd]

Welcome!

A word of warning: if those are not 6502s, as they might not be, any of the pins could have any function. As such, when you plug into a 6502 socket, you could be connecting anything to anything - there's a chance of creating a short circuit or having a signal driven by the host and by the device you plugged in. There's a chance of damaging the host machine. If that happens, you're down one machine, and also your subsequent tests are not valid.

At minimum, then, run a NOP test first. In fact other byte values can usefully give other observable behaviour, which can increase your confidence. If you have a multimeter with a frequency counting function - even quite cheap ones can have this function - you can read off more of the pins and get useful evidence.

Also beware, that some kinds of socket don't allow too many plug-unplug events before becoming a bit loose, especially so if what you're plugging in has slightly oversized pins. The CPU socket of your host machine should be protected by first plugging in a sacrificial socket and leaving that in place. Choose one without oversized pins!

Also note, ZIF sockets usually have very odd pins - flat, but at right angles to the expected orientation. They don't sit happily in most sockets so you might need to solder them to a board. I'm not sure about breadboards.

So, in principle your experiment might be useful, but it has some subtle risks.

[barrym95838]

It is still easy and relatively cheap to locate a working Apple ][+ or non-enhanced //e, at least in the USA, and AFAIK they all had socketed CPUs.

[plasmo]

stenlik wrote:

- I own a 30 MOS 6502 CPUs.
- When arguing with friend of mine over whether they work, I bet I can prove that all CPUs are fine.

If you've purchased these 6502 recently from eBay or Aliexpress, chance are they are mostly no good. I would definitely do NOP test first before plugging it into a real computer.
Bill

[Dr Jefyll]

BigEd wrote:

run a NOP test first. In fact other byte values can usefully give other observable behaviour

This.

The so-called NOP test involves a simple rig that always returns a certain fixed value (such as $EA) on the data bus whenever the CPU reads memory. The CPU address pins needn't be connected because the address is ignored; that's why an extremely simple arrangement is sufficient -- you don't need any RAM, ROM or I/O.

In your case I'd suggest you plug the CPU into a wireless breadboard, and use 8 resistors (1K to 100K; not at all critical) to pull the 8 data-bus pins high or low to form the desired value. The value $EA (or any other 2-cycle opcode) should cause the SYNC pin to go high once every two cycles. 3-cycle opcodes should cause it to go high once every 3 cycles, and so on.

At this point, you may find some of the CPUs defective, in which case you may wish to stop (not having invested much effort as yet). But if you wish to continue, you could do worse than to complete the breadboard using Ben Eater's design, or something similar.

So, in summary, you could start as if you're building Ben's design. But you initially omit the memory etc, only adding it later if required.

-- Jeff

[floobydust]

Pretty much all of the earlier Vic-20 machines had socketed CPUs... and those can be had quite inexpensively. The only one I found to have a soldered in CPU was the small board version which used a pair 2KBx8 RAMs and a pair of 1KBx4 RAMs, versus the original having 10 of the 2114 1KBx4 RAMs.

With the exception of the 6561 video chip, you can buy every chip in the Vic-20 and rebuild it from scratch quite easily. The only chip that is more rare these days is the 2114 RAM... but you can replace all 10 of those with a single 8KBx8 SRAM and have the 6665 bytes free. Note however that you'll need one 2114 for the color nybble RAM.

[JimBoyd]

If you get to the point of testing the chips on a real computer, they will not work properly on a C64. The Commodore 64 used the 6510 CPU which was basically a 6502 with a data direction register and data port at locations 0 and 1.