Page 1 of 3
processor detection
Posted: Mon Jun 21, 2004 2:27 pm
by 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
Posted: Tue Jun 22, 2004 8:32 am
by 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?)
Posted: Tue Jun 22, 2004 10:20 am
by 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!
Posted: Tue Jun 22, 2004 10:20 am
by 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!
Posted: Tue Jun 22, 2004 10:22 am
by 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!
Posted: Tue Jun 22, 2004 12:56 pm
by 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.
Posted: Tue Jun 22, 2004 3:02 pm
by 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
Re:
Posted: Tue Jan 15, 2013 10:42 pm
by AtariKSI
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.
Re: processor detection
Posted: Wed Jan 16, 2013 7:49 am
by 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
Re: processor detection
Posted: Wed Jan 16, 2013 10:13 am
by PaulF
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.
Re: processor detection
Posted: Wed Jan 16, 2013 7:55 pm
by AtariKSI
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.
Re: processor detection
Posted: Thu Aug 31, 2017 9:19 am
by 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
Re: processor detection
Posted: Thu Aug 31, 2017 8:52 pm
by 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?
Re: processor detection
Posted: Thu Aug 31, 2017 9:09 pm
by BitWise
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.
Re: processor detection
Posted: Thu Aug 31, 2017 9:18 pm
by GARTHWILSON
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/ .