💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › Accelerators … captured on 2023-01-29 at 07:40:46.
-=-=-=-=-=-=-
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