On Wednesday, 10 May 2023 at 02:43:21 UTC+8, martindo...@gmail.com wrote:
> 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

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.

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

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

On Sunday, 3 December 2000 at 20:12:04 UTC+8, David Empson wrote:
> 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!

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.

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