NORMFAST - set normal or fast speed on the IIGS, //c+ and hopefully FASTChip

[r***@gmail.com]

I would appreciate if someone can test this with a FastChip.

NORMFAST sets normal (1Mhz) or fast speed on the IIGS, //c+, or hopefully on an Apple II with a FASTChip.
(Not yet tested with a FASTChip. The source is based on the documentation.)

This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.

The other expected use is to set the speed in a program.

If the Apple is an original, ][ Plus, or //e, a FASTChip is assumed.
It is *probably* harmless if there is no FASTChip.
Does nothing on a //c that is not a //c+.

BRUN NORMFAST or CALL 768 for normal (1Mhz) speed.
CALL 772 for fast speed.
NORMFAST's fast value for the FASTChip is 40 ($28), 16Mhz. 9 is 1Mhz.
FASTChip users should POKE the desired speed value at 773 before CALL 772.

NORMFAST is position independent and can be loaded most anywhere in the first 48K of memory.

=====

Boot your favorite emulator in DOS 3.3 or BASIC.SYSTEM. Copy and paste the following.

CALL -151
300:A9 9 D0 2 A9 28 A2 1 AE B3 FB E0 6
:D0 D AE C0 FB F0 3C 48 38 20 1F FE 68
:90 22 A2 6A 8 78 8E 6A C0 8E 6A C0 8E
:6A C0 8E 6A C0 8E 6B C0 2C 6B C0 10 8
:8D 6D C0 A2 A6 8E 6A C0 28 60 C9 9 F0
:1 18 AD 36 C0 29 7F B0 2 9 80 8D 36
:C0 60 AE BF FB E0 5 D0 20 C9 9 F0 3
:A9 1 2C A9 2 A6 0 8 78 48 A9 4 48 20
:C7 C7 20 C7 C7 A9 3 48 20 C7 C7 28 86
:0 60
3D0G
BSAVE NORMFAST,A$300,L$78

=====

The source is seems short enough to include, so here it is.

;;; Set IIGS, //c+ or FASTChip //e speed to normal or fast
;
; NORMFAST Release 1 2017-08-25
;
; Sets normal (1Mhz) or fast speed on the IIGS, //c+, or
; hopefully on an Apple II with a FASTChip.
; (Not yet tested with a FASTChip. The source is based on
; the documentation.)
;
; This is primarily for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; If the Apple is an original, ][ Plus, or //e, a FASTChip
; is assumed.
; It is *probably* harmless if there is no FASTChip.
; Does nothing on a //c that is not a //c+.
;
; BRUN NORMFAST or CALL 768 for normal (1Mhz) speed.
; CALL 772 for fast speed.
; NORMFAST's fast value for the FASTChip is
; 40 ($28), 16Mhz. 9 is 1Mhz.
; FASTChip users should POKE the desired speed value at 773
; before CALL 772.
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.6502 ; a 65C02 isn't required

; addresses are lowercase, constant values are in CAPS

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036 ; bit 7: fast mode

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_16MHZ .equ 40 ; maximum

.org $300

; normal speed
lda #FC_1MHZ
bne chkiie ; always
; an instruction to hide the FASTChip speed value is not
; used here in case some future value is $C0, hitting an
; I/O location

; entry for fast speed
; FASTChip users should set to what they want
lda #FC_16MHZ
chkiie
ldx #1 ; our release number
ldx romid
cpx #ROMID_IIECOMPAT
bne fc ; not a //e, assume a FASTChip

ldx romid_ec
beq iic ; a //c

pha
sec
jsr idroutine
pla
bcc gs ; a IIGS

; set FASTChip speed value in accumulator

fc
ldx #FC_UNLOCK
php
sei ; timing sensitive
stx fc_lock
stx fc_lock
stx fc_lock
stx fc_lock
stx fc_enable
bit fc_enable
bpl fcoff ; FASTChip not enabled
sta fc_speed
ldx #FC_LOCK
stx fc_lock
fcoff
plp ; restore interrupt state
rts

; set IIGS speed, accumulator contains FASTChip speed

gs cmp #FC_1MHZ
beq gsnorm ; carry is set for normal
clc
gsnorm
lda gsspeed
and #$7F ; normal
bcs gsset
ora #$80 ; fast
gsset
sta gsspeed
rts

; set //c+ speed, accumulator contains FASTChip speed

iic
ldx romid_c
cpx #ROMID_CPLUS
bne iicrts ; not a //c+

cmp #FC_1MHZ
beq iicnorm
lda #CGGA_ENABLE
.byte $2C ; BIT <ABSOLUTE>, hide next lda #
iicnorm
lda #CGGA_DISABLE

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
iicrts
rts

[Antoine Vignau]

it should work on a FASTChip //e, the logic is here. I'll try to enter the FC dedicated code and come back to you later,

av

[Michael J. Mahon]

Post by r***@gmail.com
I would appreciate if someone can test this with a FastChip.
NORMFAST sets normal (1Mhz) or fast speed on the IIGS, //c+, or hopefully
on an Apple II with a FASTChip.
(Not yet tested with a FASTChip. The source is based on the documentation.)
This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.
The other expected use is to set the speed in a program.
If the Apple is an original, ][ Plus, or //e, a FASTChip is assumed.
It is *probably* harmless if there is no FASTChip.
Does nothing on a //c that is not a //c+.
BRUN NORMFAST or CALL 768 for normal (1Mhz) speed.
CALL 772 for fast speed.
NORMFAST's fast value for the FASTChip is 40 ($28), 16Mhz. 9 is 1Mhz.
FASTChip users should POKE the desired speed value at 773 before CALL 772.
NORMFAST is position independent and can be loaded most anywhere in the
first 48K of memory.
=====
Boot your favorite emulator in DOS 3.3 or BASIC.SYSTEM. Copy and paste the following.
CALL -151
300:A9 9 D0 2 A9 28 A2 1 AE B3 FB E0 6
:D0 D AE C0 FB F0 3C 48 38 20 1F FE 68
:90 22 A2 6A 8 78 8E 6A C0 8E 6A C0 8E
:6A C0 8E 6A C0 8E 6B C0 2C 6B C0 10 8
:8D 6D C0 A2 A6 8E 6A C0 28 60 C9 9 F0
:1 18 AD 36 C0 29 7F B0 2 9 80 8D 36
:C0 60 AE BF FB E0 5 D0 20 C9 9 F0 3
:A9 1 2C A9 2 A6 0 8 78 48 A9 4 48 20
:C7 C7 20 C7 C7 A9 3 48 20 C7 C7 28 86
:0 60
3D0G
BSAVE NORMFAST,A$300,L$78
=====
The source is seems short enough to include, so here it is.
;;; Set IIGS, //c+ or FASTChip //e speed to normal or fast
;
; NORMFAST Release 1 2017-08-25
;
; Sets normal (1Mhz) or fast speed on the IIGS, //c+, or
; hopefully on an Apple II with a FASTChip.
; (Not yet tested with a FASTChip. The source is based on
; the documentation.)
;
; This is primarily for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; If the Apple is an original, ][ Plus, or //e, a FASTChip
; is assumed.
; It is *probably* harmless if there is no FASTChip.
; Does nothing on a //c that is not a //c+.
;
; BRUN NORMFAST or CALL 768 for normal (1Mhz) speed.
; CALL 772 for fast speed.
; NORMFAST's fast value for the FASTChip is
; 40 ($28), 16Mhz. 9 is 1Mhz.
; FASTChip users should POKE the desired speed value at 773
; before CALL 772.
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.
.6502 ; a 65C02 isn't required
; addresses are lowercase, constant values are in CAPS
romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5
; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036 ; bit 7: fast mode
; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change
; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_16MHZ .equ 40 ; maximum
.org $300
; normal speed
lda #FC_1MHZ
bne chkiie ; always
; an instruction to hide the FASTChip speed value is not
; used here in case some future value is $C0, hitting an
; I/O location
; entry for fast speed
; FASTChip users should set to what they want
lda #FC_16MHZ
chkiie
ldx #1 ; our release number
ldx romid
cpx #ROMID_IIECOMPAT
bne fc ; not a //e, assume a FASTChip
ldx romid_ec
beq iic ; a //c
pha
sec
jsr idroutine
pla
bcc gs ; a IIGS
; set FASTChip speed value in accumulator
fc
ldx #FC_UNLOCK
php
sei ; timing sensitive
stx fc_lock
stx fc_lock
stx fc_lock
stx fc_lock
stx fc_enable
bit fc_enable
bpl fcoff ; FASTChip not enabled
sta fc_speed
ldx #FC_LOCK
stx fc_lock
fcoff
plp ; restore interrupt state
rts
; set IIGS speed, accumulator contains FASTChip speed
gs cmp #FC_1MHZ
beq gsnorm ; carry is set for normal
clc
gsnorm
lda gsspeed
and #$7F ; normal
bcs gsset
ora #$80 ; fast
gsset
sta gsspeed
rts
; set //c+ speed, accumulator contains FASTChip speed
iic
ldx romid_c
cpx #ROMID_CPLUS
bne iicrts ; not a //c+
cmp #FC_1MHZ
beq iicnorm
lda #CGGA_ENABLE
.byte $2C ; BIT <ABSOLUTE>, hide next lda #
iicnorm
lda #CGGA_DISABLE
; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK
lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga
jsr cgga ; disable/enable
lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga
plp ; restore interrupt state
stx $0
iicrts
rts

Roger, the IIc+ is functionally identical to a 4MHz Zip Chip, which is
likely to be found in a IIc, //e, or even a ][ or ][+. The chip's internal
timer can be used to determine whether it is a 4MHz or 8MHz model. FWIW,
the Rocket Chip is a Zip Chip clone which came in (IIRC) 5MHz and 10MHz
model.

The Zip Chip, et al., can be identified by the method described in its
documentation, and the speed control method is also described there.

[r***@gmail.com]

Post by Michael J. Mahon
the IIc+ is functionally identical to a 4MHz Zip Chip,

The //c+ and Zip are certainly related. There seem to be differences, and Apple's not entirely accurate IIc Technical Reference manual may have confused me. (It refers to two registers.)

Post by Michael J. Mahon
which is likely to be found in a IIc, //e, or even a ][ or ][+.

True. It's also prudent to ask how many working Zip Chips are still in use.

I was on the verge of posting NORMFAST when I read the FASTChip was in the a2heaven shop.

Post by Michael J. Mahon
... the Rocket Chip is a Zip Chip clone ...

Oh yeah, I remember when the Rocket Chip was announced. They're certainly collectable now!

Post by Michael J. Mahon
The Zip Chip, et al., can be identified by the method described in its
documentation, and the speed control method is also described there.

I'll take a look.

The design goals for the first NORMFAST are:

* Easy to use
* Must fit in page 3 (it being about half a page now bugs me)
* Position independent

"Fast" for variable rate accelerators such as the Zip Chip and FASTChip complicate "eazy to use."

The Zip tools disk already has tools to disable or set the speed, though they are not lightweight.

It may not be worth the bytes to check for a specific accelerator.

[Michael J. Mahon]

Post by r***@gmail.com

Post by Michael J. Mahon
the IIc+ is functionally identical to a 4MHz Zip Chip,

The //c+ and Zip are certainly related. There seem to be differences, and
Apple's not entirely accurate IIc Technical Reference manual may have
confused me. (It refers to two registers.)

Post by Michael J. Mahon
which is likely to be found in a IIc, //e, or even a ][ or ][+.

True. It's also prudent to ask how many working Zip Chips are still in use.
I was on the verge of posting NORMFAST when I read the FASTChip was in the a2heaven shop.

Post by Michael J. Mahon
... the Rocket Chip is a Zip Chip clone ...

Oh yeah, I remember when the Rocket Chip was announced. They're certainly collectable now!

Post by Michael J. Mahon
The Zip Chip, et al., can be identified by the method described in its
documentation, and the speed control method is also described there.

I'll take a look.
* Easy to use
* Must fit in page 3 (it being about half a page now bugs me)
* Position independent
"Fast" for variable rate accelerators such as the Zip Chip and FASTChip
complicate "eazy to use."
The Zip tools disk already has tools to disable or set the speed, though
they are not lightweight.
It may not be worth the bytes to check for a specific accelerator.

There are lots of working Zip Chips, particularly among the cadre of Apple
II enthusiasts today.

I have not found any differences between the Zip Chip and the IIc+, for
which Apple licensed the Zip Chip design. If you know of any please let me
know!

[r***@gmail.com]

There are lots of working Zip Chips, particularly among the cadre of Apple II enthusiasts today.

Hopefully that's fixed now, but I am not happy with the Zip Chip overlaying known I/O locations.

I have not found any differences between the Zip Chip and the IIc+, for
which Apple licensed the Zip Chip design. If you know of any please let me
know!

Okay, I'll have spend some time.

After reviewing the //c+ CCGA code I determined that I will need to write about "The Horror Of The IIc Plus Accelerator Code."

[MG]

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e

Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s

MG

[Antoine Vignau]

Note: I've tested the fastchip part only, ie. I've only entered its dedicated code.

Code from v1 works fine but it seta the high speed to the one defined in the control panel.

Code from v2 seems to do nothing. I do not have my notes handy, I'll double check later. At least, it does not crash but does not seem to disable/enable the beast. I may be wrong, further testing is needed, the one I've just did is weak but it is 4:00AM here.

Antoine

[Antoine Vignau]

still thinking about code v2 w/o having read the code but...
lsr
sta $c06a,x

X is 0 or 1 but A is 6A/2. Is A an authorized value?

av

[r***@gmail.com]

Post by Antoine Vignau
still thinking about code v2 w/o having read the code but...
lsr
sta $c06a,x
X is 0 or 1 but A is 6A/2. Is A an authorized value?

You may have noticed that the FASTChip and Zip Chip sources are almost the same. The values and addresses are different, but operations are the same.

The Zip documentation says:

Register How
Address Accessed Bit/Function

$C05A Write $A5 Locks the ZIP CHIP.
4 consecutive $5A write unlock
ZIP CHIP.
While unlocked any write other than $A5
or $5A will initiate an indefinite
syncronous sequence (disables ZIPCHIP).

$C05B Write Any hex byte written will enable
ZIPCHIP.

The apparently incorrect FASTChip documentation says:

Register How
Address Accessed Function

$C06A Write $A6 Locks FASTChip //e.
4 consecutive $6A writes unlock FASTChip //e.
While unlocked, any write other than $A6 or $6A
will initiate an indefinate syncronous sequence.
$C06B Write Any hex byte written will enable FASTChip //e

[r***@gmail.com]

Post by Antoine Vignau
Note: I've tested the fastchip part only, ie. I've only entered its dedicated code.
Code from v1 works fine but it seta the high speed to the one defined in the control panel.
Code from v2 seems to do nothing. I do not have my notes handy, I'll double check later. At least, it does not crash but does not seem to disable/enable the beast. I may be wrong, further testing is needed, the one I've just did is weak but it is 4:00AM here.

Hi Antoine,

Thank you for testing both releases.

Well that's what I get for not having a FASTChip.

My test case is quite simple:

10 FOR A=1 TO 5000:NEXT

This takes a little more than 5 seconds at 1Mhz.

It's just some free code, please get some sleep!

[r***@gmail.com]

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s

Ah, of course, how could the author of the MIG inspector avoid the accelerator code.

Just reading your comments indicates it's even worse than I thought. I'll have to look more closely later.

Glad I gave you an chance for some healthy self-promotion. :-)

