daveharv@pro-novapple.cts.com (Dave Harvey-SysAdmin) (05/15/91)
I'm looking for info on where Appletalk resides in memory. I'm running an
8-bit program, Family Roots, on an Apple IIGS with ProDOS 1.9. The program
also uses Beagle Bros Extra Variables program. Unfortunately the program
is incompatible with Appletalk and bombs. I would like to use the
Imagewriter emulation on a laserprinter for printing out the reports.
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.
proline: pro-novapple!daveharv |
uucp: crash!pnet01!pro-novapple!daveharv | Pro-novapple BBS
arpa: crash!pnet01!pro-novapple!daveharv@nosc.mil | 300/1200/2400/9600 Baud
Internet: daveharv@pro-novapple.cts.com | 703-671-0416
|
Northern Virginia Apple Users Group |
P.O. Box 8211, Falls Church, VA 22041 |toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/16/91)
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
dlyons@Apple.COM (David A. Lyons) (05/17/91)
In article <1991May16.095217.5951@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >[...] >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 Disabling interrupts is overkill (but if it's only for short times and for a small fraction of the time, it will work). All you *need* to do is follow the main/aux stack pointer rules as documented in the IIe Technical Reference Manual, the Apple IIgs Firmware Reference Manual, and probably other places too. In short, the main-memory stack pointer is stored at $0100 in aux mem whenever the aux stack is in use, and the aux-memory stack pointer is stored at $0101 in aux mem whenever the main stack is in use. If you use the AUXMOVE and XFER routines in the 80-column firmware, stack switching is automatically taken care of for you. The interrupt handler does all the appropriate "jerking around"--when it has to switch to the main stack from the auxiliary stack, is sets the stack pointer from the auxmem $0100 location. If you have failed to set this value, the interrupt handler winds up overwriting part of the stack you were using, since it had no way to know which part you were using. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dlyons@apple.com My opinions are my own, not Apple's.