Path: news.uiowa.edu!news.uiowa.edu!uunet!in1.uu.net!news.sprintlink.net!simtel!lll-winken.llnl.gov!fnnews.fnal.gov!nntp-server.caltech.edu!toddpw
From: toddpw@liquefy.ugcs.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Processor Speed on a 65816
Date: 24 Aug 1995 12:12:39 GMT
Organization: California Institute of Technology, Pasadena
Lines: 49
Message-ID: <41hqbn$p9l@gap.cco.caltech.edu>
References: <41eqss$d9@gap.cco.caltech.edu> <41gtci$llh@nexus.uiowa.edu>
NNTP-Posting-Host: liquefy.ugcs.caltech.edu
X-Newsreader: NN version 6.5.0 #14 (NOV)

snelson@news.uiowa.edu (Steven Nelson) writes:

>Todd, why should everyone have Appletalk delay disabled with a ZipGS?

Because it saps performance every time an interrupt occurs.

The Appletalk delay was originally called the "Interrupt Delay" but they
renamed it at the last minute because somebody actually tried an 8/64 on
an Appleshare network and it dropped packets like crazy.

With "Appletalk delay" on, every time an interrupt occurs your Zip will
disable acceleration for 5 ms, just like it does with the paddles and the
speaker and the others. This is a significant effect because with VBL
interrupts going you have one every 16 ms, so your Zip spends nearly 1/3
of the time not accelerating you.

Why this "fixes" appletalk: in system 5 and earlier (including the ROM
appletalk code), there are software timing loops which assume 2.8 mhz
operation. As you speed the system up, it gets more and more likely to
drop incoming packets because it thinks they are being sent too slowly
to be correct, when in reality the appletalk code is timing out too fast.

Why the Appletalk delay is not a complete solution: a full-size Appletalk
packet that you'd get from a file server takes about 14 ms to transmit.
The Appletalk delay covers the first 1/3 of the packet, the VBL interrupt
covers at most another third of the packet, but nothing is guaranteed to
keep acceleration off for the whole packet. If you speed the Zip up more,
say to 10/64, it starts dropping long packets no matter what.

This latter problem was why I originally wrote ZipTalk. It required a slot
delay to be enabled (in, say, slot 6 or 7), and before each appletalk packet
was received I tweaked that slot -- slot delays are 50 ms, so the Zip stays
unaccelerated way past the end of the packet and everything works. (I also
patched packet sending, to be safe.)

In system 6 Apple fixed things correctly in the appletalk drivers. I removed
the code from ZipTalk and released what remained as ZipFix. As of 6.0.1, the
cursor flicker problem was fixed by apple in the control panel, so now you
only need ZipFix for the GS/OS SET_SYS_SPEED hook, which nobody seems to use.

>change the AppleShare one to start up normal speed, and have the init (?cdev)
>turn on the Zip AFTER bootup started.)  Thanks for any info you can share

This is typical, because the bootup code doesn't know how to cope with the
ZIP. Once you have system 6's appletalk drivers loaded, you don't need the
special ZIP settings any more.

Todd Whitesel
toddpw @ ugcs.caltech.edu