Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!dempson
Newsgroups: comp.sys.apple2
Subject: Re: AppleTalk / Interrupts / ProDOS 8 / DOS 3.3 Launcher
Message-ID: <1993Apr7.131811.24120@actrix.gen.nz>
From: dempson@swell.actrix.gen.nz (David Empson)
Date: Wed, 7 Apr 1993 13:18:11 GMT
Sender: dempson@actrix.gen.nz (David Empson)
References: <1993Apr5.230256.29920@fawlty.towers.oz.au> <1993Apr6.102728.9500@actrix.gen.nz> <1993Apr7.001936.28618@fawlty.towers.oz.au>
Organization: Actrix Information Exchange
Lines: 86

In article <1993Apr7.001936.28618@fawlty.towers.oz.au> johnmac@fawlty.towers.oz.au (John MacLean) writes:
>David Empson writes:
> >
> >ProDOS-8 itself isn't involved in handling AppleTalk interrupts on the
> >IIgs.  They are handled by the IIgs interrupt firmware.  Patching this
> >will achieve nothing except give you a headache trying to reinvent the
> >wheel.
> 
> I swap the global page into its proper place $BF00..$BFFF when I make
> a ProDOS MLI call, so having interrupts enabled at this point is not
> a problem [and I now know that I definitely need to].
> However, what happens when the ProDOS global page is not in place?
> I know now that I cannot disable interrupts for a long period (even
> when I'm not making ProDOS calls), so the interrupts must be handled.
> 
> The ProDOS global page (as defined in Beneath Apple ProDOS), has
> various interrupt vectors, etc. This tends to indicate that processing
> of an interrupt needs the global page to be in place.
> Is this the case?

Yes.  The interrupt vector at $03FE points into the ProDOS global
page.  The code there switches in the language card and jumps to the
main part of the ProDOS interrupt handler.

On a IIgs, the $03FE vector is only used if the interrupt is not
handled by one of the IIgs's built-in interrupt handlers.  This
includes AppleTalk interrupts, which don't involve bank 0 at all.  So
in theory, you don't need the global page to handle an AppleTalk
interrupt.

I believe the AppleTalk firmware uses a bank $E1 vector for all of
its internal calls, but it is also possible to call AppleTalk via the
MLI entry point (using command code $42).  As this can only be done
from bank zero, and there won't be any AppleTalk code lurking in bank
zero, I don't think AppleTalk will be using this method itself.

> Does an Appletalk interrupt go through any other RAM vectors in bank 0
> (specifically, in page 3)?

Anything for which you'd have to install a ProDOS interrupt handler
would go through the $3FE vector.  This is basically limited to
slot-based cards that use IRQ.  All the IIgs's built-in interrupt
sources are handled without calling $3FE.

> If they do, then DOS 3.3 initialisation is likely to patch this vector
> (I think - I can check this).

Yep, DOS 3.3 cold start initializes $3D0-$3FF.  I hope you're saving
and restoring this area (at least $3F0-$3FF).


Just to repeat myself in detail, here is the sequence of events when
an IRQ occurs on the IIgs.

1. Interrupt vector fetched from ROM at $00FFFE-00FFFF or
$00FFEE-00FFEF, depending on processor mode.  Note that this vector is
always fetched from the ROM, even if the language card is switched in.

2. The vector points into $00C071-$C07F area, which jumps to $E10010
(the master IRQ vector).  This normally contains a JML instruction to
the ROM-based interrupt handler.

3. The ROM-based interrupt handler saves a few things, then checks for
AppleTalk and Serial interrupts.  If one of these has occurred it is
handled, and normal execution resumes.

4. The interrupt handler saves the current machine state, switches
into a known state, then checks all the other IIgs built-in interrupt
sources.  If one of these is active, it is handled and normal
execution resumes.

5. If none of the built-in interrupt sources were active, and the
"other interrupt" handler (used by GS/OS) doesn't claim the interrupt,
then the processor is switched to emulation mode, and an IRQ is faked,
going through the $3FE vector.  This normally points to the ProDOS-8
or ProDOS-16 interrupt handler.  After the interrupt has been dealt
with, the handler does an RTI, which returns to the ROM interrupt
handler.  The machine state is restored and normal execution is
resumed.


I think that about covers it.
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz    <--- Note my new E-Mail address!            
Snail mail: P.O. Box 27-103, Wellington, New Zealand