Discussion:
NORMFAST - set normal or fast speed on the IIGS, //c+ and hopefully FASTChip
(too old to reply)
r***@gmail.com
2017-08-26 15:33:56 UTC
Permalink
Raw Message
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
2017-08-26 15:52:15 UTC
Permalink
Raw Message
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
2017-08-26 16:19:55 UTC
Permalink
Raw Message
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
r***@gmail.com
2017-08-26 22:08:01 UTC
Permalink
Raw Message
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
2017-08-27 06:54:09 UTC
Permalink
Raw Message
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!
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
r***@gmail.com
2017-08-27 17:32:38 UTC
Permalink
Raw Message
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
2017-08-27 18:54:20 UTC
Permalink
Raw Message
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
2017-08-28 01:59:20 UTC
Permalink
Raw Message
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
2017-08-28 02:29:16 UTC
Permalink
Raw Message
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
2017-08-29 01:25:59 UTC
Permalink
Raw Message
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
2017-08-29 01:16:56 UTC
Permalink
Raw Message
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
2017-08-29 01:29:33 UTC
Permalink
Raw Message
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
2017-08-29 02:13:18 UTC
Permalink
Raw Message
Oh cool, my test case was 300L, ahem
I tested again with yours: same duration, so something is wrong!
r***@gmail.com
2017-08-30 04:47:13 UTC
Permalink
Raw Message
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
2017-09-04 06:45:47 UTC
Permalink
Raw Message
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
2017-08-29 23:15:09 UTC
Permalink
Raw Message
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
2017-08-30 04:59:34 UTC
Permalink
Raw Message
... 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
2017-08-30 07:04:04 UTC
Permalink
Raw Message
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
I am Rob
2017-08-30 18:17:42 UTC
Permalink
Raw Message
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
2017-08-30 18:24:07 UTC
Permalink
Raw Message
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 am Rob
2017-08-31 03:11:55 UTC
Permalink
Raw Message
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
2017-08-31 05:30:40 UTC
Permalink
Raw Message
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 - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Michael J. Mahon
2017-08-31 17:46:06 UTC
Permalink
Raw Message
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
MG
2017-09-01 03:49:23 UTC
Permalink
Raw Message
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
2017-09-01 05:28:18 UTC
Permalink
Raw Message
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! ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
MG
2017-08-30 23:56:54 UTC
Permalink
Raw Message
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
2017-08-31 04:00:38 UTC
Permalink
Raw Message
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
2017-08-27 17:29:00 UTC
Permalink
Raw Message
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
2017-09-03 03:51:22 UTC
Permalink
Raw Message
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
2017-09-03 16:18:31 UTC
Permalink
Raw Message
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
2017-09-03 17:07:33 UTC
Permalink
Raw Message
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
2017-09-05 20:03:22 UTC
Permalink
Raw Message
[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
2017-09-05 20:09:36 UTC
Permalink
Raw Message
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
2017-09-06 03:36:14 UTC
Permalink
Raw Message
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
2017-09-07 00:49:09 UTC
Permalink
Raw Message
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
2017-09-05 20:39:44 UTC
Permalink
Raw Message
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
2017-09-05 22:05:00 UTC
Permalink
Raw Message
I'd like to get a copy of rom files for the A2 documentation project, please

av
r***@gmail.com
2017-09-07 00:38:48 UTC
Permalink
Raw Message
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
2017-09-05 19:50:34 UTC
Permalink
Raw Message
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
2017-09-05 18:07:23 UTC
Permalink
Raw Message
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
2017-09-05 19:19:59 UTC
Permalink
Raw Message
typo: "You'll see, you have NO way of detecting it but it is easy to turn it off or on. "
r***@gmail.com
2017-09-05 19:57:02 UTC
Permalink
Raw Message
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
2017-09-05 20:35:18 UTC
Permalink
Raw Message
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
2017-09-06 05:41:40 UTC
Permalink
Raw Message
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
2017-09-07 00:43:00 UTC
Permalink
Raw Message
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
2017-09-07 00:51:55 UTC
Permalink
Raw Message
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
2017-09-07 02:20:31 UTC
Permalink
Raw Message
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
2017-09-07 16:07:34 UTC
Permalink
Raw Message
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
2017-09-07 16:19:33 UTC
Permalink
Raw Message
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
2017-09-09 16:08:06 UTC
Permalink
Raw Message
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
2017-09-09 15:59:23 UTC
Permalink
Raw Message
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
2017-09-10 19:47:30 UTC
Permalink
Raw Message
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
2017-09-11 02:18:59 UTC
Permalink
Raw Message
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
2017-09-11 16:59:46 UTC
Permalink
Raw Message
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
r***@gmail.com
2017-09-09 15:55:12 UTC
Permalink
Raw Message
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
2017-09-09 16:43:22 UTC
Permalink
Raw Message
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
MG
2017-09-26 17:07:24 UTC
Permalink
Raw Message
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
2017-09-29 00:38:46 UTC
Permalink
Raw Message
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
2017-09-29 16:20:18 UTC
Permalink
Raw Message
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
2017-10-04 21:26:02 UTC
Permalink
Raw Message
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
2017-10-06 02:45:15 UTC
Permalink
Raw Message
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
2017-10-06 15:43:19 UTC
Permalink
Raw Message
Were my recent suggestions not acceptable?

Loading...