NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/apple2/20438

Text File | 1992-09-14 | 5.2 KB | 91 lines

Newsgroups: comp.sys.apple2
Path: sparky!uunet!sun-barr!ames!data.nas.nasa.gov!mustang.mst6.lanl.gov!nntp-server.caltech.edu!toddpw
From: [e-mail] (Todd P. Whitesel)
Subject: Re: Accelerator stuff
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: punisher
Organization: California Institute of Technology, Pasadena
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 15 Sep 1992 09:31:06 GMT
Lines: 78

[e-mail] (Matt Deatherage) writes:

>The Zip's "timers-only" system means you can't be sure your timing-sensitive
>code works correctly unless you hit a softswitch that triggers a timer in
>the code at the appropriate intervals, or unless you explicitly turn off
>the Zip.  Either way requires modifying existing timing-sensitive code, and
>this was not a good idea.

Matt, you alone are able to take the engineering principle behind something and
make it sound like it's the fundamental problem with it. AppleTalk and ProTerm
(and imitation FTA demos, but they don't count) are the only things that really
had problems, and then only at higher speeds that nobody had until Zip was
about to ship the ZipGS. If Zip had added the SCC to their list of 5ms delays,
none of this would ever have come up. But at the time, NO testing uncovered any
problems, and Zip very reasonably wanted to accelerate interrupt processing
as much as possible.

>The TWGS's "AppleTalk/IRQ" option slows down to Control Panel speed (2.5 or
>1 MHz) whenever interrupts are disabled.  This has the advantage of making
>_all_ timing sensitive code work as advertised, because anyone writing
>timing-sensitive code knew they had to disable interrupts already.

Okay, but there is a lot of code that disables interrupts that really ought
to be accelerated. Ask the GNO folks how much IRQ processing overhead the IIgs
has and you'll get retching noises for an answer.

>It might slow down somewhat, but it's a darn sight better than Zip's
>"AppleTalk delay" which slows the accelerator down about 30% of the time
>(5 ms for every interrupt, incluing the 60 Hz VBL interrupt, which means
>a minimum of 300 ms slowdown every second).  It also wouldn't have forced

Zip has never tried to hide the fact that the AppleTalk delay was a last
minute kludge to make things work. 7 mhz is the first speed at which problems
with AppleTalk show up, and Zip says that all their beta testing had to be
done at 6.25 mhz (just like AE) because WDC could not deliver faster parts
until shortly before they shipped. I figured this out the hard way (i.e. using
my new Zip with the Caltech AppleTalk network) and Zip read me the necessary
programmers' info over the phone so I could start working on a fix. The first
version of ZipTalk only worked up to about 9mhz/32K, but the last version
(which should be cleared on GEnie by the time you read this) works PERFECTLY.
The whole point of ZipTalk was to eliminiate any need for the "AppleTalk Delay"
and its performance hit.

>Apple to waste time rewriting the internal LocalTalk code to be speed
>dependent at 1 MHz instead of 2.5 MHz, requiring more patch memory on ROM
>3 and time that could have been spent on more productive things.

The LocalTalk code should have been 1-mhz based in the FIRST place. Apple
warns developers not to write code that is timing dependent at 2.5 mhz;
the least Apple can do is write code that follows its own guidelines. Besides,
it couldn't cost _that_ much in engineering time unless the source was totally
screwed up. Just looking at it with Orca/Disassembler and an SCC manual I was
able to pinpoint the primary patch locations and the majority of the loop
constants. With the actual source I don't think it would have taken ME very
long at all, so it had to be EASY for somebody at Apple unless the guy who
wrote the original code was a _complete_moron_ and I can't believe _that_.

>(And no, ZipTalk alone or the code I wrote that did the same thing and
>sent to Zip a long time ago wouldn't have fixed it -- LocalTalk has to
>send a "clear to send" packet as soon as it sees a "ready to send"
>packet, and that's all done in the interrupt handler without dispatching
>to the LAPRead or LAPWrite commands -- and patching out the interrupt
>vector to slow down before doing it is not supportable or feasible due
>to extreme AppleTalk timing constraints.)

What LAPRead command? $e1/20 does that. ZipTalk intercepts it (VRN #8) with:
    LDA $E0C0FC    ;slot 7 is set to Normal speed (it can also use 6)
    JMP $02AEFD    ;typical value, this passes to the original handler
This adds 9 cycles (1 slow) to the AppleTalk IRQ manager and disables the Zip
for 50 milliseconds, more than long enough for an entire LLAP packet. You may
have noticed that not only is fully disabling the Zip too slow to do here, but
that any attempt to get the 5.0.4 AppleTalk manager to return control via the
IRQ manager convention documented in the IIgs Firmware Ref will FAIL if a
packet is received -- so there is no point in doing that anyway because you
cannot get control back without totally rearranging the stack (ick).

Todd Whitesel
toddpw @ cco.caltech.edu