Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Appletalk memory locations
Message-ID: <1991May16.095217.5951@nntp-server.caltech.edu>
Date: 16 May 91 09:52:17 GMT
References: <0.netnews.info.apple@pro-novapple>
Organization: California Institute of Technology, Pasadena
Lines: 24

daveharv@pro-novapple.cts.com (Dave Harvey-SysAdmin) writes:

>When I explained my problem to the developer of Family Roots, he asked what
>portions of memory does Appletalk use?  I couldn't answer the question even
>after reading all the Apple Technical Notes on Appletalk.  Couldn't find any
>reference to memory locations in them.  If I had the answer to that question,
>the developer could tell right away if he could solve the problem readily.

AppleTalk on the GS does not occupy any memory needed by 8 bit programs
(except some patches to Prodos). What is probably killing you is the same
thing that kills Tim Meekins' "Spinning Z" demo -- using //e methods to
access the extra 64K without temporarily disabling interrupt services
(mainly AppleTalk packet reception in this case) causes a system crash the
instant a packet comes in, because the AppleTalk drivers can't handle it.
The interrupt manager jerks around enough before it gets around to polling
AppleTalk, I would have thought it'd take care of this, but apparently not.

In short, if my guess is right, what the developer needs to hear is that
the auxiliary memory routines need to set interrupts temporarily. I've had
to do this with my own code; perhaps DTS can shed some light on the exact
switches so you can tell the developer exactly what to look for.

Todd Whitesel
toddpw @ tybalt.caltech.edu