Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!ogicse!usenet!jacobs.CS.ORST.EDU!parkern
From: parkern@jacobs.CS.ORST.EDU (Neil Parker)
Newsgroups: comp.sys.apple2
Subject: Re: Quadram APIC-A //e compatibility & code debugging
Summary: The perils of calling unpublished monitor entry points
Message-ID: <1991Mar30.131325.24160@lynx.CS.ORST.EDU>
Date: 30 Mar 91 13:13:25 GMT
References: <50a3ec40.20b6d@apollo.HP.COM>
Sender: @lynx.CS.ORST.EDU
Reply-To: parkern@jacobs.CS.ORST.EDU (Neil Parker)
Organization: The Universal Society for the Prevention of Reality
Lines: 51
Nntp-Posting-Host: jacobs.cs.orst.edu

In article <50a3ec40.20b6d@apollo.HP.COM> mort@apollo.HP.COM (Stephen Moriarty) writes:
>I have an APIC-A parallel interface card. [...]
>                                                         If I do
>]pr #1, I get what I type on the printer, but I get a dump of
>some memory address, as though I was in the monitor, following
>the first character I type at the ] prompt, and following a
>RETURN. Is the APIC-A compatible with the enhanced //e? The EPROM
>has a label marked, "APIC-A c.1983".

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.

(Moral:  Never call unpublished entry points in the ROM.)

While I can't guarantee that this is the cause of your problems, I suspect
it's probably worth adding to your list of possible causes.

>Failing that, I'd like to debug the firmware. I've listed it out
>from the Apple monitor. If I had a printer interface, I could get
>a hardcopy ;(. I'm reading the chapter on the monitor in the //e
>Technical Reference Manual, but don't see anything about single
>stepping, or setting breakpoints.

Unfortunately, Apple took out the built-in step and trace functions when
they introduced the Apple ][+, and they've never been put back in (the
Apple IIGS monitor has the "s" and "t" commands restored to it, but there's
no built-in code for them--you have to supply your own stepping and tracing
routines).  If you insist on tracing the code, I would probably recommend
getting a debugger.

>ARPA: mort@apollo.hp.com        UUCP: ...{decvax, umix, mit-eddie}!apollo!mort

               - Neil Parker
--
Neil Parker                 No cute ASCII art...no cute quote...no cute
parkern@jacobs.cs.orst.edu  disclaimer...no deposit, no return...
parker@corona.uoregon.edu   (This space intentionally left blank:           )