From: mattd@apple.com (Matt Deatherage)
Newsgroups: comp.sys.apple2
Subject: Re: Accelerator stuff
Date: 16 Sep 92 00:11:24 GMT
Followup-To: comp.sys.apple2
Organization: Developer Technical Support, Apple Computer, Inc.

In article <1992Sep15.093106.13133@cco.caltech.edu>, toddpw@cco.caltech.edu
(Todd P. Whitesel) wrote:

> 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 [...]

I think it was a fundamental problem -- Zip didn't know how long to slow
down for timing-sensitive code, so rather than do so all the time they
chose two "guess" values -- 5 ms and 50 ms.  This is probablistic rather
than deterministic, as the TWGS approach is.  I like deterministic.

> 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.

Yes, but that's just how Jawaid talks.  :)  [see below for a more concrete
discussion of this]

> 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. 

Let's not bring out that chestnut.  Compatibility guidelines are so
3rd-party
developers can stay compatible with the system software -- the system
software
itself can (and often does) have to do skanky things to work.  Being
timing-
dependent at 2.5 MHz is not a problem for Apple as long as Apple would
commit to rewriting it if the processor speed changed; 3rd-party developers
can't reasonably make such commitments (business plans change).

This is like saying "QuickDraw breaks the rules because it has hard-coded
knowledge of QuickDraw's direct page."  The system software can do as it
pleases in order to function.  Guidelines keep you compatible with it and
it with you, not it with itself.  That's done at another level.

> 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.

Assuming, of course, that you get to $E10020 within 104 microseconds of
when the first byte of the packet was detected by the SCC.  If interrupts
were already disabled when that happened, you have even less time.

And Apple's original timing tests in the late 80s showed that there was
room in the interrupt chain to add one, _maybe_ two instructions in this
code path before AppleTalk might lose data, and therefore reject packets.
You've added extra instructions in this chain, and if the system had
interrupts disabled when the packet started arriving, or if it was already
in 1 MHz mode, now you may miss the packet altogether.  This has much
more effect on a crowded network than on a typical "home" network, but
it doesn't work in 100% of the cases and is not supportable.

Your method also requires slowing down one slot, which is kind of icky
but not too much so.

All LLAP packets dispatched _except_ the previously-mentioned RTS/CTS pair
go through the LAPRead/LAPWrite AppleTalk command vectors as documented
in the Programmer's Guide.  Patching those vectors to fully disable the
Zip at start and reenable it at end avoids all the problems except the
RTS/CTS problem, and it does so _deterministically._  None of this "All
LLAP
packets should take less than 50 ms" -- it disables on start and enables
on finish, no matter how long the interim is.  Your technique would work OK
for the RTS/CTS packets sent from the IRQ.APTALK interrupt handler, save
the problems previously mentioned about making the dispatching code take
too long.  One could reasonably argue that the odds of this being a problem
are small enough in an accelerated system, but it's still going to cause
problems for people with large networks.

\============================================================================
Matt Deatherage, Developer Support Center, Apple Computer, Inc.
Personal mail only -- please POST technical questions, questions about
Apple and its policies, where to find documents and related inquiries.
The opinions I express don't represent Apple, which makes us both happy.
============================================================================