[Antoine Vignau]

Oh cool, my test case was 300L, ahem
I tested again with yours: same duration, so something is wrong!

[r***@gmail.com]

Release 3 is based on Antoine Vignau's FASTChip testing. Thanks Antoine!

Thanks to Michael Mahon for mentioning that the //c+ functionally has a Zip Chip. Zip Chip testing would still be appreciated.

DO NOT RUN THIS ON NON-GS SYSTEMS USING ANNUCIATOR 1 OR ON A //C USING VERTICAL BLANK INTERRUPTS. Otherwise it's mostly harmless.

BRUN NORMFAST or CALL 768 to disable the accelerator.
CALL 771 to enable the accelerator.

NORMFAST is position independent and can be loaded most anywhere in the first 48K of memory.

Since the FASTChip is a current product, future NORMFAST releases may be necessary.

====

Boot DOS or start BASIC.SYSTEM in your favorite emulator and copy/paste the following.

CALL -151
300:A9 0 2C A9 1 A2 3 AE B3 FB E0 6 D0
:3D AE C0 FB F0 16 48 38 20 1F FE 68
:B0 30 4A AD 36 C0 29 7F 90 2 9 80 8D
:36 C0 60 AE BF FB E0 5 D0 1B 49 1 1A
:A6 0 8 78 48 A9 4 48 20 C7 C7 20 C7
:C7 A9 3 48 20 C7 C7 28 86 0 60 A0 9
:AA F0 2 A0 28 A9 6A 8 78 8D 6A C0 8D
:6A C0 8D 6A C0 8D 6A C0 8D 6B C0 2C
:6B C0 10 A 8C 6D C0 A9 A6 8D 6A C0 28
:60 A9 5A 8D 5A C0 8D 5A C0 8D 5A C0
:8D 5A C0 4A 9D 5A C0 A9 A5 8D 5A C0
:28 60
3D0G
BSAVE NORMFAST,A$300,L$8D

====

;;; Disable/enable IIGS, //c+, FASTChip, Zip Chip accelerator
;
; NORMFAST
; Release 3 2017-08-29 Change FASTChip partially back to
; release 1, which seems to work the way release 2 was
; intended?!
;
; Release 2 2017-08-27 change enable entry point, add Zip
; Chip, change setting FASTChip speed to disable/enable
;
; Release 1 2017-08-25 IIGS, //c+ and FASTChip
;
; DO NOT RUN THIS ON NON-GS SYSTEMS USING ANNUCIATOR 1
; OR ON A //C USING VERTICAL BLANK INTERRUPTS.
;
; Disables or enables the accelerator on the IIGS, //c+,
; FASTChip or Zip Chip.
;
; Does not check for a FASTChip or Zip Chip, just tries to
; disable/enable them. Setting the Zip Chip changes
; annuciator 1 (//c vertical blank enable).
;
; This is primarily for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; If the Apple is an original, ][ Plus, or //e, the
; FASTChip is set first. If it fails a Zip Chip is set.
; The Zip Chip registers used overlap annunciator 1.
; The Zip Chip registers overlaying the annunciators
; should already be known by Zip Chip users.
;
; BRUN NORMFAST or CALL 768 to disable the accelerator.
; CALL 771 to enable the accelerator.
; (Accelerators such as the FASTChip or Zip Chip can run
; slower than 1Mhz when enabled.)
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.65C02 ; when on a //c+

; addresses are lowercase, constant values are in CAPS

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036 ; bit 7: fast mode

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_ON .equ 40 ; doco says 16.6Mhz

; Zip Chip
zc_lock .equ $C05A
ZC_UNLOCK .equ $5A ; write 4 times
ZC_LOCK .equ $A5
zc_enable .equ $C05B

.org $300

; disable accelerator
lda #0 ; offset to disable Zip
.byte $2C ; BIT <ABSOLUTE>, hide next lda #

; enable accelerator
lda #1 ; offset to enable Zip

ldx #3 ; our release number
ldx romid
cpx #ROMID_IIECOMPAT
bne fc ; not a //e, try FASTChip

ldx romid_ec
beq iic ; //c family

pha
sec
jsr idroutine
pla
bcs fc ; not a IIGS, try FASTChip

; set IIGS speed

lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
rts

; Set //c+ speed. Uses the horrible firmware in case other
; code works "by the book."

iic
ldx romid_c
cpx #ROMID_CPLUS
bne fc ; not a //c+, try FASTChip

; change 0 and 1 to 2 and 1
eor #1
inc a ; 65C02

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
rts

; FASTChip set first because its registers do not overlap
; any known motherboard locations

fc
ldy #FC_1MHZ
tax ; set X for Zip
beq fcnorm
ldy #FC_ON ; enable set speed?
fcnorm
lda #FC_UNLOCK
php
sei ; timing sensitive
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
bit fc_enable
bpl zip ; FASTChip not enabled
sty fc_speed
lda #FC_LOCK
sta fc_lock
plp ; restore interrupt state
rts

; Zip Chip registers used here overlap annunciator 1 /
; //c vertical blank registers
; enter here with processor status on stack and interrupts
; disabled

zip
lda #ZC_UNLOCK
sta zc_lock
sta zc_lock
sta zc_lock
sta zc_lock
lsr ; not ZC_LOCK or ZC_UNLOCK
sta zc_lock,x ; disable/enable
lda #ZC_LOCK
sta zc_lock
plp ; restore interrupt state
rts

[Antoine Vignau]

Post by r***@gmail.com
Release 3 is based on Antoine Vignau's FASTChip testing. Thanks Antoine!

I took the time to read v0.01 of the manual and your code matches the FASTChip //e Programmer's Reference. I'll test on the real h/w too

Antoine

[MG]

Post by r***@gmail.com
Ah, of course, how could the author of the MIG inspector avoid the accelerator code.

Yeah, it seemed like the best place to start since there was at least some documentation in the Tech Ref. At some point I am going to tackle the 3.5" code, but after seeing the accelerator code, I'm a bit worried about what I might find in there.

Post by r***@gmail.com
Just reading your comments indicates it's even worse than I thought. I'll have to look more closely later.

It's pretty bad, it looks like it was written over the course of an hour or so and when the two functions most likely to be used worked, was shipped.

Post by r***@gmail.com
Glad I gave you an chance for some healthy self-promotion. :-)

Haha, and my first usenet post for like... 15 years.

MG

[r***@gmail.com]

... At some point I am going to tackle the 3.5" code, but after seeing the accelerator code, I'm a bit worried about what I might find in there.

I would hope that the //c+ 3.5 drive code is related to either the IIGS or SuperDrive controller.

In any event, it's more likely that the 3.5 drive code works correctly.

Haha, and my first usenet post for like... 15 years.

Welcome back.

When I recently returned to retrocomputing, I was rather surprised to realize that the current (non-Facebook) place to find savvy Apple II users is comp.sys.apple2.

I didn't even think to check for activity in comp.sys.apple2.programmer until 4am Tweeted a link.

If it makes you feel any better, earlier this year in a forum I quoted myself from a 1992 Usenet posting about connecting the ImageWriter II to an Amiga.

[Michael J. Mahon]

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!

Not at all we'll-crafted.

But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.

This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.

The code in question is:

clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1

Whether A is 0 or 1, Carry is set by the compare.

The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.

Unfortunately, your revised code contains the same bug.

[I am Rob]

Post by Michael J. Mahon

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!
Not at all we'll-crafted.
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1
Whether A is 0 or 1, Carry is set by the compare.
The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.
Unfortunately, your revised code contains the same bug.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Also the CLC is unnecessary as the CMP will either clear or set the carry.

And instead of changing the 0 to a 1, the SEC could be changed to a CLC. And the BEQ to a BNE. This would constitute an error so maybe the label should be changed as well.

CMP #$00
BNE ERR
CLC
ERR: JMP SWRTS1

[Michael J. Mahon]

Post by I am Rob

Post by Michael J. Mahon

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!
Not at all we'll-crafted.
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1
Whether A is 0 or 1, Carry is set by the compare.
The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.
Unfortunately, your revised code contains the same bug.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Also the CLC is unnecessary as the CMP will either clear or set the carry.
And instead of changing the 0 to a 1, the SEC could be changed to a CLC.
And the BEQ to a BNE. This would constitute an error so maybe the label
should be changed as well.
CMP #$00
BNE ERR
CLC
ERR: JMP SWRTS1

As I said, *none* of that is necessary--just a CMP #$01 before the JMP.
Remember, CMP sets Carry if A >= operand, and clears it if A < operand.

[I am Rob]

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

Been there, done that: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!
Not at all we'll-crafted.
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1
Whether A is 0 or 1, Carry is set by the compare.
The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.
Unfortunately, your revised code contains the same bug.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Also the CLC is unnecessary as the CMP will either clear or set the carry.
And instead of changing the 0 to a 1, the SEC could be changed to a CLC.
And the BEQ to a BNE. This would constitute an error so maybe the label
should be changed as well.
CMP #$00
BNE ERR
CLC
ERR: JMP SWRTS1

As I said, *none* of that is necessary--just a CMP #$01 before the JMP.
Remember, CMP sets Carry if A >= operand, and clears it if A < operand.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I was thinking more of preserving the EQUALS ($00) / NOT EQUALS ($01).

Your way would be EQUALS ($01) / NOT EQUALS ($00).

Which is what I think what most error routines should handle.

[Michael J. Mahon]

Post by I am Rob

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!
Not at all we'll-crafted.

My comment referred to the Apple code, not yours. ;-)

Post by I am Rob

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1
Whether A is 0 or 1, Carry is set by the compare.
The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.
Unfortunately, your revised code contains the same bug.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Also the CLC is unnecessary as the CMP will either clear or set the carry.
And instead of changing the 0 to a 1, the SEC could be changed to a CLC.
And the BEQ to a BNE. This would constitute an error so maybe the label
should be changed as well.
CMP #$00
BNE ERR
CLC
ERR: JMP SWRTS1

As I said, *none* of that is necessary--just a CMP #$01 before the JMP.
Remember, CMP sets Carry if A >= operand, and clears it if A < operand.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I was thinking more of preserving the EQUALS ($00) / NOT EQUALS ($01).
Your way would be EQUALS ($01) / NOT EQUALS ($00).
Which is what I think what most error routines should handle.

I understand. Clearly, the original intent (not realized) was to use Carry
set as the error indication. In view of the bug, <not equal> has become the
error branch, and it's now necessary to preserve compatibility with the
bug! ;-(
(Although I'd be surprised if 1) more than two pieces of code ever used
this routine, and 2) *any* code ever took any meaningful error action. ;-)

[Michael J. Mahon]

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon

Post by MG

Post by r***@gmail.com
After reviewing the //c+ CCGA code I determined that I will need to
write about "The Horror Of The IIc Plus Accelerator Code."

https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e
Fixed/enhanced: https://github.com/mgcaret/rom4x/blob/master/rom5x/B1_FD00_accel5x.s
MG

Very interesting code!
Not at all we'll-crafted.

My comment referred to the Apple code, not yours. ;-)

Post by I am Rob

Post by Michael J. Mahon

Post by I am Rob

Post by Michael J. Mahon
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
clc
cmp #$00
beq noerr
sec
noerr: jmp SWRTS1
Whether A is 0 or 1, Carry is set by the compare.
The code bug is that the compare should have been done to 1. This would
set Carry if A is 1 and clear it if A is 0--no clc, conditional branch, or
sec needed.
Unfortunately, your revised code contains the same bug.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Also the CLC is unnecessary as the CMP will either clear or set the carry.
And instead of changing the 0 to a 1, the SEC could be changed to a CLC.
And the BEQ to a BNE. This would constitute an error so maybe the label
should be changed as well.
CMP #$00
BNE ERR
CLC
ERR: JMP SWRTS1

As I said, *none* of that is necessary--just a CMP #$01 before the JMP.
Remember, CMP sets Carry if A >= operand, and clears it if A < operand.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I was thinking more of preserving the EQUALS ($00) / NOT EQUALS ($01).
Your way would be EQUALS ($01) / NOT EQUALS ($00).
Which is what I think what most error routines should handle.

I understand. Clearly, the original intent (not realized) was to use Carry
set as the error indication. In view of the bug, <not equal> has become the
error branch, and it's now necessary to preserve compatibility with the
bug! ;-(
(Although I'd be surprised if 1) more than two pieces of code ever used
this routine, and 2) *any* code ever took any meaningful error action. ;-)

Upon reflection, the compatibility requirement that the Z flag reflect the
content of A, just adding an ORA #$00 after the CMP #$01 will do the job.

A TAX or TAY would do as well, but the X and Y registers have already been
restored.

[MG]

Post by Michael J. Mahon

