processor detection

[Euphoric]

Hello there, I'm wondering if there's a "standard" or usual way to detect which 6502 processor variant is running the program...

I was going to use code $EB which is an undocumented SBC #imm on the NMos 6502, an undocumented NOP on the CMos type, and XBA on the 65802/65816...

Any handy alternative known ?

Best regards,

Fabrice

[dclxvi]

Actually, the $XB opcodes are documented 1 cycle NOPs on the 65C02.

There are a lot of ways to distinguish 6502 from 65C02, etc. In addition to the method you suggest, there are cycle count differences, differences in
BCD arithmetic when adding invalid BCD numbers. If it's case of where you have a handful of processors, and you want the software to tell them apart, then pretty much any approach will work. However, you may not want to rely on undocumented behavior. If the code could be run on an emulator, I don't think it's fair to expect an emulator have to replicate undocumented behavior.

The most robust way to tell a 6502 from a 65C02 that I know of is to use the JMP (Absolute) bug. It can be a little inconvenient to set up, but I've used it. Since the unused 65C02 opcodes are guaranteed to be NOPs of various lengths, you can tell a 65C02 w/o the BBR etc. opcodes from a new 65C02 with them. I've used TXY or TYX rather than XBA to tell a 65C02 from 65816, but either one is a suitable candidate.

(It may be possible that some very old Rockwell 65C02s don't guarantee that unused opcodes are NOPs, but I don't believe that was the case by the time they went into production. Anyone know for sure?)

[Mats]

I can just add that I saw in the WDC monitor software that $EB is used to distinguish between w65c02 and 65802/65816.

That it is SBC on 6502 is new to me. What I know is that the old 6502 mostly got into an internal infinite loop when an undefined operation iwas encountered making a reset necessary.

For 65c02 all undefined operations are NOP (i.e. documented!). No more any internal infinite loops!

[Mats]

I can just add that I saw in the WDC monitor software that $EB is used to distinguish between w65c02 and 65802/65816.

That it is SBC on 6502 is new to me. What I know is that the old 6502 mostly got into an internal infinite loop when an undefined operation iwas encountered making a reset necessary.

For 65c02 all undefined operations are NOP (i.e. documented!). No more any internal infinite loops!

[Mats]

I can just add that I saw in the WDC monitor software that $EB is used to distinguish between w65c02 and 65802/65816.

That it is SBC on 6502 is new to me. What I know is that the old 6502 mostly got into an internal infinite loop when an undefined operation iwas encountered making a reset necessary.

For 65c02 all undefined operations are NOP (i.e. documented!). No more any internal infinite loops!

[leeeeee]

For NMOS/CMOS determination do this ..

Code: Select all

	SED			; set decimal mode
	CLC			; clear carry for add
	LDA	#$99	; actually 99 decimal in this case	
	ADC	#$01	; +1 gives 00 and sets Zb on 65C02
	CLD			; exit decimal mode

Lee.

[Euphoric]

Thanks for all these ideas, it surely is cleaner to use defined behavior than to rely on undocumented features. I hadn't thought at using cycle differences in R/M/W absolute indexed instructions... that is interesting too, but only if a VIA is present (for the delay measurement). So the indirect JMP and the difference in BCD mode might be the best way to differentiate between NMos and CMos...

Cheers,

Fabrice

[AtariKSI]

dclxvi wrote:

However, you may not want to rely on undocumented behavior. If the code could be run on an emulator, I don't think it's fair to expect an emulator have to replicate undocumented behavior.

Why not? If real hardware consistently produces same results and they happen to be undocumented, then they should get documented and the emulator should mimic them. There are many wonderful effects/tricks achieved on retrocomputers based on bugs or undocumented features. Heck, some famous author wrote a book called "Undocumented Windows" which allowed one to optimize one's applications like BitBlt and so forth. That was back in Windows 3.x days. And even Microsoft was caught using those features in their software.

[BigEd]

Well, some emulators do try to emulate undocumented behaviour, and some don't! Presumably the different authors take different views on what the definition of a 6502 is and what the purpose of their emulator is. If you're not paying them to do the work, you get what they choose to write. From an engineer's perspective, it's always bad to rely on undocumented behaviour. What Microsoft did might have been internally documented and therefore part of a hidden specification.

Two of the near-fatal bugs in the Apollo landing computer were essentially specification errors: see https://plus.google.com/107049823915731 ... K2myxmSvpG

If you're not acting as an engineer, but as something more empirical, then of course you can choose differently. But 8-bit history includes games which didn't work on variant platforms, exactly because of the difference between defined and undefined behaviour. If you wrote such a non-portable game, you lost out to some extent. Of course you're right that some optimisations are possible using undocumented opcode: most of the posters on this forum take more of an engineering view.

Cheers
Ed

[PaulF]

AtariKSI wrote:

dclxvi wrote:

However, you may not want to rely on undocumented behavior. If the code could be run on an emulator, I don't think it's fair to expect an emulator have to replicate undocumented behavior.

