Test harness for identifying fake 6502s

[Chromatix]

I think I would need more than one transceiver or buffer - since not only the data bus lines are connected directly to the VIA. In particular, note the four address lines and the connection directly from the analogue multiplexer to the CB2 pin, which allows sampling on the rising edge of Phi2 (though only on alternate cycles).

Squinting at the WDC datasheet, it looks like there's a pull-up effect on input pins, as though they were set to drive high. This actually works fine for the gate circuit, since it's activated by driving the pin low and it's meant to float high otherwise. I think this is also fine for all the other pins, and actually means I don't need to treat initialising Port B outputs as quite so urgent a priority (since that means /OE on both shift registers will be driven inactive by default). With the W65C22S, the bus-holding devices could settle in either state at random, which is actually less good for this application.

[jds]

There are quite a few Rockwell R6502's on ebay at the moment with the same date code, 0448. I'm pretty sure they must be fake as that would be a manufacture date near the end of 2004 if I'm interpreting the date code correctly (2 digit year, then week of year). I don't think they were still being produced by then, the R65C02 possibly was, but had been rebranded to Conexant at least 2000. Not sure why you'd want to fake a 6502 instead of a 65C02?

[Chromatix]

A theory I've seen is that Chinese e-waste reclaimers, seeking to resell working parts, are under the impression that "newer" parts are more desirable. So they'll take a genuine NMOS or early CMOS part, sand the old markings off it, and print new markings with a fresh datecode. Often the new markings are for the wrong manufacturer and/or chip variant, but at least they're clear and sharp and look nice for the customer!

On the upside, the implausible datecode makes identifying these parts as having been remarked relatively easy. That, and seeing a whole batch of chips with identical markings but slightly different packages.

[1024MAK]

Certainly you find that remarked chips often have different mould stamps in the underside, while they all have exactly the same nice clean looking marking on top...

Often slower devices are marked as faster parts, or NMOS parts are marked as CMOS parts... both remarked DIL Z80 chips and remarked DIL 6502 chips are floating about on eBay.

As are some EEPROMs and flash ROMs. Some of which either only work for a while, or can’t be blanked or reprogrammed.

I’ve even come across a NE555 (in a “kit”) where the discharge pin did nothing, so it would not time...

Mark

[Chromatix]

"But they're all just 6502s, aren't they? What's the difference? It'll work."

Alas, it's nigh-impossible to communicate the difficulties to these people. They don't have the technical education nor the motivation to appreciate it.

[Chromatix]

I've made a further revision to the design, mostly adding a 20-pin header to which a UART daughtercard can be added, and a jumper to optionally trigger /NMI when an address in the $6/7xxx range is accessed - I can use this to manually trigger /NMI with a jump lead too, if need be. This should greatly simplify revising the firmware once initially bootstrapped, so I don't need to yank the EEPROM out just to reprogram it. A monitor program can sit in, say, the top 1KB of the ROM, leaving plenty of space for the main function of the device.

By putting the UART itself on a daughtercard, I can potentially use it as a template for a semi-standardised I/O expansion system, and reuse the card itself in other projects. It includes power, four address lines, pre-qualified /OE, /WE, /CE, /RESET signals, an /IRQ facility, and a clock input (here taken directly from the oscillator). A 28L92 can be wired up to those with only an inverter to correct the sense of the Reset line, and a level shifter to correctly interface with the remote host(s); the resulting board size should be nice and small. No extra components are required, besides the connector and jumper (which will only need to be populated on the development example), so it's just traces on the board which are free!

Speaking of bootstrapping, I should think carefully about the best way to get an initial program loaded into the EEPROM and running. The brute-force method may involve running the board without a CPU or oscillator, just wires tying the address and data lines high and low, and manually toggling Phi2 to perform a write. Or I could build something slightly more sophisticated and reliable…

[DerTrueForce]

For the development version, I'd suggest using a socket(I would prefer a ZIF myself, but those are expensive, and also bulky) so you can pull the EEPROM if you need to. Having a second EEPROM helps for this as well.

For production versions, you can program the EEPROM before you solder it down.

[Chromatix]