Post by Michael J. Mahon
My comment referred to the Apple code, not yours. ;-)

Well that does make me feel a bit better, but I have often looked at my code and realized I put a bit too much YOLO into it myself.

Post by Michael J. Mahon

Post by Michael J. Mahon
(Although I'd be surprised if 1) more than two pieces of code ever used
this routine, and 2) *any* code ever took any meaningful error action. ;-)

I don't even think two did, I am pretty sure Quinn Dunki's accelerator reverse ROM was the first one.

Post by Michael J. Mahon
Upon reflection, the compatibility requirement that the Z flag reflect the
content of A, just adding an ORA #$00 after the CMP #$01 will do the job.

That's what I was thinking about doing as well, but I am not sure how necessary it is. I also agree with your assessment that error checking was never done by any potential user of these functions, because the Tech Ref says that you only get an error if you use an invalid function number. Additionally, since it was likely known to developers at the time that it worked like an integrated Zip chip, most software that would want to slow the machine down would just bypass the firmware anyway and cover the IIc Plus and anything with a Zip Chip with one routine.

So ultimately in yesterday's fix, I decided not to be bug-compatible. If I get any reports of software that actually gets broken by that particular decision, I will print this sentence out and physically eat it.

MG

[Michael J. Mahon]

Post by MG

Post by Michael J. Mahon

Post by Michael J. Mahon
My comment referred to the Apple code, not yours. ;-)

Well that does make me feel a bit better, but I have often looked at my
code and realized I put a bit too much YOLO into it myself.

Post by Michael J. Mahon

Post by Michael J. Mahon
(Although I'd be surprised if 1) more than two pieces of code ever used
this routine, and 2) *any* code ever took any meaningful error action. ;-)

I don't even think two did, I am pretty sure Quinn Dunki's accelerator
reverse ROM was the first one.

Post by Michael J. Mahon
Upon reflection, the compatibility requirement that the Z flag reflect the
content of A, just adding an ORA #$00 after the CMP #$01 will do the job.

That's what I was thinking about doing as well, but I am not sure how
necessary it is. I also agree with your assessment that error checking
was never done by any potential user of these functions, because the Tech
Ref says that you only get an error if you use an invalid function
number. Additionally, since it was likely known to developers at the
time that it worked like an integrated Zip chip, most software that would
want to slow the machine down would just bypass the firmware anyway and
cover the IIc Plus and anything with a Zip Chip with one routine.
So ultimately in yesterday's fix, I decided not to be bug-compatible. If
I get any reports of software that actually gets broken by that
particular decision, I will print this sentence out and physically eat it.
MG

Love it! ;-)

[MG]

Post by Michael J. Mahon
Very interesting code!
Not at all we'll-crafted.

I don't claim to be a great craftsman, only adequate.

Post by Michael J. Mahon
But you mention that there is a documentation bug stating that the Carry is
always set after return from the CGGA code, and that's not the case. The
Carrry *is* always set, whether A contains 0 or 1.

True enough. This project was actually my first 6502 assembly code since I was probably a freshman in high school (i.e. decades ago), so I forgot that carry set is greater than or equal, and carry clear is less than. At the time I disassembled it, I had the "or equal" part in my head the wrong way. Personally, I'm happy I got most of it right without having to reference the 6502 documentation much for a refresher.

A lot of people have looked at it, you're the first to have noticed. :-)

Post by Michael J. Mahon
This behavior was clearly not intended, since the CGGA return routine
attempts to set/clear the Carry flag depending on whether A is 0 or 1, but
fails--leading to Carry always being set.
<snip>
Unfortunately, your revised code contains the same bug.

Indeed it does. Will be fixed in the next release.

[MG]

Post by MG
Indeed it does. Will be fixed in the next release.

Fix pushed to GitHub, gist corrected. For those in the future who come late to the party, gist can show previous revisions.

I welcome more feedback, or even better, pull requests. :-)

MG

[r***@gmail.com]

Hi FASTChip and Zip Chip users, I would appreciate if you can test this version. Note that the enable replaces fast and is different than the previous version. (Hardcoding the FASTChip for 16Mhz was silly considering that the FASTChip has the easiest way to set the speed.)

DO NOT RUN THIS ON NON-GS SYSTEMS USING ANNUCIATOR 1 OR ON A //C USING VERTICAL BLANK INTERRUPTS.

Disables or enables the accelerator on the IIGS, //c+, FASTChip or Zip Chip.
(Untested with the FASTChip or Zip Chip. Source is based on the documentation.)

