Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!tektronix!reed!kamath
From: kamath@reed.UUCP (Sean Kamath)
Newsgroups: comp.sys.apple
Subject: Re: Apple //c Resets
Message-ID: <9066@reed.UUCP>
Date: 26 Apr 88 04:42:31 GMT
References: <8804200757.AA17542@crash.cts.com>
Reply-To: kamath@reed.UUCP (Sean Kamath)
Organization: Reed College, Portland OR
Lines: 34

In article <8804200757.AA17542@crash.cts.com> pnet01!pro-angmar!tmetro@nosc.MIL writes:
>
> [stuff on resets on a //e]
>Does anyone know if the hardware that controls the bank switching on a //c
>gets reset with the RESET signal?
>It must not on a //e for this to work...
>Is the $D000-$FFFF bank switched RAM contained on the motherboard of the //e?
>This article gave me the impression that it was located on a card, but maybe
>that refers to an unenhanced //e.
> 
>Thanks.


Well, I'm not sure about this. . . Ican dig it up, if anyone cares.
BUT:  on a //c, it "knows" that no card with ROM will be in slot 3.  On a
//e, this is not the case.  From what I recall, you *may* be able to do what
you want on a //e, maybe when I log off I'll try it.  BUT:  Not on a //c.
Since the //c generally has a fixed set of slots, it's interrupts are
vectored straight tothe 80 column firmware.  Note that on a //e, having the
80column card does not mean anything in the way of the firmware.  The
firmware is on the motherboard.

Unfortunately, I cannot give a very good discription of the interrupts on
the //e right now.  I left my ref.  manual at the ski cabin, and haven' been
able to go there for two months. . . I've made do with the //c one, but it
is different in a few respects, and this is one of them. . .

Sean Kamath

-- 
UUCP:  {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: reed!kamath@PSUVAX1.BITNET
ARPA:  reed!kamath@psuvax1.arpa
US Snail: 3934 SE Boise, Portland, OR  97202-3126 (I hate 4 line .sigs!)