Sockets are a must for this project *anyway*, as there's a significant probability of eventually encountering a chip that isn't even a 6502 and thereby shorting out something. The 6510 pinout, for example, is a long way from being 6502 compatible - but it's the same size, and comes out of computers known to run 6502 code, and some random Chinese recycler might therefore mistake it.

The polyfuse may catch some of these before permanent damage is caused, but it's far from guaranteed because polyfuses react rather slowly. So at that point, being able to remove chips, test them independently, and replace them with good spares saves soldering up another copy of the whole board.

My present approach to bootstrapping may involve a secondary use of the expansion port intended for the UART daughtercard. Or I might build a daughtercard to fit the EEPROM socket. Either way, that sort of thing can carry a pile of diode-ROM logic and some switches, enough to load a bootstrap program into RAM and execute it. I would only need to temporarily redirect the $Fxxx select line to the $Cxxx one to treat the expansion port as containing a 16-byte ROM, easily done by removing the '138. It is, again, the sort of thing I would only need to build once and then reuse for several machines.

Or I could build a board specifically as an EEPROM programmer, and merely incorporate the bootstrap logic into that. Decisions, decisions…

[Dr Jefyll]

Chromatix wrote:

there's a significant probability of eventually encountering a chip that isn't even a 6502 and thereby shorting out something.

It's a good point. Maybe it'd be worth including series resistors on most of the pins of the Device Under Test, to limit current. A value of 500 ohms, say, would easily be tolerated by a real 65xx's MOS circuitry (and the CMOS circuitry of the fixture) as long as the clock rate is kept fairly low.

Even so, sockets may still be a good idea...

-- Jeff

[Chromatix]

Okay, the only pins that need that treatment are the ones actively driven by some other chip, which mostly means Phi2 (well, Phi0) and the data lines - so that's one individual resistor and one 8x resistor pack. All the others are either outputs from the CPU anyway, or already pulled only through resistors - except for /IRQ and /NMI, which are pulled high by resistors but may be actively pulled low under some specific conditions.

/NMI isn't much of a concern, actually, because its jumper is to be left open-circuit when testing an unknown CPU. That leaves /IRQ, of which the only drivers are the UART and VIA. The UART should also normally be removed when testing an unknown CPU, and the VIA comes out of reset in a state where interrupts and their triggers are all disabled. So it would take a fluke to cause the VIA to actively drive /IRQ into a fake chip.

The only remaining potential short is between the power pins, but that's what the polyfuse is for, and shouldn't affect other devices.

[Chromatix]

Still haven't got very far with the PCB layout, mostly because KiCad refuses to acknowledge the presence of the footprint databases.