Does not check for a FASTChip or Zip Chip, just tries to disable/enable them. Setting the Zip Chip changes annuciator 1 (//c vertical blank enable).

This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.
The other expected use is to set the speed in a program.

If the Apple is an original, ][ Plus, or //e, the FASTChip is set first. If it fails a Zip Chip is set.
The Zip Chip registers used overlap annunciator 1.
The Zip Chip registers overlaying the annunciators should already be known by Zip Chip users.

BRUN NORMFAST or CALL 768 to disable the accelerator.
CALL 771 to enable the accelerator.
(Accelerators such as the FASTChip or Zip Chip can run slower than 1Mhz when enabled.)

NORMFAST is position independent and can be loaded most anywhere in the first 48K of memory.

=====

DO NOT RUN THIS ON NON-GS SYSTEMS USING ANNUCIATOR 1 OR ON A //C USING VERTICAL BLANK INTERRUPTS.

Boot DOS or start a copy of BASIC.SYSTEM and copy/paste the following.

CALL -151
300:A9 0 2C A9 1 A2 2 AE B3 FB E0 6 D0
:3D AE C0 FB F0 16 48 38 20 1F FE 68
:B0 30 4A AD 36 C0 29 7F 90 2 9 80 8D
:36 C0 60 AE BF FB E0 5 D0 1B 49 1 1A
:A6 0 8 78 48 A9 4 48 20 C7 C7 20 C7
:C7 A9 3 48 20 C7 C7 28 86 0 60 AA A9
:6A 8 78 8D 6A C0 8D 6A C0 8D 6A C0 8D
:6A C0 8D 6B C0 2C 6B C0 10 B 4A 9D 6A
:C0 A9 A6 8D 6A C0 28 60 A9 5A 8D 5A
:C0 8D 5A C0 8D 5A C0 8D 5A C0 4A 9D
:5A C0 A9 A5 8D 5A C0 28 60
3D0G
BSAVE NORMFAST,A$300,L$88

=====

This version uses a 65C02 opcode on the //c+.

;;; Disable/enable IIGS, //c+, FASTChip, Zip Chip accelerator
;
; NORMFAST
; Release 2 2017-08-27 change enable entry point, add Zip
; Chip, change setting FASTChip speed to disable/enable
;
; Release 1 2017-08-25 IIGS, //c+ and FASTChip
;
; DO NOT RUN THIS ON NON-GS SYSTEMS USING ANNUCIATOR 1
; OR ON A //C USING VERTICAL BLANK INTERRUPTS.
;
; Disables or enables the accelerator on the IIGS, //c+,
; FASTChip or Zip Chip.
; (Untested with the FASTChip or Zip Chip.
; Source is based on the documentation.)
;
; Does not check for a FASTChip or Zip Chip, just tries to
; disable/enable them. Setting the Zip Chip changes
; annuciator 1 (//c vertical blank enable).
;
; This is primarily for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; If the Apple is an original, ][ Plus, or //e, the
; FASTChip is set first. If it fails a Zip Chip is set.
; The Zip Chip registers used overlap annunciator 1.
; The Zip Chip registers overlaying the annunciators
; should already be known by Zip Chip users.
;
; BRUN NORMFAST or CALL 768 to disable the accelerator.
; CALL 771 to enable the accelerator.
; (Accelerators such as the FASTChip or Zip Chip can run
; slower than 1Mhz when enabled.)
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.65C02 ; when on a //c+

; addresses are lowercase, constant values are in CAPS

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036 ; bit 7: fast mode

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B

; Zip Chip
zc_lock .equ $C05A
ZC_UNLOCK .equ $5A ; write 4 times
ZC_LOCK .equ $A5
zc_enable .equ $C05B

.org $300

; disable accelerator
lda #0 ; offset to disable Zip/FAST
.byte $2C ; BIT <ABSOLUTE>, hide next ldx #

; enable accelerator
lda #1 ; offset to enable Zip/FAST

ldx #2 ; our release number
ldx romid
cpx #ROMID_IIECOMPAT
bne fc ; not a //e, try FASTChip

ldx romid_ec
beq iic ; a //c

pha
sec
jsr idroutine
pla
bcs fc ; not a IIGS, try FASTChip

; set IIGS speed

lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
rts

; set //c+ speed

iic
ldx romid_c
cpx #ROMID_CPLUS
bne fc ; not a //c+, try FASTChip

; change 0 and 1 to 2 and 1
eor #1
inc a ; 65C02

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
iicrts
rts

; FASTChip set first because its registers do not overlap
; any known motherboard locations

fc
tax
lda #FC_UNLOCK
php
sei ; timing sensitive
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
bit fc_enable
bpl zip ; FASTChip not enabled
lsr ; cannot be FC_LOCK or FC_UNLOCK
sta fc_lock,x ; disable/enable
lda #FC_LOCK
sta fc_lock
plp ; restore interrupt state
rts

; Zip Chip registers used here overlap annunciator 1 /
; //c vertical blank registers
; enter here with processor status on stack and interrupts
; disabled

zip
lda #ZC_UNLOCK
sta zc_lock
sta zc_lock
sta zc_lock
sta zc_lock
lsr ; not ZC_LOCK or ZC_UNLOCK
sta zc_lock,x ; disable/enable
lda #ZC_LOCK
sta zc_lock
plp ; restore interrupt state
rts

[Andrew Roughan]

Post by r***@gmail.com
NORMFAST sets normal (1Mhz) or fast speed on the IIGS, //c+, or hopefully
on an Apple II with a FASTChip.

If you are trying to support commonly used accelerators then perhaps you
should also support the Transwarp //e

Post by r***@gmail.com
This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.

Perhaps this reason d'être needs updating?
As the fast chip //e is not usable with a //c+

Regards
Andrew

[r***@gmail.com]

Post by Andrew Roughan
If you are trying to support commonly used accelerators then perhaps you
should also support the Transwarp //e

Heh, it was a matter of time before someone asked about another accelerator. I'll see what I can find.

Post by Andrew Roughan

Post by r***@gmail.com
This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.

Perhaps this reason d'être needs updating?
As the fast chip //e is not usable with a //c+

Well, it's still a true statement. Setting normal speed manually on the //gs or the FASTChip is simple.

A FASTChip is not likely to work in a //gs either.

NORMFAST is intended to run on any configuration with minimal adverse side effects.

[i***@gmail.com]

Post by r***@gmail.com
Heh, it was a matter of time before someone asked about another accelerator.

Laser 128EX from the "Laser 128 Series Technical Reference Manual", Appendix A:

"The clock frequency of the CPU is software-selectable to be 1 MHz, 2.3 MHz or 3.6 MHz through the write-only I/O location $C074 which is usually referred to as the speed register. Only bit 5 to bit 7 of the speed register are used.

Bit 6 and bit 7 of the speed register are used for selecting the highest operating frequency of the CPU. Table A-1 shows the CPU speed for various speed register bit settings.

Speed Register ($C074)|Maximum CPU
Bit 7 | Bit 6 |operating frequency
---------+------------+-------------------
0 | 0 | 1 MHz
0 | 1 | 1 MHz
1 | 0 | 2.3 MHz
1 | 1 | 3.6 MHz

Table A-1 Selection of CPU speed
"

(This is followed by several pages explaining the dynamic slow-down logic.)

https://archive.org/details/Laser_128_Series_Technical_Reference_Manual

I don't know the "canonical" way to detect a Laser or distinguish 128 from 128EX or 128EX/2, though.

[r***@gmail.com]

[Details about setting the Laser 128EX speed]
https://archive.org/details/Laser_128_Series_Technical_Reference_Manual
I don't know the "canonical" way to detect a Laser or distinguish 128 from 128EX or 128EX/2, though.

I was thinking about trying to find a Laser 128 until the SmartPort emulators came out. Before that, a card slot would have been quite valuable.

Thanks for the link.

Yeah, Laser 128 identification is supposed to be something that nobody was supposed to do!

There is a ROM dump of the 128EX2 at the Apple II Documentation Project.

Does anyone have a ROM dump of the 128EX?

[Jorge]

Post by r***@gmail.com
Does anyone have a ROM dump of the 128EX?

I can do it, I have a 128EX.

[I am Rob]

Post by Jorge

Post by r***@gmail.com
Does anyone have a ROM dump of the 128EX?

I can do it, I have a 128EX.

I guess I am missing slots 4 and 7 firmware and the ROM for the serial ports and the video expansion ROM and smartport.

If you want to do it Jorge, then I won't have to pull out my Laser. :)

I can post the code for reading the ROMs if you need it.

Do you know how to access the serial ports control panel? I didn't know how for quite awhile after I got mine.

[r***@gmail.com]

Post by I am Rob
Do you know how to access the serial ports control panel? I didn't know how for quite awhile after I got mine.

The Laser 128 documentation says Control-P-Reset. (P being pressed with Control-Reset.)

[I am Rob]

Post by r***@gmail.com

[Details about setting the Laser 128EX speed]
https://archive.org/details/Laser_128_Series_Technical_Reference_Manual
I don't know the "canonical" way to detect a Laser or distinguish 128 from 128EX or 128EX/2, though.

I was thinking about trying to find a Laser 128 until the SmartPort emulators came out. Before that, a card slot would have been quite valuable.
Thanks for the link.
Yeah, Laser 128 identification is supposed to be something that nobody was supposed to do!
There is a ROM dump of the 128EX2 at the Apple II Documentation Project.
Does anyone have a ROM dump of the 128EX?

I have version 4.2 from a 128EX, but it is broken into parts with the internal ROMs for each slot in separate files. C100, C200 .. C700.

plus the Laser applesoft in a separate file. PM me if you want a disk image.

[Antoine Vignau]

I'd like to get a copy of rom files for the A2 documentation project, please

av

[r***@gmail.com]

Post by I am Rob
I have version 4.2 from a 128EX, but it is broken into parts with the internal ROMs for each slot in separate files. C100, C200 .. C700.

Thanks for the offer.

I was a doofus and didn't check the Apple II Documentation Project first. It has the 4.2, 4.5 and EX/2 ROMs.

[r***@gmail.com]

Post by r***@gmail.com

Post by Andrew Roughan
If you are trying to support commonly used accelerators then perhaps you
should also support the Transwarp //e

Heh, it was a matter of time before someone asked about another accelerator. I'll see what I can find.

TransWarp II support is not looking good at the moment.

The "TransWarp II Programmer's Guide" is required. A glance at the user's manuals for the TransWarp I and II indicate that the II was a redesign.

TransWarp I support is easy.

Post by r***@gmail.com

Post by Andrew Roughan
Perhaps this reason d'être needs updating?
As the fast chip //e is not usable with a //c+

Well, it's still a true statement. Setting normal speed manually on the //gs or the FASTChip is simple.

Over the weekend I noticed that there are two Apple II accelerators in production, you are correct, I should update that.

[Antoine Vignau]

If you want to support more cards, you have manuals @ http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Interface%20Cards/Accelerators/

I've just uploaded the pseudo manual of the Number Nine accelerator card. You'll see, you have of way of detecting it but it is easy to turn it off or on.

Antoine

[Antoine Vignau]

typo: "You'll see, you have NO way of detecting it but it is easy to turn it off or on. "

[r***@gmail.com]

If you want to support more cards, ...

It's likely that I'll need to restrict the list of supported accelerators.

NORMFAST is rapidly approaching the $D0 size for page 3. I do not think it will be very useful if it no longer fits in page 3.

I also think it's likely that there will be an address conflict between accelerators.

Thanks for the Apple II Documentation Project! It is a very valuable resource for us.

[I am Rob]

Post by r***@gmail.com

If you want to support more cards, ...

It's likely that I'll need to restrict the list of supported accelerators.
NORMFAST is rapidly approaching the $D0 size for page 3. I do not think it will be very useful if it no longer fits in page 3.
I also think it's likely that there will be an address conflict between accelerators.
Thanks for the Apple II Documentation Project! It is a very valuable resource for us.

How about writing an identification program that identifies which accelerator the computer has at bootup, then only installing the code for just that accelerator in page 3?

[i***@gmail.com]

Post by r***@gmail.com
It's likely that I'll need to restrict the list of supported accelerators.
NORMFAST is rapidly approaching the $D0 size for page 3. I do not think it will be very useful if it no longer fits in page 3.

I'm envisioning building the logic into a program launcher - the launcher can run accelerated, but slow the processor down for the launched app (e.g. a game). Not quite the same use case, but definitely building on what you've started and the research that's being shared/consolidated here!

[r***@gmail.com]

Post by i***@gmail.com
I'm envisioning building the logic into a program launcher - the launcher can run accelerated, but slow the processor down for the launched app (e.g. a game). Not quite the same use case, but definitely building on what you've started and the research that's being shared/consolidated here!

Thanks for letting me know.

My expectation is that once source gets posted, it will have a life of its own.

If you do write a launcher, it may be tempting to add options for more finely controlled accelerators like the FASTChip and Zip Chip to run just a little slower or faster than 1Mhz for certain games.

[r***@gmail.com]

NORMFAST release 4 adds Laser 128EX, the trademarked accelerator from Germany, and TransWarp I to the IIgs, //c+, FASTChip and Zip Chip support.

Any testers and/or a copy of the "TransWarp II Programmer's Guide" would be appreciated! I can only test the IIgs and //c+, which is fine with me.

WARNING: The memory location to set the accelerator speed may overlap existing locations such as: annuciators, Apple //c specific hardware, or the paddle trigger.

BRUN NORMFAST or CALL 768 to disable the accelerator.
CALL 771 to enable the accelerator.
Enabling an older accelerator may set maximum speed.
Accelerators such as the FASTChip or Zip Chip can run slower than 1Mhz when enabled.

NORMFAST is position independent and can be loaded most anywhere.

The Laser 128 is problematic. It's not clear how identify a plain 128 from a 128EX (with accelerator). When NORMFAST finds a 128, it assumes that it's an EX. This means that a plain 128 with an accelerator gets ignored.

=====

Boot DOS or start BASIC.SYSTEM in your favorite emulator and copy/paste the following.

CALL -151
300:A9 0 2C A9 1 A2 4 AE B3 FB E0 6 D0
:52 AE C0 FB F0 2B AE FF FF E0 C4 D0 E
:4A AD 74 C0 29 3F 90 2 9 C0 8D 74 C0
:60 48 38 20 1F FE 68 B0 30 4A AD 36
:C0 29 7F 90 2 9 80 8D 36 C0 60 AE BF
:FB E0 5 D0 1B 49 1 1A A6 0 8 78 48 A9
:4 48 20 C7 C7 20 C7 C7 A9 3 48 20 C7
:C7 28 86 0 60 A0 9 AA F0 2 A0 28 A9
:6A 8 78 8D 6A C0 8D 6A C0 8D 6A C0 8D
:6A C0 8D 6B C0 2C 6B C0 10 A 8C 6D C0
:A9 A6 8D 6A C0 28 60 A9 5A 8D 5A C0
:8D 5A C0 8D 5A C0 8D 5A C0 4A 9D 5A
:C0 A9 A5 8D 5A C0 28 8A 49 1 AA 9D 5C
:C0 8E 74 C0 60
3D0G
BSAVE NORMFAST,A$300,L$AC

=====

;;; NORMFAST Disable/enable Apple II compatible accelerator
;
; Release 4 2017-09-06 Add Laser 128EX, TransWarp I, UW
;
; Release 3 2017-08-29 Change FASTChip partially back to
; release 1, which seems to work the way release 2 was
; intended?!
;
; Release 2 2017-08-27 change enable entry point, add Zip
; Chip, change setting FASTChip speed to disable/enable
;
; Release 1 2017-08-25 IIGS, //c+ and FASTChip
;
; WARNING: The memory location to set the accelerator
; speed may overlap existing locations such as:
; annuciators or Apple //c specific hardware
; paddle trigger
;
; Known to work: IIGS, //c+
; Theoretically: FASTChip, Laser 128EX, TransWarp I,
; trademarked German product, Zip Chip
;
; BRUN NORMFAST or CALL 768 to disable the accelerator.
; CALL 771 to enable the accelerator.
; Enabling an older accelerator may set maximum speed.
; Accelerators such as the FASTChip or Zip Chip can run
; slower than 1Mhz when enabled.
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; This was originally for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.65C02 ; when on a //c+

; addresses are lowercase, constant values are in CAPS

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
; Laser 128s are $E0
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036 ; bit 7: fast mode

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

l128irqpage .equ $C4
; From the 4.2, 4.5 and EX2 ROM dumps at the Apple II
; Documentation Project, the Laser 128 IRQ handlers are
; in the $C4 page.
; A comp.sys.apple2 post says the 6.0 ROM for the 128 and
; 128EX are identical, so there may not be an easy way to
; tell a plain 128 from an (accelerated) 128EX.
irq .equ $FFFE ; 6502 IRQ vector

; may overlap with paddle trigger
ex_cfg .equ $C074 ; bits 7 & 6 for speed
EX_NOTSPEED .equ $3F
EX_1MHZMASK .equ $0
EX_2MHZMASK .equ $80 ; 2.3Mhz
EX_3MHZMASK .equ $C0 ; 3.6Mhz

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_ON .equ 40 ; doco says 16.6Mhz

; TransWarp I
; may overlap with paddle trigger
tw1_speed .equ $C074
TW1_1MHZ .equ 1
TW1_MAX .equ 0

; Trademarked German accelerator
; overlaps annunciator 2 & //c mouse interrupts
uw_fast .equ $C05C
uw_1mhz .equ $C05D

; Zip Chip
; overlaps annunciator 1 & //c vertical blank
zc_lock .equ $C05A
ZC_UNLOCK .equ $5A ; write 4 times
ZC_LOCK .equ $A5
zc_enable .equ $C05B

.org $300

; disable accelerator
lda #0 ; offset to disable Zip
.byte $2C ; BIT <ABSOLUTE>, hide next lda #

; enable accelerator
lda #1 ; offset to enable Zip

ldx #4 ; our release number

;; first check built-in accelerators

ldx romid
cpx #ROMID_IIECOMPAT
bne fc ; not a //e, try FASTChip

ldx romid_ec
beq iic ; //c family

; not worth the bytes for enhanced //e check
ldx irq+1
cpx #l128irqpage
bne gscheck

; a Laser 128, hopefully harmless on a non EX

lsr ; set carry for fast
lda ex_cfg
and #EX_NOTSPEED ; 1Mhz is zero
bcc exset
ora #EX_3MHZMASK
exset
sta ex_cfg
rts

gscheck
pha
sec
jsr idroutine
pla
bcs fc ; not a IIGS, try FASTChip

; set IIGS speed

lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
rts

iic
ldx romid_c
cpx #ROMID_CPLUS
bne fc ; not a //c+, try FASTChip

; Set //c+ speed. Uses the horrible firmware in case other
; code works "by the book", that is can check and set
; whether the accelerator is enabled.
; The //c+ is Zip compatible.

; change 0 and 1 to 2 and 1
eor #1
inc a ; 65C02

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
rts

;; At this point, the computer does not have a built-in
;; accelerator

; FASTChip tried first because its registers do not overlap
; any known motherboard locations

fc
ldy #FC_1MHZ
tax ; also sets X for Zip
beq fcset
ldy #FC_ON ; enable set speed?
fcset
lda #FC_UNLOCK
php
sei ; timing sensitive
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
bit fc_enable
bpl zip ; FASTChip not enabled
sty fc_speed
lda #FC_LOCK
sta fc_lock
plp ; restore interrupt state
rts

; Zip Chip registers used here overlap annunciator 1 /
; //c vertical blank registers
; A Zip Chip can be detected, but that would require
; accessing other overloaded memory locations.
; enter here with X = 0 to disable, 1 to enable
; processor status on stack and interrupts disabled

zip
lda #ZC_UNLOCK
sta zc_lock
sta zc_lock
sta zc_lock
sta zc_lock
lsr ; not ZC_LOCK or ZC_UNLOCK
sta zc_lock,x ; disable/enable
lda #ZC_LOCK
sta zc_lock
plp ; restore interrupt state

; trademarked accelerator from Germany

txa
eor #1 ; swap 0 and 1
tax
sta uw_fast,x ; value does not matter

; TransWarp I

stx tw1_speed

rts

[I am Rob]

Post by r***@gmail.com
The Laser 128 is problematic. It's not clear how identify a plain 128 from a 128EX (with accelerator). When NORMFAST finds a 128, it assumes that it's an EX. This means that a plain 128 with an accelerator gets ignored.

Does it matter what $C074 is set to on the Laser 128? If it doesn't have any effect, would it matter?

I believe it is also possible for any of the Laser 128 series to have an 8 Mhz Zip Chip as well or is the Zip chip identified before Laser 128 series?

[qkumba]

May I suggest a change from:

; set IIGS speed

lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed


to

; set IIGS speed

lsr ; set carry for enable
lda gsspeed
php
asl
plp
ror ; normal or fast based on carry
sta gsspeed

[qkumba]

And this:

fc
ldy #FC_1MHZ
tax ; also sets X for Zip
beq fcset
ldy #FC_ON ; enable set speed?

can be

fc
tax ; also sets X for Zip
ldy fc_defs,x
...

fc_defs
.db FC1MHZ, FC_ON

[r***@gmail.com]

Post by r***@gmail.com
fc
ldy #FC_1MHZ
tax ; also sets X for Zip
beq fcset
ldy #FC_ON ; enable set speed?
can be
fc
tax ; also sets X for Zip
ldy fc_defs,x
...
fc_defs
.db FC1MHZ, FC_ON

Tempting, but would break relocating the binary. There seem to be enough just getting started programmers, so if they want to use NORMFAST I think it would be convenient for them to load it whereever they have the bytes.

[r***@gmail.com]

Post by r***@gmail.com
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
to
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
php
asl
plp
ror ; normal or fast based on carry
sta gsspeed

Code crunching already, eh? (I sympathize, it's a hard habit to break.)

Okay, if I don't invert the lsb of the accumulator, I'll make that change.

Unfortunately using 0 for normal and 1 for fast is mostly useful for the Zip. I'm likely to switch it around and make the Zip code pay the price.

[John Brooks]

Post by r***@gmail.com

Post by r***@gmail.com
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
to
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
php
asl
plp
ror ; normal or fast based on carry
sta gsspeed

Code crunching already, eh? (I sympathize, it's a hard habit to break.)
Okay, if I don't invert the lsb of the accumulator, I'll make that change.
Unfortunately using 0 for normal and 1 for fast is mostly useful for the Zip. I'm likely to switch it around and make the Zip code pay the price.

I'm not sure how much code size matters for NORMFAST, but I think 10-20 bytes could be saved by combining the GS/EX code path and the Zip/FastCHIP code path.

-JB
@JBrooksBSI

[qkumba]

Post by r***@gmail.com
Code crunching already, eh? (I sympathize, it's a hard habit to break.)

Based on the earlier mention of being short on space, I thought that I would look.

Post by r***@gmail.com
Okay, if I don't invert the lsb of the accumulator, I'll make that change.
Unfortunately using 0 for normal and 1 for fast is mostly useful for the Zip. I'm likely to switch it around and make the Zip code pay the price.

Fair enough.

[Michael J. Mahon]

Post by r***@gmail.com

Post by r***@gmail.com
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
and #$7F ; normal
bcc gsset
ora #$80 ; fast
gsset
sta gsspeed
to
; set IIGS speed
lsr ; set carry for enable
lda gsspeed
php
asl
plp
ror ; normal or fast based on carry
sta gsspeed

Code crunching already, eh? (I sympathize, it's a hard habit to break.)
Okay, if I don't invert the lsb of the accumulator, I'll make that change.
Unfortunately using 0 for normal and 1 for fast is mostly useful for the
Zip. I'm likely to switch it around and make the Zip code pay the price.

Given the function of the code, it's hard to imagine how performance could
be an issue.

[r***@gmail.com]

Post by I am Rob

Post by r***@gmail.com
The Laser 128 is problematic. It's not clear how identify a plain 128 from a 128EX (with accelerator). When NORMFAST finds a 128, it assumes that it's an EX. This means that a plain 128 with an accelerator gets ignored.

Does it matter what $C074 is set to on the Laser 128? If it doesn't have any effect, would it matter?

A good question. The related question is whether or not $C074 triggers the paddle timer on a Laser 128 or not.

Post by I am Rob
I believe it is also possible for any of the Laser 128 series to have an 8 Mhz Zip Chip as well or is the Zip chip identified before Laser 128 series?

Indeed, that is the loop hole. NORMFAST doesn't check for Zip Chip, which would access even more already used memory addresses.

The problem with an accelerator in a Laser 128 is the TransWarp I, which also uses $C074.

Testers are still wanted!

[Michael J. Mahon]

Post by r***@gmail.com

Post by I am Rob

Post by r***@gmail.com
The Laser 128 is problematic. It's not clear how identify a plain 128
from a 128EX (with accelerator). When NORMFAST finds a 128, it assumes
that it's an EX. This means that a plain 128 with an accelerator gets ignored.

Does it matter what $C074 is set to on the Laser 128? If it doesn't
have any effect, would it matter?

A good question. The related question is whether or not $C074 triggers
the paddle timer on a Laser 128 or not.

Post by I am Rob
I believe it is also possible for any of the Laser 128 series to have an
8 Mhz Zip Chip as well or is the Zip chip identified before Laser 128 series?

Indeed, that is the loop hole. NORMFAST doesn't check for Zip Chip, which
would access even more already used memory addresses.

The only Apple softswitch accessed by Zip Chip controls is the "unlock"
address, $C05A. Once the chip is unlocked, other accesses in that range are
intercepted by the ASIC and don't reach the Apple bus.

[MG]

Post by r***@gmail.com
I would appreciate if someone can test this with a FastChip.
NORMFAST sets normal (1Mhz) or fast speed on the IIGS, //c+, or hopefully on an Apple II with a FASTChip.
(Not yet tested with a FASTChip. The source is based on the documentation.)
This is primarily for the //c+ which is normally difficult to set to 1Mhz speed.
The other expected use is to set the speed in a program.
If the Apple is an original, ][ Plus, or //e, a FASTChip is assumed.
It is *probably* harmless if there is no FASTChip.
Does nothing on a //c that is not a //c+.

You could add support for the Apple IIe Card for Macintosh fairly cheaply.

; See if IIe Card is present
detect_IIe_Card:
lda $fbdd
cmp #$02
bne notiiecard

Set normal/fast info can be found here:

http://www.1000bit.it/support/manuali/apple/technotes/aiie/tn.aiie.10.html

[r***@gmail.com]

You could add support for the Apple IIe Card for Macintosh fairly cheaply. ...

Support for the Mac IIe Card? Ugh.

Anyway, added - and as usual untested - in NORMFAST 5.

Warning: NORMFAST now blindly sets add on accelerators. Annuciator/IIc specific locations and the paddle timer may be triggered.

Known to work: IIGS, //c+
Theoretically: FASTChip, Laser 128EX, Mac IIe Card, TransWarp I, trademarked German product, Zip Chip

BRUN NORMFAST or CALL 768 to disable the accelerator.
CALL 771 to enable the accelerator.
Enabling an older accelerator may set maximum speed.
Accelerators such as the FASTChip or Zip Chip can run slower than 1Mhz when enabled.

NORMFAST is position independent and can be loaded most anywhere in the first 48K of memory.

The size of $B5 is a good omen regarding a @Straczynski creation.

====

Boot a copy of DOS or start BASIC.SYSTEM in your favorite Apple II emulator, then copy and paste the following.

CALL -151
300:A9 1 2C A9 0 A2 5 AE B3 FB E0 6 D0
:62 AE C0 FB F0 3D AE FF FF E0 C4 D0
:16 A0 C0 A2 74 4A 98 B0 5 1D 0 C0 D0
:5 49 FF 3D 0 C0 9D 0 C0 60 48 38 20
:1F FE 68 B0 6 A0 80 A2 36 D0 E0 AE BE
:FB D0 2D AE DD FB E0 2 D0 26 A0 4 A2
:2B D0 CE AE BF FB E0 5 D0 19 1A A6 0
:8 78 48 A9 4 48 20 C7 C7 20 C7 C7 A9
:3 48 20 C7 C7 28 86 0 60 8D 74 C0 A8
:49 1 AA A9 5A 8 78 8D 5A C0 8D 5A C0
:8D 5A C0 8D 5A C0 4A 9D 5A C0 A9 A5
:8D 5A C0 99 5C C0 A2 9 98 D0 2 A2 28
:A9 6A 8D 6A C0 8D 6A C0 8D 6A C0 8D
:6A C0 8D 6B C0 8E 6D C0 A9 A6 8D 6A
:C0 28 60
3D0G
BSAVE NORMFAST,A$300,L$B5

====

Testing on the //c+ includes an in memory patch to use the generic code. This failed because the //c+ happened to report the FastCHIP enabled bit as true, so never tried the Zip Chip. Testing for the FASTChip enable has been removed. There are not enough bytes to test for the acclerators, so all add on accelerators are now set blindly.

Qkumba is correct that lookups would make the code shorter; however this would require position dependant code, or extra code to calculate the table address.

John Brooks was correct about shortening the GS and EX code which became obvious with the Mac IIe Card.

Antoine mentioned the Saturn Systems Accelerator so I looked into it. The Saturn Systems uses the slot firmware addresses ($C<slot>x0) for control. I have never seen this before. A slot search would be necessary, so requires way too many bytes.

====

;;; NORMFAST Disable/enable Apple II compatible accelerator
;
; Release 5 2017-09-27 Add Macintosh IIe Card. Addon
; accelerators are now set blindly, so will access
; annunciators/IIc locations and may trigger the
; paddle timer.
; No plans for the Saturn Systems Accelerator which would
; require a slot search.
;
; Release 4 2017-09-06 Add Laser 128EX, TransWarp I, UW
;
; Release 3 2017-08-29 Change FASTChip partially back to
; release 1, which seems to work the way release 2 was
; intended?!
;
; Release 2 2017-08-27 change enable entry point, add Zip
; Chip, change setting FASTChip speed to disable/enable
;
; Release 1 2017-08-25 IIGS, //c+ and FASTChip
;
; WARNING: The memory location to set the accelerator
; speed may overlap existing locations such as:
; annuciators or Apple //c specific hardware
; paddle trigger
;
; Known to work: IIGS, //c+
; Theoretically: FASTChip, Laser 128EX, Mac IIe Card,
; TransWarp I, trademarked German product, Zip Chip
;
; BRUN NORMFAST or CALL 768 to disable the accelerator.
; CALL 771 to enable the accelerator.
; Enabling an older accelerator may set maximum speed.
; Accelerators such as the FASTChip or Zip Chip can run
; slower than 1Mhz when enabled.
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; This was originally for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.65C02 ; only used for //c+
; 6502 opcodes are preferred to be friendly to the old
; monitor disassemblers

; addresses are lowercase, constant values are in CAPS

RELEASE .equ 5 ; our version

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
; Laser 128s are $E0
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5
romid_maciie_0 .equ $FBBE ; 0
romid_maciie_2 .equ $FBDD ; 2

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036
GS_FAST .equ $80 ; mask

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

; Macintosh IIe Card
maciie .equ $C02B
MACIIE_FAST .equ 4 ; mask

l128irqpage .equ $C4
; From the 4.2, 4.5 and EX2 ROM dumps at the Apple II
; Documentation Project, the Laser 128 IRQ handlers are
; in the $C4 page.
; A comp.sys.apple2 post says the 6.0 ROM for the 128 and
; 128EX are identical, so there may not be an easy way to
; tell a plain 128 from an (accelerated) 128EX.
irq .equ $FFFE ; 6502 IRQ vector

; may overlap with paddle trigger
ex_cfg .equ $C074 ; bits 7 & 6 for speed
EX_NOTSPEED .equ $3F
EX_1MHZMASK .equ $0
EX_2MHZMASK .equ $80 ; 2.3Mhz
EX_3MHZMASK .equ $C0 ; 3.6Mhz

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_ON .equ 40 ; doco says 16.6Mhz

; TransWarp I
; may overlap with paddle trigger
tw1_speed .equ $C074
TW1_1MHZ .equ 1
TW1_MAX .equ 0

; Trademarked German accelerator
; overlaps annunciator 2 & //c mouse interrupts
uw_fast .equ $C05C
uw_1mhz .equ $C05D

; Zip Chip
; overlaps annunciator 1 & //c vertical blank
zc_lock .equ $C05A
ZC_UNLOCK .equ $5A ; write 4 times
ZC_LOCK .equ $A5
zc_enable .equ $C05B

iobase .equ $C000 ; easily confused with kbd

.org $300

; disable accelerator
lda #1
.byte $2C ; BIT <ABSOLUTE>, hide next lda #

; enable accelerator
lda #0

ldx #RELEASE ; our release number

;; first check built-in accelerators

ldx romid
cpx #ROMID_IIECOMPAT
bne addon ; not a //e

ldx romid_ec
beq iic ; //c family

; not worth the bytes for enhanced //e check
ldx irq+1
cpx #l128irqpage
bne gscheck

; a Laser 128, hopefully harmless on a non EX

ldy #EX_3MHZMASK ; phew, all needed bits set
ldx #lo(ex_cfg)

;; setspeed - set 1Mhz with AND and fast with OR
;
; A = lsb set for normal speed
; X = low byte address of speed location
; Y = OR mask for fast

setspeed
lsr
tya
bcs setnorm
ora iobase,x
bne setsta ; always

setnorm
eor #$FF
and iobase,x
setsta
sta iobase,x
rts

gscheck
pha
sec
jsr idroutine
pla
bcs maccheck ; not a gs

; set IIGS speed

ldy #GS_FAST
ldx #lo(gsspeed)
bne setspeed ; always

maccheck
ldx romid_maciie_0
bne addon ; no built-in accelerator
ldx romid_maciie_2
cpx #2
bne addon ; no built-in accelerator

; the IIe Card in a Mac

ldy #MACIIE_FAST
ldx #lo(maciie)
bne setspeed ; always

iic
ldx romid_c
cpx #ROMID_CPLUS
bne addon ; not a //c+, eventually hit Zip

; Set //c+ speed. Uses the horrible firmware in case other
; code works "by the book", that is can check and set
; whether the accelerator is enabled.
; The //c+ is otherwise Zip compatible.

inc a ; 65C02 $1A

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
rts

;; At this point, the computer does not have a built-in
;; accelerator
;
; Previous versions had tested fc_enable, which was not
; enough. Running low on space so just set blindly.

addon
; TransWarp I

sta tw1_speed

; Zip Chip

tay
eor #1
tax
lda #ZC_UNLOCK
php
sei ; timing sensitive
sta zc_lock
sta zc_lock
sta zc_lock
sta zc_lock
lsr ; not ZC_LOCK or ZC_UNLOCK
sta zc_lock,x ; disable/enable
lda #ZC_LOCK
sta zc_lock

;; current products are subject to change so do
;; these last

; trademarked accelerator from Germany

sta uw_fast,y ; value does not matter

; FASTChip

ldx #FC_1MHZ
tya
bne fcset
ldx #FC_ON ; enable set speed?
fcset
lda #FC_UNLOCK
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
stx fc_speed
lda #FC_LOCK
sta fc_lock
plp ; restore interrupt state
rts

[qkumba]

Two more suggestions:

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga
jsr cgga ; disable/enable
lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

->

ldy #CGGA_LOCK ; should lock after a change
phy
pha ; action after CGGA_UNLOCK
iny ;#CGGA_UNLOCK ; unlock to change
phy
jsr cgga
jsr cgga ; disable/enable
jsr cgga

and

ldx #FC_1MHZ
tya
bne fcset
ldx #FC_ON ; enable set speed?
fcset
lda #FC_UNLOCK
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
stx fc_speed
lda #FC_LOCK
sta fc_lock

->

ldx #FC_1MHZ
dey
beq fcset
ldx #FC_ON ; enable set speed?
fcset
ldy #FC_UNLOCK
sty fc_lock
sty fc_lock
sty fc_lock
sty fc_lock
sty fc_enable
stx fc_speed
inc a ; 65C02 $1A ;#FC_LOCK
sta fc_lock

[MG]

Post by r***@gmail.com
romid_maciie_0 .equ $FBBE ; 0

[SNIP]

Post by r***@gmail.com
ldx romid_maciie_0
bne addon ; no built-in accelerator

Omit this check, as that byte is the version of the Apple IIe Card firmware and is different among several versions of the "IIe Startup" application (2.2.2d1 is $03 at $FBBE).

tn.misc.07 probably should have put it in square brackets per its own commentary.

MG

[r***@gmail.com]

Post by MG

Post by r***@gmail.com
romid_maciie_0 .equ $FBBE ; 0

[SNIP]

Post by r***@gmail.com
ldx romid_maciie_0
bne addon ; no built-in accelerator

Omit this check, as that byte is the version of the Apple IIe Card firmware and is different among several versions of the "IIe Startup" application (2.2.2d1 is $03 at $FBBE).
tn.misc.07 probably should have put it in square brackets per its own commentary.
MG

Thanks! Deleting code for a fix is always appreciated, especially in page 3.

NORMFAST 6 - Disable/enable Apple II accelerator

Warning: NORMFAST now blindly sets add on accelerators. Annuciator/IIc specific locations and the paddle timer may be triggered.

Known to work: IIGS, //c+
Theoretically: FASTChip, Laser 128EX, Mac IIe Card, TransWarp I, trademarked German product, Zip Chip

BRUN NORMFAST or CALL 768 to disable the accelerator.
CALL 771 to enable the accelerator.
Enabling an older accelerator may set maximum speed.
Accelerators such as the FASTChip or Zip Chip can run slower than 1Mhz when enabled.

NORMFAST is position independent and can be loaded most anywhere in the first 48K of memory.

====

Boot a copy of DOS or start BASIC.SYSTEM in your favorite Apple II emulator, then copy and paste the following.

CALL -151
300:A9 1 2C A9 0 A2 6 AE B3 FB E0 6 D0
:5D AE C0 FB F0 38 AE FF FF E0 C4 D0
:16 A0 C0 A2 74 4A 98 B0 5 1D 0 C0 D0
:5 49 FF 3D 0 C0 9D 0 C0 60 48 38 20
:1F FE 68 B0 6 A0 80 A2 36 D0 E0 AE DD
:FB E0 2 D0 26 A0 4 A2 2B D0 D3 AE BF
:FB E0 5 D0 19 1A A6 0 8 78 48 A9 4 48
:20 C7 C7 20 C7 C7 A9 3 48 20 C7 C7 28
:86 0 60 8D 74 C0 A8 49 1 AA A9 5A 8
:78 8D 5A C0 8D 5A C0 8D 5A C0 8D 5A
:C0 4A 9D 5A C0 A9 A5 8D 5A C0 99 5C
:C0 A2 9 98 D0 2 A2 28 A9 6A 8D 6A C0
:8D 6A C0 8D 6A C0 8D 6A C0 8D 6B C0
:8E 6D C0 A9 A6 8D 6A C0 28 60
3D0G
BSAVE NORMFAST,A$300,L$B0

====

;;; NORMFAST Disable/enable Apple II compatible accelerator
;
; Release 6 2017-10-05 Fix Mac IIe card check
;
; Release 5 2017-09-27 Add Macintosh IIe Card. Addon
; accelerators are now set blindly, so will access
; annunciators/IIc locations and may trigger the
; paddle timer.
; No plans for the Saturn Systems Accelerator which would
; require a slot search.
;
; Release 4 2017-09-06 Add Laser 128EX, TransWarp I, UW
;
; Release 3 2017-08-29 Change FASTChip partially back to
; release 1, which seems to work the way release 2 was
; intended?!
;
; Release 2 2017-08-27 change enable entry point, add Zip
; Chip, change setting FASTChip speed to disable/enable
;
; Release 1 2017-08-25 IIGS, //c+ and FASTChip
;
; WARNING: The memory location to set the accelerator
; speed may overlap existing locations such as:
; annuciators or Apple //c specific hardware
; paddle trigger
;
; Known to work: IIGS, //c+
; Theoretically: FASTChip, Laser 128EX, Mac IIe Card,
; TransWarp I, trademarked German product, Zip Chip
;
; BRUN NORMFAST or CALL 768 to disable the accelerator.
; CALL 771 to enable the accelerator.
; Enabling an older accelerator may set maximum speed.
; Accelerators such as the FASTChip or Zip Chip can run
; slower than 1Mhz when enabled.
;
; NORMFAST is position independent and can be loaded most
; anywhere in the first 48K of memory.
; The ROMs must be enabled to identify the model of the
; computer.
;
; This was originally for the //c+ which is normally
; difficult to set to 1Mhz speed.
; The other expected use is to set the speed in a program.
;
; Written for Andrew Jacobs' Java based dev65 assembler at
; http://sourceforge.net/projects/dev65 but has portability
; in mind.

.65C02 ; only used for //c+
; 6502 opcodes are preferred to be friendly to the old
; monitor disassemblers

; addresses are lowercase, constant values are in CAPS

RELEASE .equ 6 ; our version

romid .equ $FBB3
; $38=][, $EA=][+, $06=//e compatible
ROMID_IIECOMPAT .equ 6
romid_ec .equ $FBC0
; $EA=//e original, $E0=//e enhanced, $E1=//e EDM, $00=//c
; Laser 128s are $E0
romid_c .equ $FBBF
; $FF=original, $00=Unidisk 3.5 ... $05=//c+
ROMID_CPLUS .equ 5
romid_maciie_2 .equ $FBDD ; 2

; IIGS
idroutine .equ $FE1F ; SEC, JSR $FE1F, BCS notgs
gsspeed .equ $C036
GS_FAST .equ $80 ; mask

; //c+ Cache Glue Gate Array (accelerator)
cgga .equ $C7C7 ; entry point
CGGA_ENABLE .equ 1 ; fast
CGGA_DISABLE .equ 2 ; normal
CGGA_LOCK .equ 3
CGGA_UNLOCK .equ 4 ; required to make a change

; Macintosh IIe Card
maciie .equ $C02B
MACIIE_FAST .equ 4 ; mask

l128irqpage .equ $C4
; From the 4.2, 4.5 and EX2 ROM dumps at the Apple II
; Documentation Project, the Laser 128 IRQ handlers are
; in the $C4 page.
; A comp.sys.apple2 post says the 6.0 ROM for the 128 and
; 128EX are identical, so there may not be an easy way to
; tell a plain 128 from an (accelerated) 128EX.
irq .equ $FFFE ; 6502 IRQ vector

; may overlap with paddle trigger
ex_cfg .equ $C074 ; bits 7 & 6 for speed
EX_NOTSPEED .equ $3F
EX_1MHZMASK .equ $0
EX_2MHZMASK .equ $80 ; 2.3Mhz
EX_3MHZMASK .equ $C0 ; 3.6Mhz

; FASTChip
fc_lock .equ $C06A
FC_UNLOCK .equ $6A ; write 4 times
FC_LOCK .equ $A6
fc_enable .equ $C06B
fc_speed .equ $C06D
FC_1MHZ .equ 9
FC_ON .equ 40 ; doco says 16.6Mhz

; TransWarp I
; may overlap with paddle trigger
tw1_speed .equ $C074
TW1_1MHZ .equ 1
TW1_MAX .equ 0

; Trademarked German accelerator
; overlaps annunciator 2 & //c mouse interrupts
uw_fast .equ $C05C
uw_1mhz .equ $C05D

; Zip Chip
; overlaps annunciator 1 & //c vertical blank
zc_lock .equ $C05A
ZC_UNLOCK .equ $5A ; write 4 times
ZC_LOCK .equ $A5
zc_enable .equ $C05B

iobase .equ $C000 ; easily confused with kbd

.org $300

; disable accelerator
lda #1
.byte $2C ; BIT <ABSOLUTE>, hide next lda #

; enable accelerator
lda #0

ldx #RELEASE ; our release number

;; first check built-in accelerators

ldx romid
cpx #ROMID_IIECOMPAT
bne addon ; not a //e

ldx romid_ec
beq iic ; //c family

; not worth the bytes for enhanced //e check
ldx irq+1
cpx #l128irqpage
bne gscheck

; a Laser 128, hopefully harmless on a non EX

ldy #EX_3MHZMASK ; phew, all needed bits set
ldx #lo(ex_cfg)

;; setspeed - set 1Mhz with AND and fast with OR
;
; A = lsb set for normal speed
; X = low byte address of speed location
; Y = OR mask for fast

setspeed
lsr
tya
bcs setnorm
ora iobase,x
bne setsta ; always

setnorm
eor #$FF
and iobase,x
setsta
sta iobase,x
rts

gscheck
pha
sec
jsr idroutine
pla
bcs maccheck ; not a gs

; set IIGS speed

ldy #GS_FAST
ldx #lo(gsspeed)
bne setspeed ; always

maccheck
ldx romid_maciie_2
cpx #2
bne addon ; no built-in accelerator

; the IIe Card in a Mac

ldy #MACIIE_FAST
ldx #lo(maciie)
bne setspeed ; always

iic
ldx romid_c
cpx #ROMID_CPLUS
bne addon ; not a //c+, eventually hit Zip

; Set //c+ speed. Uses the horrible firmware in case other
; code works "by the book", that is can check and set
; whether the accelerator is enabled.
; The //c+ is otherwise Zip compatible.

inc a ; 65C02 $1A

; cgga calls save X and Y regs but sets $0 to 0
; (this will get a laugh from C programmers)
ldx $0
php
sei ; timing sensitive
pha ; action after CGGA_UNLOCK

lda #CGGA_UNLOCK ; unlock to change
pha
jsr cgga

jsr cgga ; disable/enable

lda #CGGA_LOCK ; should lock after a change
pha
jsr cgga

plp ; restore interrupt state
stx $0
rts

;; At this point, the computer does not have a built-in
;; accelerator
;
; Previous versions had tested fc_enable, which was not
; enough. Running low on space so just set blindly.

addon
; TransWarp I

sta tw1_speed

; Zip Chip

tay
eor #1
tax
lda #ZC_UNLOCK
php
sei ; timing sensitive
sta zc_lock
sta zc_lock
sta zc_lock
sta zc_lock
lsr ; not ZC_LOCK or ZC_UNLOCK
sta zc_lock,x ; disable/enable
lda #ZC_LOCK
sta zc_lock

;; current products are subject to change so do
;; these last

; trademarked accelerator from Germany

sta uw_fast,y ; value does not matter

; FASTChip

ldx #FC_1MHZ
tya
bne fcset
ldx #FC_ON ; enable set speed?
fcset
lda #FC_UNLOCK
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_lock
sta fc_enable
stx fc_speed
lda #FC_LOCK
sta fc_lock
plp ; restore interrupt state
rts

[qkumba]

Were my recent suggestions not acceptable?

[James Wages]

romid_maciie_0 .equ $FBBE ; 0

...that byte is the version of the Apple IIe Card firmware and is different among several versions of the "IIe Startup" application (2.2.2d1 is $03 at $FBBE).

Actually, "FBBE" appears to pertain exclusively to FIRMWARE (not the IIe Startup application SOFTWARE), because when I type the following two commands at a BASIC prompt (with the IIe Card installed in an LC575 motherboard)...

CALL -151
FBBE

...it says FBBE is 03 regardless of whether I use version 2.2.1 or 2.2.2d1 of the IIe Startup app. (I cannot run II Setup app versions older than 2.2.1 because when I try, it throws the error: "Unable to continue because of a fatal error. Error # 10019.")

Interesting aside: when I try the same commands on the Virtual ][ emulator, it says FBBE is 00.

[MG]

Post by James Wages

romid_maciie_0 .equ $FBBE ; 0

...that byte is the version of the Apple IIe Card firmware and is different among several versions of the "IIe Startup" application (2.2.2d1 is $03 at $FBBE).

Actually,

...

Post by James Wages
"FBBE" appears to pertain exclusively to FIRMWARE (not the IIe Startup application SOFTWARE), because when I type the following two commands at a BASIC prompt (with the IIe Card installed in an LC575 motherboard)...
CALL -151
FBBE
...it says FBBE is 03 regardless of whether I use version 2.2.1 or 2.2.2d1 of the IIe Startup app. (I cannot run II Setup app versions older than 2.2.1 because when I try, it throws the error: "Unable to continue because of a fatal error. Error # 10019.")

I fail to see how any of that contradicts what I said. I literally said "that byte is the version of the Apple IIe Card firmware," which, BTW, is contained in the IIe Startup Application and loaded into the card when it starts - there is no actual ROM on the card. I said it was different among several versions of IIe Startup (as they vary on which firmware they ship), not unique to each version of IIe Startup.

Post by James Wages
Interesting aside: when I try the same commands on the Virtual ][ emulator, it says FBBE is 00.

That's because Virtual II is emulating a normal Apple IIe, not a IIe Card, and the normal Apple IIe firmware has $FBBE=$00.

MG

P.S. if you wish to examine the Apple IIe Card firmware as contained in the IIe Startup application: http://apple2.guidero.us/doku.php/mg_notes/iie_card/iie_startup_resources

[James Wages]

I literally said "that byte is the version of the Apple IIe Card firmware," which, BTW, is contained in the IIe Startup Application and loaded into the card when it starts - there is no actual ROM on the card. I said it was different among several versions of IIe Startup (as they vary on which firmware they ship), not unique to each version of IIe Startup.

Post by James Wages
Interesting aside: when I try the same commands on the Virtual ][ emulator, it says FBBE is 00.

That's because Virtual II is emulating a normal Apple IIe, not a IIe Card, and the normal Apple IIe firmware has $FBBE=$00.
MG
P.S. if you wish to examine the Apple IIe Card firmware as contained in the IIe Startup application: http://apple2.guidero.us/doku.php/mg_notes/iie_card/iie_startup_resources

Thank you for making time to kindly offer me a great explanation. I appreciate it very much.

So FBBE=00 applies to the original Apple IIe (enhanced or not, numerical keyboard version or older) as well as Virtual][, but FBBE=01/02/03 apply exclusively to the IIe Card?

Please know that I tested version 2.2.1 and 2.2.2d1 of the IIe Startup app, and FBBE = 03 on both app versions. Based on what you told me, that indicates 03 the IIe Card's hardware firmware revision. If FBBE numbers 01, 02 & 03 are exclusively used by the IIe Card, then such indicates Apple revised that card 3 times. However, I cannot find any information about what the differences would be between those 3 hardware/firmware revisions. Would you know?

Yes, I have read that "LC //e Card - IIe Startup Resources" web page you linked for me earlier this week, but it didn't shed light on what the actual hardware/firmware differences are between FBBE 01, 02 & 03.

To give some context to what promoted me to post a reply to your old 2017 post in the first place, I have been discussing issues with the Total Replay folks on their Github, and it was mentioned by Frank Milliron in the post below that he suspected IIe Startup versions 1.0 through 2.2.21d might have differing numbers that would allow him to differentiation between the various IIe Startup app versions on a code level...
https://github.com/a2-4am/4cade/issues/503#issuecomment-1266309227

You may find the GitHub discussion interesting, as I state my experience there about using the IIe Card in an overclocked Mystic (LC575) motherboard, citing how different versions of the IIe Startup app react to that particular Macintosh motherboard its 68040 CPU clock speed.

[MG]

Post by James Wages

I literally said "that byte is the version of the Apple IIe Card firmware," which, BTW, is contained in the IIe Startup Application and loaded into the card when it starts - there is no actual ROM on the card. I said it was different among several versions of IIe Startup (as they vary on which firmware they ship), not unique to each version of IIe Startup.

Post by James Wages
Interesting aside: when I try the same commands on the Virtual ][ emulator, it says FBBE is 00.

That's because Virtual II is emulating a normal Apple IIe, not a IIe Card, and the normal Apple IIe firmware has $FBBE=$00.
MG
P.S. if you wish to examine the Apple IIe Card firmware as contained in the IIe Startup application: http://apple2.guidero.us/doku.php/mg_notes/iie_card/iie_startup_resources

Thank you for making time to kindly offer me a great explanation. I appreciate it very much.
So FBBE=00 applies to the original Apple IIe (enhanced or not, numerical keyboard version or older) as well as Virtual][, but FBBE=01/02/03 apply exclusively to the IIe Card?

FBBE=00 also apples to old versions of IIe Startup, which may be hard to find.

Post by James Wages
Please know that I tested version 2.2.1 and 2.2.2d1 of the IIe Startup app, and FBBE = 03 on both app versions. Based on what you told me, that indicates 03 the IIe Card's hardware firmware revision. If FBBE numbers 01, 02 & 03 are exclusively used by the IIe Card, then such indicates Apple revised that card 3 times. However, I cannot find any information about what the differences would be between those 3 hardware/firmware revisions. Would you know?

It is not a hardware version. As far as I know, there is only one production version of the IIe Card. The card contains a (possibly custom) 65C02, RAM, IWM, Gemini, and some support chips. In particular, the only ROM chip on the card is a small 256-byte PROM that identifies the card to the Macintosh, it does not contain any on-board firmware.

The card "firmware" is entirely contained in the IIe Startup application. It is loaded into the card when the application starts via address+data byte registers in the card's mapped memory on the Macintosh bus (very much like an Apple II "slinky" card). The card has 256K of memory, which is divided into four parts, one main RAM bank, two Aux RAM banks (the second of which probably no software knows about), and a fourth bank that becomes the "ROM" from the Apple IIe perspective.

The fourth bank is divided into four parts as well, one of which is the main firmware bank (AppleSoft + the monitor), two auxiliary firmware banks, and the slot ROMs.

Again, this is not actual firmware in ROM, it is RAM acting like ROM.

Post by James Wages
Yes, I have read that "LC //e Card - IIe Startup Resources" web page you linked for me earlier this week, but it didn't shed light on what the actual hardware/firmware differences are between FBBE 01, 02 & 03.

FBBE does not indicate any hardware differences whatsoever. It comes from the "Monx" resource in the IIe Startup application. If you use an old enough version of IIe Startup, you will see a different value in FBBE. All of the "firmware" / "ROM" in the fourth bank of RAM I mentioned above is loaded into the card by the IIe Startup application.

Post by James Wages
To give some context to what promoted me to post a reply to your old 2017 post in the first place, I have been discussing issues with the Total Replay folks on their Github, and it was mentioned by Frank Milliron in the post below that he suspected IIe Startup versions 1.0 through 2.2.21d might have differing numbers that would allow him to differentiation between the various IIe Startup app versions on a code level...
https://github.com/a2-4am/4cade/issues/503#issuecomment-1266309227

Frank is correct, they do have different numbers at FBBE. As for any meaningful difference between the different versions, I haven't really investigated them or even map the IIe Startup -> FBBE numbers.

Post by James Wages
You may find the GitHub discussion interesting, as I state my experience there about using the IIe Card in an overclocked Mystic (LC575) motherboard, citing how different versions of the IIe Startup app react to that particular Macintosh motherboard its 68040 CPU clock speed.

I run one in a Color Classic with a Mystic board, one in a Quadra 605, and one in an LC III. But I generally run 2.2.2d1 on all of them.

I will check out the discussion.

MG

[James Wages]

...The card has 256K of memory, which is divided into four parts, one main RAM bank, two Aux RAM banks (the second of which probably no software knows about), and a fourth bank that becomes the "ROM" from the Apple IIe perspective.
The fourth bank is divided into four parts as well, one of which is the main firmware bank (AppleSoft + the monitor), two auxiliary firmware banks, and the slot ROMs.
Again, this is not actual firmware in ROM, it is RAM acting like ROM.

Very interesting! I humbly appreciate your time in providing such an amazingly helpful information.

So 128K of the card's physical 256K is being used as the IIe's "one main RAM bank," while the remaining 128K is divided into 2 Aux RAM banks (56K each?) and the "ROM" bank (16K divided into 4 parts).

When I launch IIe Startup and display the IIe Option Panel, I see the virtual Memory Expansion Card in virtual slot 7 is set to 256K, which apparently uses the Mac's RAM. If I then enter the IIe environment and check, it says the total RAM is 384K. That 384K indicates 128K (physical RAM on the IIe Card) + 256K (memory expansion card, which uses the Mac's RAM) is being used.

FBBE does not indicate any hardware differences whatsoever. It comes from the "Monx" resource in the IIe Startup application. If you use an old enough version of IIe Startup, you will see a different value in FBBE. All of the "firmware" / "ROM" in the fourth bank of RAM I mentioned above is loaded into the card by the IIe Startup application.
Frank is correct, they do have different numbers at FBBE. As for any meaningful difference between the different versions, I haven't really investigated them or even map the IIe Startup -> FBBE numbers.
I run one in a Color Classic with a Mystic board, one in a Quadra 605, and one in an LC III. But I generally run 2.2.2d1 on all of them.

Very interesting.

In that Github discussion, Frank mentions 7 different versions of the IIe Startup app, and yet it seems that only FBBE = 00, 01, 02 & 03 were used as identifiers. Since I know by my own testing that v.2.2.1 & v.2.2.2d1 share FBBE = 03, we then have the following (based on what Frank wrote on Github):

v1.0
$FBBE = 00

v2.0
$FBBE = 01?

v2.0.1
$FBBE = ?

v2.1
$FBBE = 02

v2.2
$FBBE = 02?

v2.2.1
$FBBE = 03

v2.2.2d1
$FBBE = 03

Separately from that...

I recently posted a YouTube video on my experience with the IIe Card installed in my overclocked Color Classic Mystic with the standard 60Hz VGA mod installed. Please understand that I have a lot of vintage Mac experience, but the IIe Card is my first use of an Apple II of any kind, so I am basically sharing that experience with others here:

At that particular timestamp in my video, I show how the IIe Card environment looks with the VGA mod. Instead of spanning the same horizontal width of the CRT as the Macintosh environment does when you have the stock 512x384 resolution, with the VGA mod, the IIe environment displays as 560x384 within the 640x480 VGA resolution. I don't see that as a problem, but I found it interesting. When you have the stock 512x384 resolution, the Color Classic can switch to 560x384 (spanning the same physical width on the CRT as the stock 512x384 resolution), but with the 60Hz VGA mod (I don't know if the 67Hz VGA mod will work), 560x384 is displayed within the 640x480. This means the IIe environment will display smaller when you have the VGA mod, as compared to a Color Classic with its stock resolution.

Anyway, if you continue watching you will see that I show how ProDOS icons vanish off the desktop when you enter the IIe environment (which is normal), and then I present a problem I encountered -- not being able to Format disks inserted into the Mac's internal Floppy drive (or even Write any data to it). I can Read data from it just fine though.

For some reason I don't fully understand, the solution is to use older version 2.2.1 of IIe Startup, which amazingly works on with the LC575 motherboard (even at a 40MHz overclock). That allows me to Format and Write data within the IIe environment, whereas v2.2.2d1 will not (at any Mac clock speed). But when I overclock the Mac's 68040 to 44MHz or higher, the version 2.2.1 app throws an error saying the IIe Card is damaged (it's not), and only 2.2.2.d1 will launch. Even with the 040 overclocked to 50MHz, the v2.2.2d1 app still launches and enters the IIe environment. The lone caveat with v.2.2.2d1, as shown in my video, is that you cannot (1) Format or (2) Write Data to a ProDOS formatted 3.5" floppy disk inserted into the Mac's internal floppy drive. Drives attached via Y-cable (in my case, using a FloppyEMU) still allow me to write data to them just fine, even with the Mystic motherboard highly overclocked.

[Steve Nickolas]

Post by James Wages
At that particular timestamp in my video, I show how the IIe Card
environment looks with the VGA mod. Instead of spanning the same
horizontal width of the CRT as the Macintosh environment does when you
have the stock 512x384 resolution, with the VGA mod, the IIe environment
displays as 560x384 within the 640x480 VGA resolution. I don't see that
as a problem, but I found it interesting. When you have the stock
512x384 resolution, the Color Classic can switch to 560x384 (spanning
the same physical width on the CRT as the stock 512x384 resolution), but
with the 60Hz VGA mod (I don't know if the 67Hz VGA mod will work),
560x384 is displayed within the 640x480. This means the IIe environment
will display smaller when you have the VGA mod, as compared to a Color
Classic with its stock resolution.

I have a VGA dongle and it does the same thing.

-uso.

[James Wages]

Post by Steve Nickolas
I have a VGA dongle and it does the same thing.

VGA "dongle"???

In my case, I have performed the VGA "mod" where you physically alter the Analog Board of a Color Classic, as shown in my VGA Mod video here:

[Steve Nickolas]

Post by James Wages

Post by Steve Nickolas
I have a VGA dongle and it does the same thing.

VGA "dongle"???

It plugs in the monitor jack, you plug the monitor into that.

-uso.

[MG]

Post by James Wages

...The card has 256K of memory, which is divided into four parts, one main RAM bank, two Aux RAM banks (the second of which probably no software knows about), and a fourth bank that becomes the "ROM" from the Apple IIe perspective.
The fourth bank is divided into four parts as well, one of which is the main firmware bank (AppleSoft + the monitor), two auxiliary firmware banks, and the slot ROMs.
Again, this is not actual firmware in ROM, it is RAM acting like ROM.

Very interesting! I humbly appreciate your time in providing such an amazingly helpful information.
So 128K of the card's physical 256K is being used as the IIe's "one main RAM bank," while the remaining 128K is divided into 2 Aux RAM banks (56K each?) and the "ROM" bank (16K divided into 4 parts).

64K is the main RAM, 64K is one aux memory bank just like a normal IIe, 64K is a second aux bank that can be selected via bit 4 of $C02B, and 64K is the "ROM."

To understand how it's addressed, we go back to the original Apple IIe. The Apple IIe memory map itself is somewhat complicated. In a stock machine with no expansion there is 64K of memory, which (up to) 56K is visible at any given time. The extra 4K is switchable into $D000-$DFFF, allowing access to the full 64K. This precedent was set by the Apple II/II+ (48K) with a 16K expansion. The memory can be selected for write-only (reads come from ROM), read-only, or read+write.

When a 64K memory card is inserted into the IIe Aux slot, it creates a second ("aux") 64K bank alongside the regular memory that may be switched in two large regions. Addressing what is switched in works the same as above. There are also some features that make it so you can write into the aux memory while reading the main memory.

The Apple IIe Card adds a second aux memory bank that can be switched in that is otherwise addressed the same way. I haven't figured out what it is used for though I suspect the AppleTalk stuff might buffer things there. A notable thing is that this extra bank of memory is not selected the same way that extra aux memory cards for a standard IIe are selected, so it's not compatible with software that understand "ramworks-style" memory.

Post by James Wages
When I launch IIe Startup and display the IIe Option Panel, I see the virtual Memory Expansion Card in virtual slot 7 is set to 256K, which apparently uses the Mac's RAM. If I then enter the IIe environment and check, it says the total RAM is 384K. That 384K indicates 128K (physical RAM on the IIe Card) + 256K (memory expansion card, which uses the Mac's RAM) is being used.

That's a totally different type of expansion RAM, known as "slinky" memory. The memory is addressed by a 3-byte address register and a single-byte data register. Accessing the data register reads or writes to the byte pointed to by the address register, and then increments the address register. You can't execute program code out of this style of memory, and it normally functions as a RAM disk. The physical equivalent to this is the "Apple II Memory Expansion Card" and there were more-functional clones like the AE RAMFactor card. In fact, the RAMFactor card firmware can work with the emulated memory card and add the firmware features (but no battery backup). I did this as a proof-of-concept for modifying the IIe Card's "firmware": http://apple2.guidero.us/doku.php/projects/rf_lc

Post by James Wages

FBBE does not indicate any hardware differences whatsoever. It comes from the "Monx" resource in the IIe Startup application. If you use an old enough version of IIe Startup, you will see a different value in FBBE. All of the "firmware" / "ROM" in the fourth bank of RAM I mentioned above is loaded into the card by the IIe Startup application.
Frank is correct, they do have different numbers at FBBE. As for any meaningful difference between the different versions, I haven't really investigated them or even map the IIe Startup -> FBBE numbers.
I run one in a Color Classic with a Mystic board, one in a Quadra 605, and one in an LC III. But I generally run 2.2.2d1 on all of them.

Very interesting.

[snip]

Post by James Wages
Separately from that...
http://youtu.be/iKF_zGshSWY
At that particular timestamp in my video, I show how the IIe Card environment looks with the VGA mod. Instead of spanning the same horizontal width of the CRT as the Macintosh environment does when you have the stock 512x384 resolution, with the VGA mod, the IIe environment displays as 560x384 within the 640x480 VGA resolution. I don't see that as a problem, but I found it interesting. When you have the stock 512x384 resolution, the Color Classic can switch to 560x384 (spanning the same physical width on the CRT as the stock 512x384 resolution), but with the 60Hz VGA mod (I don't know if the 67Hz VGA mod will work), 560x384 is displayed within the 640x480. This means the IIe environment will display smaller when you have the VGA mod, as compared to a Color Classic with its stock resolution.

This is normal. The Macintosh will switch to the 560x384 resolution if, and only if, the machine is capable of displaying 512x384. Furthermore, if a resolution larger than that is selected, on some Macs that are otherwise capable of 512x384, you will get 560x384 centered in that display rather than the native resolution. This is due to how the circuitry is wired in the machine. The IIe Card contains a crystal that generates the horizontal frequency for that resolution and switches it in to the video generation circuit. The machine has to support that.

Post by James Wages
Anyway, if you continue watching you will see that I show how ProDOS icons vanish off the desktop when you enter the IIe environment (which is normal), and then I present a problem I encountered -- not being able to Format disks inserted into the Mac's internal Floppy drive (or even Write any data to it). I can Read data from it just fine though.

Hmm, I don't recall running in to that. I don't have any of my machines set up right now to test, unfortunately. I keep hoping someone comes along that is an expert on the Mac side who wants to reverse-engineer the 68K code in the IIe Startup application, that would increase the overall level of understanding of the card, probably let me complete the picture for the IIe side of the card, and maybe even allow the IIe Startup application to be patched or outright replaced. All of the IIe-side code that I've looked at is the same between 2.2.1 and 2.2.2d1, so the blame for disk problems is likely in the 68K code.

Post by James Wages
For some reason I don't fully understand, the solution is to use older version 2.2.1 of IIe Startup, which amazingly works on with the LC575 motherboard (even at a 40MHz overclock). That allows me to Format and Write data within the IIe environment, whereas v2.2.2d1 will not (at any Mac clock speed). But when I overclock the Mac's 68040 to 44MHz or higher, the version 2.2.1 app throws an error saying the IIe Card is damaged (it's not), and only 2.2.2.d1 will launch. Even with the 040 overclocked to 50MHz, the v2.2.2d1 app still launches and enters the IIe environment. The lone caveat with v.2.2.2d1, as shown in my video, is that you cannot (1) Format or (2) Write Data to a ProDOS formatted 3.5" floppy disk inserted into the Mac's internal floppy drive. Drives attached via Y-cable (in my case, using a FloppyEMU) still allow me to write data to them just fine, even with the Mystic motherboard highly overclocked.

It doesn't surprise me that you eventually run in to trouble at higher speeds, as this will mess with timing on the bus and in the overall system. It's possible that at higher clock speeds the electrical interface becomes a problem or the software just doesn't wait long enough for the card to finish doing things.

MG

[MG]

To understand how it's addressed, we go back to the original Apple IIe. The Apple IIe memory map itself is somewhat complicated. In a stock machine with no expansion there is 64K of memory, which (up to) 56K is visible at any given time. The extra 4K is switchable into $D000-$DFFF, allowing access to the full 64K. This precedent was set by the Apple II/II+ (48K) with a 16K expansion. The memory can be selected for write-only (reads come from ROM), read-only, or read+write.

Bah, up to 60K, not 56K :-)

MG

[James Wages]

Post by MG

To understand how it's addressed, we go back to the original Apple IIe. The Apple IIe memory map itself is somewhat complicated. In a stock machine with no expansion there is 64K of memory, which (up to) 56K is visible at any given time. The extra 4K is switchable into $D000-$DFFF, allowing access to the full 64K. This precedent was set by the Apple II/II+ (48K) with a 16K expansion. The memory can be selected for write-only (reads come from ROM), read-only, or read+write.

Bah, up to 60K, not 56K :-)
MG

Thank you for the detailed information. Perhaps you could assist me in understanding something that is maybe memory related or maybe just a bug. I don't know which. Here is a 3.5" 800K HDV image that contains A2 Desktop and BeagleWrite:

https://kiramek.com/21test95/A2DeskTop-1.2-alpha48-en_800k.hdv.zip

I can use the emulator Virtual ][ on my modern Mac running MacOS Monterey to boot a IIe from this image just fine. (I use a virtual SCSI II card in slot 7, then add OmniDisk, then load the HDV into that virtual drive.) After booting, if I then open the Beaglewrite folder and then open Bw.System, BeagleWrite launches just fine and I can use it normally. No issues with the emulator at all,

However, if I put that same HDV image on my FloppyEMU (with the AppleII Firmware installed), connect the FloppyEMU to the Y-cable of my IIe Card (installed on an LC575 motherboard), then boot the Mac and launch IIe Startup v.2.2.2d1, the click on SmartPort, drag the icon from Spare Disk Drives into Slot 5 Drive 1, then click the Restart IIe button, I can boot into A2D just fine. If I then try to launch Bw.System, it starts to load. I see the splash screen, and then is says:

Ram drive detected in slot 7 drive 1.
OK to load BeagleWrite into it?
OK Cancel

(The Virtual ][ emulator doesn't show me that for some reason.)
Sometimes it will freeze right there. But even when it doesn't freeze there, regardless of whether I click OK or Cancel, it continues to load but then freezes just as the new word processor page displays. There is no flashing I-beam cursor and mouse and keyboard are frozen. It's totally locked up.

I've repeated this multiple times running the IIe environment at 1MHz, 1.9MHz, with the virtual Clock card removed from Slot 2, with more memory all the way up to 1MB -- all to no avail.

If I return to the Macintosh environment, quite IIe Startup, then use IIe Startup v.2.2.1 instead to try the same exact thing, BeagleWrite opens without freezing.

I am doing this with the Mac's CPU set to 40MHz, which allows v.2.2.1 of the IIe Startup app to load. At higher CPU clock frequencies v.2.2.1 will never launch. But even at 40MHz, it takes maybe 4 or 5 launch attempts before IIe Startup v.2.2.1 fully loads without that "IIe card is damaged" error dialog. IIe Startup v.2.2.2d1 always loads perfectly with no error dialog ever, regardless of the Mac's CPU clock frequency; but as I said, v.2.2.2d1 has some quirks. I cannot Format or Write to 800K ProDOS disk inserted into he Mac's internal floppy drive, and I now see that I cannot use BeagleWrite because of the aforementioned freeze.

Maybe this has nothing to do with memory and is just a bug in v.2.2.2d1. Not sure. Just wanted to report my experience as I continue to test the IIe Card in this Color Classic Mystic.

[Steve Nickolas]

ISTR there was a bug in the Apple II Desktop involving hitting a
softswitch that only actually did anything on the Mac card.

-uso.

[Joshua Bell]

Post by James Wages
Ram drive detected in slot 7 drive 1.
OK to load BeagleWrite into it?
OK Cancel

So... do you have a RAM drive (memory expansion card) configured in your Slot 7? If not... sounds like a BW bug. If so, try disabling it, and see if the problem still occurs.

Post by James Wages
(The Virtual ][ emulator doesn't show me that for some reason.)

Virtual ][ doesn't support "Slinky" memory expansion cards, so you presumably don't have a RAM drive in Slot 7.

Post by James Wages
Sometimes it will freeze right there. But even when it doesn't freeze there, regardless of whether I click OK or Cancel, it continues to load but then freezes just as the new word processor page displays. There is no flashing I-beam cursor and mouse and keyboard are frozen. It's totally locked up.

It would be interesting to drop to BASIC.SYSTEM and see if Slot 7 Drive 1 behaves there, or if this is a red herring. Put BASIC.SYSTEM on your disk image, invoke it, and at the ] prompt type: CAT,S7,D1

It could also be interesting to see what devices ProDOS thinks you have. Try:

CALL-151 (at the ] prompt)
BF10.BF3F (at the * prompt)

BF10..BF2F are the device driver entry points (slots 0...7 drive 1, followed by slots 0...7 drive 2).
BF31 is the number of devices, followed by the device unit numbers.
If you have a Slot 7 Drive 1 device then I'd expect BF1E /BF1F to have $C7xx and there to be a $7x device unit number in the list.

FWIW, I configured a //e system in MAME (using Ample) with a memory expansion card in Slot 7, booted into A2D, launched BW, got the prompt about copying to RAM, selected OK, and everything seemed fine.

Post by James Wages
ISTR there was a bug in the Apple II Desktop involving hitting a
softswitch that only actually did anything on the Mac card.

We fixed that a while ago. It's unclear from the repro steps given if A2D is necessary or a distraction. Glad to hear someone's trying alpha48 though!

[James Wages]

Post by Steve Nickolas
ISTR there was a bug in the Apple II Desktop involving hitting a
softswitch that only actually did anything on the Mac card.

I don't know what a "softswitch" is, but as I said in my previous message, IIe Setup version 2.2.2d1 (a Macintosh app that loads the IIe environment when the IIe Card is installed) has the freezing issue when trying to launch BeageWrite, but the slightly older version 2.2.1 does not have the BeagleWrite freezing issue.

Post by Steve Nickolas
So... do you have a RAM drive (memory expansion card) configured in your Slot 7? If not... sounds like a BW bug. If so, try disabling it, and see if the problem still occurs.

In Virtual ][ on my modern Mac, I have a virtual SCSI II card in Slot 7, which has two OmniDisks setup. Virtual ][ by default puts a 64K virtual Ramworks card into the AUX slot.

On my Color Classic Mystic with IIe Card installed, I have the IIe Option Panel configured with a virtual memory card in slot 7 (the default slot for that, which uses the Mac's RAM). Slot 5 is used by SmartPort, where I have my Omnidisks setup to boot from the aforementioned 800K disks and also ProDOS hard drive images. I removed both the Clock card in slot 2 and that virtual memory card in slot 7 and tried it again, but it still freezes.

I confirmed just now that it absolutely is not an A2D-related bug because if I download the following bootable 800K disk image of BeagleWrite only (no A2D files at all) and try it with IIe Setup v.2.2.2d1 on my Color Classic Mystic, it too shows the freezing problem:
https://macgui.com/downloads/?file_id=9171

But when I test BeagleWrite with the slightly older v.2.2.1 of IIe Setup, there is no freeze.

So why not just use v.2.2.1 instead of v.2.2.2d1? Because only v.2.2.2d1 can be used when the Color Classic's 68040 CPU is overclocked higher than 40MHz. Another reason is because it's hard to get v.2.2.1 to load without an error dialog even at lower Mac CPU clock speeds, due to some bug, which I guess Apple tried to fix in v.2.2.2d1.

Post by Steve Nickolas
It would be interesting to drop to BASIC.SYSTEM and see if Slot 7 Drive 1 behaves there, or if this is a red herring. Put BASIC.SYSTEM on your disk image, invoke it, and at the ] prompt type: CAT,S7,D1

First, please note that the IIe Option Panel (which is used by the IIe Card installed in a vintage Mac), only allows you to put the SmartPort card in slot 5, not any other slot.

Next, if I put the virtual RAMcard back into slot 7 on my Color Classic and then boot from my A2D 800K OmniDisk (which is using Slot 5), I then get to the Desktop and launch Basic.System. Then at the "]" prompt, I type:

CAT,S7,D1

Which then says:

/RAM7
NAME TYPE BLOCKS MODIFIED
DESKTOP DIR 1 10-OCT-22
BLOCKS FREE: 1543 BLOCKS USED: 505

I then typed the following at the "]" prompt:

CALL-151

It then showed me an asterisk prompt, at which I then typed:

BF10.BF3F

Which it then response with:

BF10- A3 DE A3 DE A3 DE A3 DE
BF18- A3 DE 16 C5 00 D0 4E C7
BF20- A3 DE A3 DE A3 DE 00 FF
BF28- A3 DE 16 C5 00 D0 A3 DE
BF30- 70 05 E0 60 DB 5B 74 BF
BF38- 00 00 00 00 00 00 00 00

At the time I rand that test, the IIe Option Panel was setup as follows:

Slot1: empty
Slot2: clock card
Slot3: display (operated by the Mac and cannot be changed)
Slot4: mouse card
Slot5: SmartPort card (cannot be moved to any other slot)
Slot6: 5.25" drive card
Slot7: RAM card (with 1024K assigned)

[MG]

Maybe this has nothing to do with memory and is just a bug in v.2.2.2d1. Not sure. Just wanted to report my experience as I continue to test the IIe Card in this Color Classic Mystic.

v2.2.2d1 specifically addresses issues with the LC 550/575 systems. https://archive.org/details/IIe_Startup_Vers_2.2.2d1_Desc/mode/1up. That's probably why you are not getting the the "damaged" message.

It's entirely possible that it introduces new bugs. As a developer preview it seems likely that other code may have snuck in besides the 550/575 fix.

MG

[Andrew Roughan]

Hi MG,

I see that you have put a lot of effort into trying to understand the inner
workings of the Mac LC //e card.

Are you aware of any public resource that identifies issues with the
software?
I imagine that Apple probably has an internal bug list that we are unlikely
to see.
If someone was to take a look at the source with the view to improve it,
they would undoubtedly appreciate a list of issues to consider fixing.

Eg:
I know that 2.2.2d1 has a problem with the DGR colors.
Elsewhere in this NORMFAST thread there was a disk access issue declared.

In the absence of other candidates, perhaps you would consider hosting such
a list alongside your other resources?

Regards
Andrew

[MG]

Post by Andrew Roughan
Hi MG,
I see that you have put a lot of effort into trying to understand the inner
workings of the Mac LC //e card.
Are you aware of any public resource that identifies issues with the
software?

I have not seen any. I have compiled a list of some anomalies vs a standard IIe, some of which are "as designed", the only "real" bug I've capture there is the DGR palette issue you mention below.

http://apple2.guidero.us/doku.php/mg_notes/iie_card/problem_software

Post by Andrew Roughan
I imagine that Apple probably has an internal bug list that we are unlikely
to see.
If someone was to take a look at the source with the view to improve it,
they would undoubtedly appreciate a list of issues to consider fixing.
I know that 2.2.2d1 has a problem with the DGR colors.

I believe this problem exists on all versions, but I have not verified that. As I've mentioned, it'd wonderful to have someone who is intimately familiar with 68K Mac architecture and reverse engineering take on the Mac side of the system.

Post by Andrew Roughan
Elsewhere in this NORMFAST thread there was a disk access issue declared.

I would like to see some more data on that one. The hardware configuration in that case is non-standard, it will be interesting to see if this is consistently reproducible across models, especially standard vs non-standard configuration. Perhaps this will serve as motivation to get my office cleaned up so I can get an LC set up again.

Post by Andrew Roughan
In the absence of other candidates, perhaps you would consider hosting such
a list alongside your other resources?

I'm not opposed to doing so, it is probably best done as a GitHub project, even if there is no code involved (yet). That way issues can simply be logged and commented on by anyone.

MG