Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!mturner
From: mturner@convex.com (Mike P. Turner)
Newsgroups: comp.sys.apple2
Subject: Re: Quadram APIC-A //e compatibility & code debugging
Message-ID: <1991Apr02.223712.13868@convex.com>
Date: 2 Apr 91 22:37:12 GMT
References: <50a3ec40.20b6d@apollo.HP.COM> <1991Mar30.131325.24160@lynx.CS.ORST.EDU>
Sender: news@convex.com (news access account)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 25
Nntp-Posting-Host: pixel.convex.com

>I have never owned (or even seen) an APIC-A parallel interface card, but
>your problem sounds familiar anyway.  It seems that back when my mother
>upgraded the old Apple ][+ to a //e, her parallel interface card (a Tymac
>PPC-100) suddenly started spewing garbage (which looked like monitor dumps)
>at seemingly random intervals.  The reason turned out to be that the Tymac
>was incompatible with the //e ROMs.
>
>It seems that a common technique used by interface cards to find out what
>slot they're in is to call an RTS instruction in the monitor and examine
>the return address that the JSR pushed onto the stack.  Apple guarantees
>that there will always be an RTS at $FF58 for this very purpose.
>Unfortunately, the Tymac doesn't call $FF58--it calls $FDFF instead.  On
>the Apple ][+ there was an RTS at $FDFF, so everything worked just fine.
>However, on the enhanced //e, that RTS was replaced with some other
>instruction (I think it was a NOP), so instead of returning execution fell
>through to $FE00, which is part of the monitor's memory dump routine.
>
I had the same problem with a TYMAC card when I upgraded my ][e.  I had
to modify the code and then create a new eprom.  If someone is having
similiar problems I'd be willing to try to fix their printer card.  If
interested send me some email at mturner@convex.com.

Mike Turner mturner@convex.com
Convex Computer Corporation
214-497-4834