[comp.sys.apple] testing for 65C02 presence

AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (01/17/89)

>Date: Sun, 15 Jan 89 05:21:59 PST
>From: pbhyd!ldcol@pacbell.pacbell.com
>Subject: Re: testing all 3 parts of IIe enhancement

I wrote:
>Also from the monitor, type
>
>300:A9 00 1A 00
>300G
>
>You should get a register dump; I just need to know the value after
>"A=".  It should be 00 if you have a 6502 and 01 if you have a
>65C02.

Larry Colton asks:
>David, can you please explain why the above works?  What is the difference
>between the 6502 and the 65c02 as far as how the above code is treated?

On the 6502, opcode $1A doesn't do anything (anybody want to
guarantee that? as fasr as _I_ know it doesn't); on the 65C02, $1A
is "INC A" (or just "INC"), which adds one to the A register.

So the above program is

300:A9 00  LDA #$00
302:1A     INC
303:00     BRK

It loads A with zero, increments it to 1 _if_ a 65C02 (or 65802, or
65816, for that matter) is running the code, and then Breaks into
the monitor with a register dump.

>Larry Colton                {att,bellcore,sun,ames,pyramid}!pacbell!ldcol

--David A. Lyons              bitnet: awcttypa@uiamvs
  DAL Systems                 CompuServe:  72177,3233
  P.O. Box 287                GEnie mail:    D.LYONS2
  North Liberty, IA 52317     AppleLinkPE: Dave Lyons

matthew@sunpix.UUCP ( Sun NCAA) (01/18/89)

In article <8901161831.aa18496@SMOKE.BRL.MIL>, AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes:
# >Date: Sun, 15 Jan 89 05:21:59 PST
# >From: pbhyd!ldcol@pacbell.pacbell.com
# >Subject: Re: testing all 3 parts of IIe enhancement
# 
# I wrote:
# >Also from the monitor, type
# >
# >300:A9 00 1A 00
# >300G
# >
# >You should get a register dump; I just need to know the value after
# >"A=".  It should be 00 if you have a 6502 and 01 if you have a
# >65C02.
# 
# Larry Colton asks:
# >David, can you please explain why the above works?  What is the difference
# >between the 6502 and the 65c02 as far as how the above code is treated?
# 
# On the 6502, opcode $1A doesn't do anything (anybody want to
# guarantee that? as fasr as _I_ know it doesn't); on the 65C02, $1A
# is "INC A" (or just "INC"), which adds one to the A register.
# 
# So the above program is
# 
# 300:A9 00  LDA #$00
# 302:1A     INC
# 303:00     BRK
# 
# It loads A with zero, increments it to 1 _if_ a 65C02 (or 65802, or
# 65816, for that matter) is running the code, and then Breaks into
# the monitor with a register dump.
# 
# >Larry Colton                {att,bellcore,sun,ames,pyramid}!pacbell!ldcol
# 
# --David A. Lyons              bitnet: awcttypa@uiamvs
#   DAL Systems                 CompuServe:  72177,3233
#   P.O. Box 287                GEnie mail:    D.LYONS2
#   North Liberty, IA 52317     AppleLinkPE: Dave Lyons


    David, your dealing with tricks that may, or may not hold. The best solution
I'ves scene for testing which processor is in a machine, was published in a book
by David Eyes and used know (and valid differences between the processor to tell
them apart. 


	SED		;Use known bugs to determine processor type.
	LDA	#$99	;Load ACC with max BCD value.
	CLC		
	ADC	#$01	;Add one to exceed max value.
	BMI	DONE	;Bug in 6502 causes sign flag not to clear.
	CLC
	XCE		;XCE instruction is a 65C02 NOP.
	BCC	DONE	;If it was a 65816, carry would have set.
	XCE		;restore 65816 to 6502 emulation mode.
        SEC		;flag processor as 65816.
DONE	CLD		;restore processor to binary mode.
	RTS
*
* FLAG	VALUE	Processor
*
* SIGN  (minus)	6502
* SIGN  (plus)	65C02, 65816
* CARRY (clear)	65C02
* CARRY (set)	65816
-- 
Matthew Lee Stier     (919) 469-8300|
Sun Microsystems ---  RTP, NC  27560|          "Wisconsin   Escapee"
uucp: {sun, rti}!sunpix!matthew     |

ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (01/20/89)

># >300:A9 00 1A 00
># >300G

>	SED		;Use known bugs to determine processor type.
>	LDA	#$99	;Load ACC with max BCD value.

Still, none of these will find ALL of the potential differences.

I know of two flavors of 65c02 (Rockwell and NCR, I think), perhaps with
slightly different instruction sets.  Instruction timings may be different as 
well, like one 'fixed' the bug where certain instructions take an extra cycle 
when accessing over a page boundary?

[I believe Ted Medin wrote this...]
In article <546@cod.UUCP>, medin@cod.UUCP (Ted Medin) writes:
>Function		NMOS 6502		65C02
>---------------------------------------------------------------------------
>Indexed addressing	Extra read of		Extra read of last
>across page		invalid address		instruction byte
>boundary
...
>Jump indirect,		Page address does	Page address increments
>address=XXFF		not increment		and adds one cycle

And, how would you test for Zip or Rocket chippedness?

There's still a bit of work left to do.
-- 
					- Ralph W. Hyre, Jr.
Internet: ralphw@{ius{3,2,1}.,}cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"
--