identifying enhanced IIe

[Mark Lemmert]

Does anyone know if the following is a valid test to determine whether an Apple IIe is enhanced or unenhanced? It seem like it should work, but I want to double check.

I know that it can be determined by looking at the motherboard but I’m curious if this would work as alternative to opening up the case.

Thanks!



CALL -151
6000: 90 00 90


6000L

then observe whether the monitor list for 6000 shows ???? or the STZ 65C02 opcode.

[Antoine Vignau]

90 is the opcode BCC. 6502 or 65c02 both handle it.
We had a discussion on the Facebook about that and a simple code with the decimal mode allows to differentiate both processors.

Check there,
Antoine

[qkumba]

> 90 is the opcode BCC. 6502 or 65c02 both handle it.
> We had a discussion on the Facebook about that and a simple code with the decimal mode allows to differentiate both processors.

If it's a LDA #$20/SBC #$0F style, then it doesn't work for the WDC chips.

Try this instead: 18 80 01 38 90 xx
which on 6502 looks like
CLC
NOP 01
SEC
BCC x65C02
;branch is not taken on 6502.

on 65C02 looks like
CLC
BRA +
SEC
+BCC x65C02

branch is taken on 65C02.

[D Finnigan]

Mark Lemmert wrote:
> Does anyone know if the following is a valid test to determine whether an
> Apple IIe is enhanced or unenhanced? It seem like it should work, but I
> want to double check.

Here is an oldie but a goodie:
http://macgui.com/usenet/?group=7&id=9234#msg

Also, how strict is your definition of enhanced IIe? Do you want the royal
flush: 65C02, 1985 firmware, and updated video ROM? Or just the 65C02?

--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[Michael Pohoreski]

On Monday, August 8, 2016 at 10:20:40 AM UTC-7, D Finnigan wrote:
> Also, how strict is your definition of enhanced IIe? Do you want the royal
> flush: 65C02, 1985 firmware, and updated video ROM? Or just the 65C02?

/Oblg.

http://i1.kym-cdn.com/entries/icons/original/000/006/759/both.png

[Mark Lemmert]

On Sunday, August 7, 2016 at 10:35:15 PM UTC-5, Antoine Vignau wrote:
> 90 is the opcode BCC. 6502 or 65c02 both handle it.

Oops; I meant $9C

> We had a discussion on the Facebook about that and a simple code with the decimal mode allows to differentiate both processors.
>
> Check there,
> Antoine

Thanks!

[Mark Lemmert]

Thanks for the suggestions everyone!

Mark

[John Brooks]

On Monday, August 8, 2016 at 6:34:09 PM UTC-7, Mark Lemmert wrote:
> Thanks for the suggestions everyone!
>
> Mark

I've been out of town and late to the discussion, but here are some more ideas:


use 1-byte undoc 6502 nop:

:a9 00 1a

followed by BNE Got65c02 or BEQ Got6502. Returns A=0 for 6502. A=1 for 65c02/65816.


Or combine with a 2-byte undoc 6502/65c02 dop for 65816 detection:

:a9 00 1a c2 80

followed by BMI Got65816 or BPL Not65816, then BNE/BEQ as above for 6502/65c02 determination.


If you don't want to use undocumented 6502 opcodes or care more about the ROM version, you can check the version ID2 byte at $FBBF as described in the IIGS Firmware ref Appendix B to detect if the ROM is Enhanced IIe, IIGS, IIc, or IIc Plus:

:ad bf fb e9 01 69 03

followed by BCS Got65c02 or BCC Got6502. You can save a byte by using a 65c02 DEC A (6502 undoc nop):

:ad bf fb 3a 69 03

At Got65c02 if you want to detect 65816 vs 65c02 (and acc != 0), you can do this:

:7b

followed by BEQ Got65816 or BNE Not65816.


Hope that helps,
-JB
Twitter:@JBrooksBSI

[Mark Lemmert]

Hi Peter,

From the monitor on a real Apple IIe and in AppleWIN (6502 mode) I tried typing in 6000: 18 80 01 38 90 A0 and get the following result:

6000L

CLC
???
ORA ($38, X)
BCC 5FA6

Does that make any sense? It seems not to recognize the $80 as an opcode.

Thanks.

Mark

[Steve Nickolas]

On Thu, 3 Nov 2016, Mark Lemmert wrote:

> Hi Peter,
>
> From the monitor on a real Apple IIe and in AppleWIN (6502 mode) I tried typing in 6000: 18 80 01 38 90 A0 and get the following result:
>
> 6000L
>
> CLC
> ???
> ORA ($38, X)
> BCC 5FA6
>
> Does that make any sense? It seems not to recognize the $80 as an opcode.
>
> Thanks.
>
> Mark

The disassembler isn't updated for 65SC02 operations like the //c one is.

-uso.

[6502wo...@gmail.com]

Ah, got it. Thanks!

[roger....@gmail.com]