Why not? If real hardware consistently produces same results and they happen to be undocumented, then they should get documented and the emulator should mimic them. There are many wonderful effects/tricks achieved on retrocomputers based on bugs or undocumented features. Heck, some famous author wrote a book called "Undocumented Windows" which allowed one to optimize one's applications like BitBlt and so forth. That was back in Windows 3.x days. And even Microsoft was caught using those features in their software.

The problem with using undocumented features in the NMOS 6502 is that they are not guarenteed to work the same way on all CPUs. I understand that different manufacturer's NMOS 6502s performed differently when executing the undocumented op-codes.

[AtariKSI]

PaulF wrote:

AtariKSI wrote:

dclxvi wrote:

However, you may not want to rely on undocumented behavior. If the code could be run on an emulator, I don't think it's fair to expect an emulator have to replicate undocumented behavior.

Why not? If real hardware consistently produces same results and they happen to be undocumented, then they should get documented and the emulator should mimic them. There are many wonderful effects/tricks achieved on retrocomputers based on bugs or undocumented features. Heck, some famous author wrote a book called "Undocumented Windows" which allowed one to optimize one's applications like BitBlt and so forth. That was back in Windows 3.x days. And even Microsoft was caught using those features in their software.

The problem with using undocumented features in the NMOS 6502 is that they are not guarenteed to work the same way on all CPUs. I understand that different manufacturer's NMOS 6502s performed differently when executing the undocumented op-codes.

Well, that's the point I was trying to get at with the STZ. Whether it would behave the same on all 6502 variants as a NOP. I know it behaves consistently on the Atari 8-bit computer series and Atari 5200 console. See for undocumented features/bugs to be used they don't have to be guaranteed to work across all platforms since the 6502s are already different and so is the hardware I/O ports across different machines like: Commodore 64, Atari 800, Vic-20, Apple IIe, PET, etc. But they just have to work consistently on the same machine or series of machines. It would be great if the undocumented feature worked across all retro-type machines, but even on a particular machine basis is enough. Most games/applications were ported over from one to the other and source code was modified extensively due to difference in the nature of graphics, audio, disk I/O, etc. of the machines.

[BitWise]

I was hunting for this information on 65xx detection and thought I would add it here for posterity. From the WDC programming manual.

Code: Select all

0001 0000                   KEEP    KL.14.6
0002 0000                   65816   ON
0003 0000
0004 0000                   LONGA   OFF
0005 0000                   LONGI   OFF         generate ‘6502’ code
0006 0000
0007 0000           ; CHECK - -
0008 0000           ; CHECK PROCESSOR TYPE
0009 0000           ; MINUS = 6502
0010 0000           ; CARRY CLEAR = 65C02
0011 0000           ; CARRY SET = 65816
0012 0000
0013 0000           CHECK   START
0014 0000 F8                SED                 Trick with decimal mode used
0015 0001 A999              LDA     #$99        set negative flag
0016 0003 18                CLC
0017 0004 6901              ADC     #$01        add 1 to get new accum value of 0
0018 0006 3006              BMI     DONE        branch if 0 does not clear negative flag: 6502
0019 0008
0020 0008           ; else 65C02 or 65802 if neg flag cleared by decimal-mode arith
0021 0008
0022 0008 18                CLC
0023 0009 FB                XCE                 OK to execute unimplemented C02 opcodes
0024 000A 9002              BCC     DONE        branch if didn’t do anything:65C02
0025 000C FB                XCE                 switch back to emulation mode
0026 000D 38                SEC                 set carry
0027 000E D8        DONE    CLD                 binary
0028 000F 60                RTS
0029 0010                   END

[whartung]

Interesting. So FB is an unimplemented opcode on the C02, and it's a NOP? Are all unimplemented codes on the C02 NOPs? vs the 6502?

[BitWise]

whartung wrote:

Interesting. So FB is an unimplemented opcode on the C02, and it's a NOP? Are all unimplemented codes on the C02 NOPs? vs the 6502?

Yes.

On my three chip board though I differentiate between 6502 and 65C02 using the JMP ($xxFF) bug and looking at the MSB of the address accessed as I'm generating the instructions on the fly to the processor.

I was thinking of using a sequence like LDA #1, XBA, LDA #2, XBA, STA $xx to differentiate between the 65C02 and 65C802 though rather than changing out of emulation mode. XBA will be a NOP on a 65C02 so it will store 2 and a 65C802 will store 1.

[GARTHWILSON]

whartung wrote:

Interesting. So FB is an unimplemented opcode on the C02, and it's a NOP? Are all unimplemented codes on the C02 NOPs? vs the 6502?

Yes, the unused op codes are NOPs, with different numbers of cycles. Jeff has used the single-cycle ones for his fast-I/O tricks. See the NOP summary about 3/4 of the way down my page on NMOS-CMOS differences at http://wilsonminesco.com/NMOS-CMOSdif/ .