If your Apple 1 works, then you can enter a test program to check whether ROR works. This is perfectly safe; the CPU will produce the wrong result (basically an ASL that doesn't update the C flag) but otherwise will keep running fine. You're probably more familiar with WozMon than I am, for entering
the following:
Code:
0300: A9 0D 20 EF FF A9 01 18
:6A A2 00 B0 02 A2 03 BD
:1D 03 20 EF FF E8 C9 00
:D0 F5 4C 1F FF 4E 4F 20
:52 4F 52 20 42 55 47 00
This should print "ROR BUG" or "NO ROR BUG", based on whether ROR($01) sets the C flag - it should, but the buggy CPUs won't.
If you do have the ROR bug, I'd be interested to confirm whether my 6502 classification routine correctly identifies even the early 6502 as NMOS - which it should, since it doesn't rely on any ROR behaviour. I'll reproduce it here in hex format, and with an Apple 1 compatible output routine:
Code:
A9 00 85 84 85 85 A9 1D
85 83 A9 6B 85 1D A9 4E
47 83 45 83 C9 53 D0 04
80 02 A9 65 20 EF FF A9
0D 20 EF FF 4C 1F FF
This version includes the extra check for a naive 6502 emulator (which implements undocumented opcodes as NOPs). I've slightly modified it to produce an E for that case instead of a lower-case n, because the Apple 1 only supports upper-case.
A real NMOS 6502 should print N; a 65SC02 would print S; a 65C02 with the Rockwell instructions would print C, and a 65816 or 65802 would print 8. If you get anything *other* than N on a ROR-bug 6502, let me know and we'll puzzle it out.