So, what with the recent chat about fake parts and discovering that my so-called "R65C02P4" is really probably an NMOS part (albeit working well enough so far that I still think it was worth the $2), I'm thinking that I'd like to cons up a simple board to make it easier to test and play with random supposedly-6502 CPUs.

One thing that would be nice would be to easily be able to do the simple "wire data bus to NOP" test, so you can just drop in a CPU and start scoping it out, without worrying about what's in your ROM (or whether you even have working ROM or RAM). I'm thinking the easiest way to do this would be to put a couple of 8-gang DIP switches on the bus, with one turning on 4K7 pull-downs to ground and the other 4K7 pull-ups to Vcc. Leave them all off and you have a normally functioning machine, or turn on the ones you need to pull the data bus to $EA or whatever your preferred NOP is. (I don't know if any other opcodes would be useful—maybe the ones that are NOP on some processors but not others.)

Is that a sensible way to do this?

You'd also want jumpers to handle the various pinout differences, such as one to connect pin 1 to ground or leave it floating, and so on.

For debugging after that, you'd probably want a basic SBC setup: RAM in the lower 32K, ROM in the upper 16K, and a PIO and ACIA mapped between them. (You should be able to decode all of that with a 74LS138 and a 74LS00, or similar.) Throw some jumpers on the chip selects to allow you to hold them high instead of using the decoding inputs (à la the RC6502 Apple I SBC (schematic in the export/ subdir) and you're set.

(And yeah, it wouldn't be a very "safe" board to use, since it would be easy to mess up the jumpers and switches, but it's designed for hardware hackers, not beginners.)

_________________
Curt J. Sampson - github.com/0cjs

I've got something along those lines in progress as my "6502 Fake Finder" project. It doesn't have an arbitrary instruction selector, but instead runs software on the CPU under test and samples interesting control lines through a multiplexer and shift register attached to a 6522. It should be able to cope with any approximately pin-compatible 6502 variant, including the 65816 (enough pins are the same to boot up) and the 65C102 (in which the quadrature clock is a minor complication).

One of its features is a polyfuse on the power supply, and current-limiting resistors on all input lines to the CPU, to cope with chips that are absolutely not 6502s at all. Unfortunately an NMOS 6502 draws so much power under normal circumstances that the fuse probably won't open before seriously damaging (through latchup) whatever chip is actually inserted, but it'll save the power supply itself and the known-good components of the board.

It might also be reasonable to build a test harness that uses a known-good CPU as a basis for sequencing tests and sampling signals. I haven't done this because a falsely-marked part that isn't a 6502 at all is useless to me, so destroying it in the process of identifying that fact is not much of a loss.

Incidentally, the dip switches on the bus could be directly tied to the power rails, with the resistors between there and the pins. That'd save you a few components.

Ah, after a moment's thought and sketching I see what you mean. One resistor shared between a pair of Vcc and GND switches, rather than one for each.

Though come to think of it, it's probably not worth the bother to have switches at all. One of the things I want to do is bring out lots of stuff to header pins to make probing and testing easy (not to mention hooking it up to a breadboard for testing new peripherals); if I have the data bus pins coming out anyway, I can just drop on a bunch of pull-up/down header pins and use jumper wires to do the same thing. (These header pins would include jumpered pairs for power inputs to all the major chips so I can always stick an ammeter in front of the Vcc pin(s) to see power consumption, as well as the chip select jumpers I mentioned earlier.)

I also want to try out JuanGg's cool partial wire wrap technique. I don't know how well this mixes with it, but at least for the few pins I'm leaving unconnected for the moment (SYNC, Φ1, BE, a couple of NCs) it gives me an easy test/jumper point. And I suppose that works for the address decoding outputs, too, come to think of it; if I divide my upper 32K into 8 4K blocks with a '138, I can wire it all with jumper wires initially, wire wrap anything I want to make fairly permanent, and the rest are available for experimentation. (One of the things that most annoys me about my RC6502 Apple I Replica SBC is that there's 20 KB of unused address space that's decoded, but my only way to get access to that decoding is solder wires to the back of the board or directly to the chip pins.)


Now that's an interesting thought! I look forward to seeing what you do with that. Though I wonder why you'd bother with shift registers; wouldn't just having latches that trigger when required that you could then read directly do the same thing more easily?

_________________
Curt J. Sampson - github.com/0cjs

The shift registers collect a history of the signal over a series of consecutive clock cycles. I then have the 6522's timer trigger a parallel load from a shift register into its port latches, via an external trace which connects a timer-triggered output to the latch trigger. This way I should be able to observe the control signal sequences for eight different control pins, in both clock phases, over a whole sequence of interesting instructions, just by selecting the correct multiplexer line and altering the 6522 timer value. Enough to uniquely identify most sub-types of 6502 after the preliminary of performing software core-type detection.

For example, I could set the shift registers to sample the RDY pin, and set one of the 6522's timers to trigger the load sooner than the other timer triggers an IRQ, then execute opcode $CB (WAI). I then have two independent ways of confirming whether WAI actually works, which is only true on WDC 65C02s which are otherwise hard to distinguish from Rockwell 65C02s. One of these is observing RDY sampled low while the CPU is halted; the other is observing the IRQ timer in an expired state when the CPU resumes execution. Many such observations can be checksummed into a signature which can then be looked up in a table.

If I merely connected the control lines directly to the 6522, I wouldn't have as much control over when the signals are sampled, and I suspect it would be synchronised in a very awkward way with the Phi2 clock (whether that be the rising or falling edge). By using external shift registers, I can instead use a quadrature clock to sample the midpoints of both the Phi1 and Phi2 phases. The system clock is deliberately slow enough (below 500kHz) to ensure that the signals are stable when sampled, and the 6522 then latches the shift register's output on a Phi2 clock edge, when the shift register itself is stable.

Ah, I see! Very nice!

_________________
Curt J. Sampson - github.com/0cjs