apple 2 chip's help

[reuven]

Do you have R65c02 Chip's for apple 2 ?
Let me know

Tank's

R.K

[David Empson]

reuven <rkop...@barak-online.net> wrote:

> Do you have R65c02 Chip's for apple 2 ?

I don't understand the question. Are you asking:

(a) Can anyone here supply me with an R65C02 chip for use in an Apple
II?

or

(b) Was the 65C02 used in the Apple II an R65C02?

The answer to the second question is no. Apple never used the Rockwell
variant of the 65C02 in the Apple II, but there isn't anything stopping
an end user from replacing the supplied CPU with a Rockwell version.

In particular, the extra instructions in the R65C02 are not commonly
available, and they are incompatible with later processors in the 65xx
family, namely the 65816 (used in the IIgs) and the 65802.

The original Apple II used a MOS Technology 6502 (or an equivalent).
Apple continued to use the 6502 until the unenhanced Apple IIe. The
Apple IIc and enhanced Apple IIe use the Western Design Center (or
equivalent) 65C02. The Apple IIgs uses the WDC (or equivalent) 65816.
"GTE" seems to be a common brand for the CPUs I've noticed in more
recent Apple II models. The WDC 65802 was available for a while as a
third-party upgrade for 8-bit Apple II models. Accelerator cards for
8-bit machines generally use a 65C02 (some of which might be using an
R65C02), but I imagine there were early ones that had a 6502.

If you are writing a program which depends on the R65C02 instructions,
you should definitely include code to test the CPU type (6502, 65C02,
R65C02 or 65802/65816) before executing any instructions specific to the
R65C02. There was a routine in Eyes & Lichty which detected most of
these, and I worked out an extended version which identified all four
major types (I'd have to do a bit of hunting to find it, or reconstruct
it).

[David Empson]

David Empson <dem...@actrix.gen.nz> wrote:

> If you are writing a program which depends on the R65C02 instructions,
> you should definitely include code to test the CPU type (6502, 65C02,
> R65C02 or 65802/65816) before executing any instructions specific to the
> R65C02. There was a routine in Eyes & Lichty which detected most of
> these, and I worked out an extended version which identified all four
> major types (I'd have to do a bit of hunting to find it, or reconstruct
> it).

I've managed to locate the original article I posted in October 1994
with this detection routine (this required a fair amount of searching on
my IIgs). Here is the text of my earlier article, with a little editing
for tidiness.

I've had a request for a revised version of the routine to detect the
processor, so that it can identify a Rockwell R65C02.

Here is the routine I've come up with. This routine has an additional
benefit: it will correctly detect a 65802/65816 if the chip is in 8-bit
native mode (the previous routine would incorrectly identify it as a
65C02). Neither routine will work properly if the 65802/65816 is in
native mode with the M or X bits clear (i.e. 16-bit registers).

0320- A0 00 LDY #$00
0322- F8 SED
0323- A9 99 LDA #$99
0325- 18 CLC
0326- 69 01 ADC #$01
0328- D8 CLD
0329- D0 15 BMI $0340 ; 6502: N flag not affected by decimal add
032B- A0 03 LDY #$03
032D- A2 00 LDX #$00
032F- BB TYX ; 65802 instruction, NOP on all 65C02s
0330- D0 0E BNE $0340 ; Branch only on 65802/816
0332- A6 EA LDX $EA
0334- 88 DEY
0335- 84 EA STY $EA
0337- 17 EA RMB1 $EA ; Rockwell R65C02 instruction
0339- C4 EA CPY $EA ; Location $EA unaffected on other 65C02
033B- 86 EA STX $EA
033D- D0 01 BNE $0340 ; Branch only on Rockwell R65C02 (test CPY)
033F- 88 DEY
0340- 84 00 STY $00
0342- 60 RTS

I've included comments to show the general logic. The routine first
tests for a 6502 using the same trick as before: relying on the negative
flag not being affected by an add in decimal mode. This only happens on
a 6502.

The next part of the code checks for a 65802 or 65816 by seeing if the
TYX instruction is implemented (transfer Y to X). On a 65C02 (both
types), this is an undefined opcode, which will behave as a NOP. On the
65C02, the Z flag will still be set from the LDX #$00 instruction. On
the 65802/65816, the Z flag will be clear because the TYX instruction
set the X register to 3 (the contents of Y). The branch only occurs on
the 65802/65816.

The third part of the code tests for a Rockwell R65C02 by seeing if the
special zero page bit manipulation instructions are present. The R65C02
has 32 extra opcodes. The instructions are:

RMBn zp Reset Memory Bit n in zero page location (8 opcodes)
SMBn zp Set Memory Bit n in zero page location (8 opcodes)
BBRn zp,dest Branch if bit n reset in zero page location (8 opcodes)
BBSn zp,dest Branch if bit n set in zero page location (8 opcodes)

The opcodes are:

$07, $17, $27, $37, $47, $57, $67, $77 (RMBn zp)
$87, $97, $A7, $B7, $C7, $D7, $E7, $F7 (SMBn zp)
$0F, $1F, $2F, $3F, $4F, $5F, $6F, $7F (BBRn zp,dest)
$8F, $9F, $AF, $BF, $CF, $DF, $EF, $FF (BBSn zp,dest)

The code saves the contents of zero page location $EA, sets it to 2,
then tries to use the RMB1 instruction to clear bit 1 of the location.

On a Rockwell R65C02, this will work, and location $EA will now contain
zero, so the following CPY sees that the location has changed.

On any other 65C02, the $17 opcode is undefined, so acts as a NOP. The
operand ($EA) is then executed as an instrution. $EA is the opcode for
NOP, so nothing happens. Location $EA still contains $02, so the CPY
sees that the location is the same.