But I *have* started writing the firmware. Except for specific tests, I'm having to stick to documented NMOS opcodes, which is fun. The first order of business is initialising the CPU (assuming as little as possible), then the VIA and shift registers, then immediately checking to see whether we're dealing with a divided clock (in which case we have to activate the workaround). Then I initialise the display and show a title string - turns out "6502 Fake Finder" fits precisely across a 16-character line - and access the debug trigger address (though there's nothing behind the NMI handler yet). So far so good, and we don't even need to use RAM to get this far.

So the next item is a very simple RAM test. I write the self-address to every entry in zero page, verify it, then do the same with the bitwise inverse. With ZP proved, I then use it to indirect-index over the rest of the 8KB RAM with the same test, followed by a self-page test. If any of these tests fail, I display the failing address (two digits if it happened during the ZP test, four digits otherwise) and halt in a busy loop.

All of the above display routines are inline-coded. But once the RAM test is completed, I can use the stack and therefore subroutines, so there's now a simple series of display routines ready for use. Currently these are able to copy an arbitrary zero-terminated string from a given address to a given place on the display; I'll probably add something to allow scrolling the display too.

From there, I can start implementing some actual identification tests. I'll probably start with several pure-software tests that can distinguish NMOS from CMOS - the BRA opcode, the JMP ($xxFF) bug, the Z flag after $99 + $01 in decimal mode (with a sanity check to ensure decimal mode itself works), and the cycle count differences of certain instructions (measurable by way of the VIA timers). I can also safely test ROR for the early-production bug. After that, I can move on to distinguishing the different CMOS CPUs.

One of the trickier instructions to test for is WAI - next to STP, which is almost impossible to test from the "inside". For a start, $CB is the undocumented 2-byte "SBX" on NMOS, so it may be best to just skip this test (along with many other CMOS-specific tests) if the CPU has already been identified as NMOS. On WDC chips, it will pull RDY low until an interrupt occurs - which we can trigger at will through the VIA, and monitor the RDY signal into the bargain. On non-WDC CMOS 6502s, $CB is a single-byte NOP - except on the 65CE02, where it is the 3-byte ASW abs. So to identify a WDC CPU, we first have to either eliminate the 65CE02 as well as the NMOS, or cope with the fact that some bytes may be skipped and additional accesses made. Then we can use both a read of the VIA timers and a check of the RDY signal to see whether the WAI operations actually occurred.

On the hardware signal side, note the trace from PB7 (via PB6) to CA1. This allows the active shift register to be sampled at a chosen time when T1 runs down, not merely when the CPU gets around to it. By repeating a test with different sampling times and shift register setups, a complete "signature" of the CPU's external behaviour can be obtained and compared to what's expected of each known model. Figuring out precisely what *is* expected might be an interesting project for a long flight…

[Chromatix]

Today I finally gave up on making KiCad's PCB editor work on OSX, and moved the project over to one of my Linux machines. That's already allowed me to assign appropriate footprints to each component, including drawing a new footprint for the power jack (from the datasheet dimensional drawing).

At the same time, I decided to rework the clocking arrangements. Now the VIA and other peripherals are clocked from Phi2_Out by default, ensuring they're always in step with the CPU - as long as it's not an '816. To account for the latter, I'll have to put in a jumper to manually change it over to the Phi2 input, because the Phi2_Out pin becomes VDA which has address-bus timing. Most 6502s will run fine with the jumper in either position. This happily reduces the component count and eliminates some rather ticklish structures in the clocking.

The shift registers, meanwhile, are still clocked by Phi3 and Phi4, and take Phi2_O as one of the multiplexed inputs - so they can still detect the difference between a normal 65xx, the 65(S)C102 with its clock divider, and the '816's VDA output.

And I came across a very useful table listing all the pin-compatible 40-pin 6502 variants. I can use that!

[Chromatix]

A day of hard work later, I have a 6-inch square, 4-layer PCB layout that passes design rule checks.

I'm not 100% happy with it, as I think the address and data buses would have been easier to route if I'd organised the devices in a different order, but I only had to eat into the VCC plane for a few address lines, and the GND plane is still completely continuous. I may try again tomorrow, after making a backup of this version, and possibly swapping some signals around on the sampling mux and the NAND gates.

But I do have a nice rendering of it…

[Chromatix]

On the software side, opcode $5C should be a really good discriminator between four of the six major core types:

- On NMOS, it's a 3-byte, 4-cycle NOP.
- On CMOS (C, SC, or WDC), it's a 3-byte, 8-cycle NOP.
- On the 65CE02, it's a 4-byte, 4-cycle NOP (mnemonic AUG - it's supposed to be a future-expansion prefix code).
- On the '816, it's a 4-byte, 4-cycle, JMP long instruction.

Since we don't care if an '816 core jumps to a different bank (because the bank byte latch isn't implemented on the board), we can put a useful opcode in the 4th byte (INY, say) and a valid jump target in the 2nd and 3rd, to which an '816 or '802 will jump. Then, both the NMOS and standard CMOS cores will execute the INY, while the 65CE02 won't, which is detectable. Finally, the NMOS and CMOS cores can be distinguished by observing the cycle count - read a free-running VIA timer before and after, and subtract.

Meanwhile, here's a distilled version of that model table I found:

[GARTHWILSON]

Chromatix wrote:

I think the address and data buses would have been easier to route if I'd organised the devices in a different order

Remember, if you haven't already, that you mix up address lines and mix up data lines on the memory, as mentioned in the first tip in the "Tip of the Day" column, at viewtopic.php?p=2303#p2303 . This will often make routing easier. Edit: I might have been forgetting your context. I'll review it and get back to this later.