On Sunday, August 7, 2016 at 6:27:58 PM UTC-5, Mark Lemmert wrote:
> Does anyone know if the following is a valid test to determine whether an Apple IIe is enhanced or unenhanced?

Splitting hairs, in a word, no.

Most of this thread has been around 65C02 identification.

There should be nothing wrong with using a 65C02 in an unenhanced //e.

"By the book", identifying an enhanced //e is done by checking the ROMs:
$FBB3 = $06 (//e or later)
$FBC0 = $E0 (//e type; //c is zero; IIGS is also $E0)

[roger....@gmail.com]

On Sunday, November 6, 2016 at 11:44:25 AM UTC-6, roger....@gmail.com wrote:
> "By the book", identifying an enhanced //e is done by checking the ROMs:
> $FBB3 = $06 (//e or later)
> $FBC0 = $E0 (//e type; //c is zero; IIGS is also $E0)

Having just remembered the //e Extended Debug Monitor ($FBC0 = $E1), the lazier way would be to check:

$FBB3 = $06 (//e or later)

$FBC0 <> $EA (not an original //e)

[6502wo...@gmail.com]

Thanks Roger.

Is the term original //e synonymous with unenhanced //e ?


I tried this out in AppleWIN using the "Apple IIe" and "Enhanced Apple IIe" settings and got the following results:

"Apple IIe"

FBB3 = $06
FBC0 = $EA


"Enhanced Apple IIe"

FBB3 = $06
FBC0 = $E0


If I understand correctly, this looks like it is what is expected. Correct?

> There should be nothing wrong with using a 65C02 in an unenhanced //e.

Just to make sure I understand the difference between unenhanced and enhanced, does this refer to a scenario only the 65C02 chip was installed and the 3 ROM chips in the enhanced IIe upgrade kit were not installed?


For context, here is the information I've read that my inferences are based on. Thanks for your help!


http://apple2history.org/history/ah07/#07
This version of the Apple IIe was introduced in March of 1985. It involved changes to make the IIe more closely compatible with The Apple IIc and II Plus. The upgrade kit (for previous IIe owners) consisted of four chips that were swapped in the motherboard: The 65c02 processor, with more assembly language opcodes, replaced the 6502; two more chips with Applesoft and Monitor ROM changes; and the fourth chip was a character generator ROM that included graphics characters (first introduced on the IIc) called “MouseText“. The Enhanced IIe ROM changes fixed most of the known problems with the IIe 80-column firmware, and made it possible to enter Applesoft and Monitor commands in lower-case. The older 80-column routines were slower than most software developers wanted; they disabled interrupts for too long a time. Also, there were problems in making Applesoft work properly with the 80-column routines. These problems were solved with the newer ROMs.

[D Finnigan]

6502workshop wrote:
> On Sunday, November 6, 2016 at 12:02:10 PM UTC-6, roger....@gmail.com
> wrote:
>> On Sunday, November 6, 2016 at 11:44:25 AM UTC-6, roger....@gmail.com
>> wrote:
>> > "By the book", identifying an enhanced //e is done by checking the
>> > ROMs:
>> > $FBB3 = $06 (//e or later)
>> > $FBC0 = $E0 (//e type; //c is zero; IIGS is also $E0)
>>
>> Having just remembered the //e Extended Debug Monitor ($FBC0 = $E1), the
>> lazier way would be to check:
>> $FBB3 = $06 (//e or later)
>> $FBC0 <> $EA (not an original //e)

See the Apple II technote referred to below for identification routines and
check bytes.

>
>
> Thanks Roger.
>
> Is the term original //e synonymous with unenhanced //e ?

Yes. As well as the term "Standard Apple IIe"

>
>
> I tried this out in AppleWIN using the "Apple IIe" and "Enhanced Apple
> IIe"
> settings and got the following results:
>

[...]

>
>
> If I understand correctly, this looks like it is what is expected.
> Correct?

No need to mess around and waste time with emulators. You can trust and
reply upon the official Apple Computer documentation, specifically the tech
notes that explain all that you're asking about.

Miscellaneous #7
Apple II Family Identification
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.07.html

Also:

Miscellaneous #2
Apple II Family Identification Routines 2.2
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.02.html

>
>
>> There should be nothing wrong with using a 65C02 in an unenhanced //e.

Correct. Because everyone who has ever used a Transwarp in the IIe has used
a 65C02 in that machine.

>
> Just to make sure I understand the difference between unenhanced and
> enhanced, does this refer to a scenario only the 65C02 chip was installed
> and the 3 ROM chips in the enhanced IIe upgrade kit were not installed?

> http://apple2history.org/history/ah07/#07
> This version of the Apple IIe was introduced in March of 1985. It involved
> changes to make the IIe more closely compatible with The Apple IIc and II
> Plus.

Again, don't refer to emulators or 2nd party sources for this information.
Don't guess around.

The official Apple Computer documentation defines what is an Enhanced Apple
IIe.

See the "Apple IIe Technical Reference Manual," page xxix for a definition.

The enhanced Apple IIe includes the following changes from the original
Apple IIe:

- The 65C02 microprocessor, which is a new version of the 6502
microprocessor found in the original Apple IIe. The 65C02 uses less
power, has 27 new opcodes, and runs at the same speed as the 6502.
(See Chapter 7 and Appendix A.)

- A new video ROM containing the same MouseText characters found in
the Apple IIe. (See Chapter 2.)

- New Monitor ROMs (the CD and EF ROMs) containing the enhanced
Apple IIe firmware. (See Chapter 5.)

- The identification byte at $FBC0 has been changed. In the original
Apple IIe it was $EA (decimal 234), in the enhanced Apple IIe it is $E0
(decimal 224).



For further reading, look for the manual called "About your Enhanced Apple
IIe: Programmer's Guide"
It looks like this: http://macgui.com/gallery/showphoto.php?pic_id=1335

That's my copy, but I don't have a PDF. There may be some other Apple IIe
manuals from 1985 and later that also include the definition of what is an
Enhanced Apple IIe.

There's also this manual, "Apple IIe Guide To The New Features"
http://macgui.com/gallery/showphoto.php?pic_id=1341#img
(Again, my copy, no PDF)

[roger....@gmail.com]

On Monday, November 7, 2016 at 2:27:36 PM UTC-6, D Finnigan wrote:
> No need to mess around and waste time with emulators.

In general I disagree with this statement. Emulators are very fast and convenient. I cross assemble so often just copy and paste to get the code over. (Historical note: the first Microsoft BASIC was developed on an emulator.)

Emulators are the only practical way for many people to run some things.

In the end, yes, the code should be run on the real thing (emulators are unlikely to be perfect).

> You can trust and
> reply upon the official Apple Computer documentation, specifically the tech
> notes that explain all that you're asking about.

ROFL...were you programming Apple IIs when they were being produced? It took me awhile to figure out that the interrupt enable bit in the SSC manual is described incorrectly.

The Double Hires Tech Note is the worst piece ever written on the subject.

However it is vital to point out that the Tech Notes supersede over all previous Apple doco. (Tech Notes that are corrections to published books are the most obvious example.)

> Apple II Family Identification Routines 2.2
> http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.02.html

Anyone who needs to identify a IIe card is either doing something extremely special or totally wrong.

The only Apple document I've seen mentioning the //e Extended Debug Monitor ROM ($FBCO = $E1) describes its features.

Would also be wary of Apple code samples. I need to write up the horrors of the IIc Plus accelerator code.

====

The code I use to check for a 65C02 is based on a ProDOS Tech Note:

lda #$99 ; set N
clc
sed
adc #1 ; A = 0
cld
bpl a65C02 ; N set correctly
bmi a6502 ; N unchanged

====

I should have pointed out that in general there is little difference between an enhanced //e and the //c. (A IIGS is a lot like an enhanced //e...depending how a serial port is used and the paddles are read.)

If the intent is to check a machine for a 65C02 and mousetext, $FBB3 = 6 and $FBC0 <> $EA is reasonable. (Checking for 128K is another matter.)

The //c Technical References are quite useful because they describe the differences between the members of the Apple II family.

[Bill Buckels]

<roger....@gmail.com> wrote:
>The Double Hires Tech Note is the worst piece ever written on the subject.

Seconded.

File Type Notes for graphics are not my favourite either and incomplete. If
this is something that needs doing then perhaps it should be done properly.

My MSDN subscriptions etc. from Microsoft in the early 90's for Windows
development were almost free, as was my support from Microsoft in the 80's
for MS-DOS development. APDA was a ripoff.

Bill

[Steve Nickolas]

I always saw post-][ Apple as more closed-off than Microsoft.

In later days, Microsoft tools became less and less expensive, and the GNU
tools, albeit inferior, came out freely available, which on Windows
spelled doom for expensive compilers. MS now has a lot of the API
documentation online for free - and that, even if you're not using a
Microsoft compiler. I used it as a reference when working on my latest
emulator.

There's still nothing comparable to MinGW for GS/OS.

-uso.

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
> There's still nothing comparable to MinGW for GS/OS.

Prolly never will be... I love my MinGW... and my cc65... etc.

Man are we spoiled or what :)

Bill

[Steve Nickolas]

On Thu, 10 Nov 2016, Bill Buckels wrote:

> "Steve Nickolas" <usot...@buric.co> wrote:
>> There's still nothing comparable to MinGW for GS/OS.
>
> Prolly never will be... I love my MinGW... and my cc65... etc.

If I were to try to get a C compiler up for a IIgs target, I'd use the
cc65 tools for it (ca65, ld65), as they do the job well enough and are
65816-aware.

GCC...unfortunately not an option because the 65816 doesn't have a flat
memory model (same reason it can't be done on 8088 or 286).

-uso.