The following STX is used to restore the original contents of location
$EA. It doesn't affect the flags. The following BNE tests the result
of the CPY. If the branch occurs, we have a Rockwell R65C02. If not,
we have a standard 65C02.

So, after calling this routine, location 0 (and the acummulator) contain
one of the following values:

0 6502
1 Standard 65C02
2 Rockwell R65C02
3 65802 or 65816

Incidentally, I found that a IIe clone I have here contains a Rockwell
R65C02, so I've tested this routine on all four types of processor
(except the 65802, but I have tested it on the 65816).

Here is a BASIC subroutine to implement the above routine.

6000 REM IDENTIFY THE PROCESSOR
6010 I = 800
6020 READ J: IF J < 0 THEN GOTO 6040
6030 POKE I,J: I = I + 1: GOTO 6020
6040 CALL 800
6050 CPU = PEEK(0): REM 0 = 6502, 1 = 65C02, 2 = R65C02, 3 = 65802/816
6060 RETURN
6070 DATA 160,0,248,169,153,24,105,1,216,48,21,160,3,162,0,187,208,14
6080 DATA 166,234,136,132,234,23,234,196,234,134,234,208,1,136,132,0
6090 DATA 96,-1

Share and enjoy!

[Wyatt Wong]

Found 2 typos:

1. The opcode in address $329 should be 30 for BMI instead of D0.

0329- 30 15 BMI $0340 ; 6502: N flag not affected by decimal add

2. In the BASIC Program, line 6060 should be END instead of RETURN. Since there is NO GOSUB statement, the original line 6060 RETURN will generate an error.

[martindo...@gmail.com]

On Tuesday, May 9, 2023 at 12:47:06 PM UTC-4, Wyatt Wong wrote:
> On Sunday, 3 December 2000 at 20:12:04 UTC+8, David Empson wrote:

[snip]

> > Here is a BASIC subroutine to implement the above routine.
> > 6000 REM IDENTIFY THE PROCESSOR

[snip]
> > 6060 RETURN
[snip]

>
> 2. In the BASIC Program, line 6060 should be END instead of RETURN. Since there is NO GOSUB statement, the original line 6060 RETURN will generate an error.

Wyatt, I think David's BASIC code is OK because it's presented as a subroutine and is not intended to run as a stand-alone program. I agree that if you want to exercise the code stand-alone, you would need to either change RETURN to END, or add a line on the front like 10 GOSUB 6000 : END

[Wyatt Wong]

It is ***YOUR*** assumption that David's BASIC code is presented as a subroutine. But It does NOT mean that EVERYONE who read his message will get the SAME impression at all.

I simply mentioned that changing line "6060 RETURN" into "6060 END" will NOT generate error when execute the code. For those who incorporate David's code as part of their BASIC program, they can simply ignore what I suggest.

[Oliver Schmidt]

Hi Wyatt,

>It is ***YOUR*** assumption that David's BASIC code is presented as a subro=
>utine. But It does NOT mean that EVERYONE who read his message will get th=
>e SAME impression at all.

Certainly not! It is solely ******YOUR****** communication style that
causes problems - not only here, but also on FB...

The posting in question is titled 'Routine...' and consistently uses
the term 'routine', not 'program' all over the place.

And it says:

> So, after calling this routine, location 0 (and the acummulator) contain
> one of the following values:
> 0 6502
> 1 Standard 65C02
> 2 Rockwell R65C02
> 3 65802 or 65816

So it uses the term 'calling', not 'running'. Apart from that: What
sense is in a standalone program, that doesn't print its findings?

And finally it literally says:

> Here is a BASIC subroutine to implement the above routine.
> 6000 REM IDENTIFY THE PROCESSOR

> 6010 I = 800
> 6020 READ J: IF J < 0 THEN GOTO 6040
> 6030 POKE I,J: I = I + 1: GOTO 6020
> 6040 CALL 800
> 6050 CPU = PEEK(0): REM 0 = 6502, 1 = 65C02, 2 = R65C02, 3 = 65802/816
> 6060 RETURN

So it's a ******subroutine******, you see it? Just 7 lines above the
RETURN.

>I simply mentioned that changing line "6060 RETURN" into "6060 END" will NO=
>T generate error when execute the code. For those who incorporate David's c=

>ode as part of their BASIC program, they can simply ignore what I suggest.

Cartainly not! You didn't "simply mention" or "suggest" anything. You
classified the RETURN as "typo" and wrote, it "should" be an END
instead.

I strongly suggest that you take a step back from creating alternative
realities.

Thanks,
Oliver

[Michael 'AppleWin Debugger Dev']

On Thursday, May 25, 2023 at 12:25:28 PM UTC-7, Wyatt Wong wrote:

> It is ***YOUR*** assumption that David's BASIC code is presented as a subroutine.

Wyatt, you WAY OFF BASE on this for three reasons:

1. First, David **explicitly** stated it was a sub-routine. (Emphasis added):
> Here is a BASIC **subroutine**

2. The LARGE line numbers, 6000 - 6090 are a BASIC idiom that it is sub-routine.

3. The RETURN on line 6060 was your THIRD clue that it was a sub-routine.

Ignoring the evidence doesn't magically make it go away.

> But It does NOT mean that EVERYONE who read his message will get the SAME impression at all.

Yes. Yes, it does.

People post code snippets with the implicit understanding that any half-competent programmer can figure out how to use them. If you need help with BASIC then ASK -- people are more then willing to help beginners out. But flaming a 20+ year old post because YOU are still a **naïve and beginner Applesoft programmer** just makes you look like a complete tool / utter fool.

i.e. Next time lose the fucking attitude.

Michael