For some years, it has been the case that what you order from eBay might not be what you actually receive. Frequently the advertisement is for a genuine WDC part, and the CPU will arrive with WDC markings from their earlier production runs (but with too late a date code), but actually turn out to be an NMOS part, or if you're lucky, an early CMOS part from Rockwell or CMD. Other times, a badly faded marking might be scarcely visible, yet alone readable, leaving you uncertain as to what exactly you have received.
There are fairly simple ways to distinguish an NMOS part from CMOS in software, provided you have a running machine. But if you've built your SBC anticipating a modern CMOS part, you'll probably find an NMOS CPU won't work at all - whether due to incompatibility of the glue logic and peripherals with TTL signals, or too low a supply voltage, or too high a clock speed. This inevitably leads to frustration.
What you need in that case is a test harness that will accept *any* genuine 6502 and identify it for you, using both software and hardware differences. As a bonus, since the most essential pins are the same, it should be possible to slot a 65816 (or 65802) into the same test harness and have that be identified, too. Only 6502 variants with incompatible pinouts, such as the 6510 or "mini" versions, could not be handled by a single board, unless extra sockets were fitted specifically for that purpose - but I think those are much less susceptible to counterfeiting, anyway.
The essential pins are RESB, A0-15, D0-7, Phi2-in, and R/W, all of which are identical in function across the whole family (except for bank address multiplexing with the '816). These are sufficient for attaching a small SRAM and EEPROM, a small LCD character display for output, and a 6522 VIA. The latter is to host cycle-accurate timers, produce IRQs, and probe some of the remaining control-side pins whose function varies between 6502 family members.
The W65C22N (not S!) and 74HCT family glue logic will work fine with both NMOS and CMOS CPUs, and a clock speed of between 100kHz and 1MHz ensures compatibility with even the slowest speed grades of NMOS. For ease of construction, a design using only through-hole parts would make sense. Hobbyists needing to test only a small number of CPUs might stick with a conventional DIP socket for the CPU, while some might prefer to install a ZIF socket to handle larger numbers quickly and without damage.
There is one wrinkle in the shape of the NMOS 6512, on which Phi1 is an input, not an output, and is required for correct operation. I think this could be handled safely by generating Phi1 externally, and feeding it to the relevant pin through a parallel RC connection and a jumper. On a 6502 the internal and external drives will be identical, so no significant current will flow. To identify the 6512, removing the jumper and thus the external clock will make it stop working, while a normal 6502 will keep going. This pin must also be tied low to run the 65816 correctly, since it becomes the ABORT signal. Hence the jumper should normally be left in the "no clock input" position, and only set to make a 6512 work; this jumper's state should be fed to a 6522 input for detection. NB: the 65SC12 (found in the BBC Master) does not require Phi1 input, and simply doesn't produce a Phi1 output.
There's also a (presumably rare) version that takes a crystal across two pins and divides the resulting frequency by 4, producing a quadrature clock signal on the Phi1 pin as well as a Phi2 output. This would leave the CPU operating at a quarter of the speed expected, and indeed out of step with the 6522. I think the 6522 might still be accessible in that condition, and 250kHz is still well within the range of acceptable NMOS frequencies, so it should be easy to notice this variant by observing instructions taking 4x as long as they should. It may also be feasible to rig up a detector to find where Phi2-out gets out of step with Phi2-in, and provide that detection at one of the 6522's inputs.
Other pins that can usefully be probed include:
- VPB (pin 1) which is marked Vss on both NMOS and early CMOS chips, and is apparently only VPB on WDC. The latter will read high except when actually taking an interrupt. A weak pull-down should ensure compatibility with early chips.
- RDY (pin 2) which is normally pulled high, but which executing WAI on a WDC part will pull low. The 6522's built-in shift register could be used to record a short-term history (every other Phi2 cycle), to be examined immediately after a WAI test (which will involve generating a timed interrupt).
- MLB (pin 5) which is NC on early parts, even some CMOS parts, and Vss on the 6512. It's present on variants intended for multiprocessing, and indicates when a RMW operation is in progress. It may be sufficient to attach this to the 6522's pulse counter input, with a weak pull-down.
- SYNC (pin 7) becomes VPA on the 65816, and thus stays high during a greater proportion of cycles (when fetching operands in the instruction stream, as well as opcodes). This is a sufficiently important way of distinguishing the 65802 from the 65816 to be worth installing a shift register to capture a cycle-accurate history, then accessed through one of the 6522's ports.
- Phi2-out (pin 39) becomes VDA on the 65816, and thus goes high during a smaller proportion of cycles (opcode fetches and data accesses only). This could be an additional method of distinguishing the 65802 from the 65816, but the sample point would have to be at mid-phase instead of at Phi2 leading edge, since the original use of this pin is unstable at the latter moment. This requires generating a quadrature clock, not just Phi1 and Phi2.
- SOB (pin 38) input on the 6502 becomes the multiplexed MX output on the '816. This should be pulled high, but its functionality can be checked by putting the '816 in native mode (having first established the possibility of doing so), and then setting both accumulator and index registers to 16-bit mode. This will pull the MX pin low on an '816, but have no external effect on an '802.
This might be a good excuse for me to get back up to speed with KiCAD…