6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Nov 23, 2024 11:18 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 3
  [ 37 posts ]  Go to page 1, 2, 3  Next
  Previous topic | Next topic 
Author Message
Euphoric
 Post subject: processor detection
PostPosted: Mon Jun 21, 2004 2:27 pm 
Offline

Joined: Fri Dec 19, 2003 10:57 am
Posts: 24
Location: Toulouse
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
Top
 Profile  
Reply with quote  
dclxvi
 Post subject:
PostPosted: Tue Jun 22, 2004 8:32 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
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?)
Top
 Profile  
Reply with quote  
Mats
 Post subject:
PostPosted: Tue Jun 22, 2004 10:20 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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!
Top
 Profile  
Reply with quote  
Mats
 Post subject:
PostPosted: Tue Jun 22, 2004 10:20 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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!
Top
 Profile  
Reply with quote  
Mats
 Post subject:
PostPosted: Tue Jun 22, 2004 10:22 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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!
Top
 Profile  
Reply with quote  
leeeeee
 Post subject:
PostPosted: Tue Jun 22, 2004 12:56 pm 
Offline

Joined: Fri Aug 30, 2002 2:05 pm
Posts: 347
Location: UK
For NMOS/CMOS determination do this ..

Code:

   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.
Top
 Profile  
Reply with quote  
Euphoric
 Post subject:
PostPosted: Tue Jun 22, 2004 3:02 pm 
Offline

Joined: Fri Dec 19, 2003 10:57 am
Posts: 24
Location: Toulouse
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
Top
 Profile  
Reply with quote  
AtariKSI
 Post subject: Re:
PostPosted: Tue Jan 15, 2013 10:42 pm 
Offline

Joined: Tue Jan 15, 2013 9:23 am
Posts: 10
Location: Planet X
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.

_________________
http://www.krishnasoft.com -- "...simply wonderful." Make the world a better place-- instead of complicating things, make them simply wonderful.
Top
 Profile  
Reply with quote  
BigEd
 Post subject: Re: processor detection
PostPosted: Wed Jan 16, 2013 7:49 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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
Top
 Profile  
Reply with quote  
PaulF
 Post subject: Re: processor detection
PostPosted: Wed Jan 16, 2013 10:13 am 
Offline
User avatar

Joined: Mon Dec 08, 2008 6:32 pm
Posts: 143
Location: Brighton, England
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.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!
Top
 Profile  
Reply with quote  
AtariKSI
 Post subject: Re: processor detection
PostPosted: Wed Jan 16, 2013 7:55 pm 
Offline

Joined: Tue Jan 15, 2013 9:23 am
Posts: 10
Location: Planet X
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.

_________________
http://www.krishnasoft.com -- "...simply wonderful." Make the world a better place-- instead of complicating things, make them simply wonderful.
Top
 Profile  
Reply with quote  
BitWise
 Post subject: Re: processor detection
PostPosted: Thu Aug 31, 2017 9:19 am 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
I was hunting for this information on 65xx detection and thought I would add it here for posterity. From the WDC programming manual.
Code:
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

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs
Top
 Profile  
Reply with quote  
whartung
 Post subject: Re: processor detection
PostPosted: Thu Aug 31, 2017 8:52 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
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?
Top
 Profile  
Reply with quote  
BitWise
 Post subject: Re: processor detection
PostPosted: Thu Aug 31, 2017 9:09 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject: Re: processor detection
PostPosted: Thu Aug 31, 2017 9:18 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
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/ .

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 3
  [ 37 posts ]  Go to page 1, 2, 3  Next

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 27 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.