Re: AUX memory question

[dempson@actrix.gen.nz (David Empson)]

Matthew Russotto <russotto@wanda.pond.com> wrote:

> In article <XN1l6.3027$7e6.1254088@homer.alpha.net>,
> Dennis Jenkins  <dennis@usb.com> wrote:
> >Hello,
> >     I know that I can use the soft switches $c002 through $c005 to
> >control if an I going to read or write to the 48K main/aux memory, but how
> >do I gain access to the upper 16K of AUX memory (and then re-gain access
> >to the upper 16K of normal memory)?  I think the answer in the the address
> >range of $c080 through $c08f, but I don't understand what each of those
> >soft switches _really_ does.  I know that ProDOS lives in one of those
> >upper banks, and I have to be careful not to trash it.
> 
> Any reason you have to use PRODOS?  DOS 3.3 has a smaller footprint.
> I don't think 8-bit Prodos uses any of the auxiliary memory, including
> the language card space, but I'm not certain.

ProDOS uses most of auxiliary memory for its /RAM volume.  There are
documented procedures for disconnecting /RAM if you want to use
auxiliary memory for other purposes.  You don't get to use all of it,
but most is available.

There are some system software components that make use of parts of
auxiliary memory for other purposes.  In these cases, /RAM will not be
available, and applications have a tighter restriction on available
auxiliary memory.

See TN.PDOS.026 (Polite Use of Auxiliary Memory) for details.

> >     (I know about the AUXMOVE API found at $c311.  That isn't exactly
> >what I want.  I need faster access to AUX memory, as I am using it to
> >store hash tables.  AUXMOVE is way to slow.  I am writing my own custom
> >AUX memory access functions.  I store them in the upper part of zero page.
> >My code has nothing to do with BASIC.SYSTEM, so I'm not worried about
> >basic trashing my work areas.)
> 
> >     I currently have working code that lets me read/write single bytes
> >(at a time, exactly what I want) to AUX range $0200 through $bfff.

The aforementioned technote says that auxiliary memory locations below
$0800 are permanently reserved for use by the system software.  With
reference to the ProDOS-8 Technical Reference Manual: $0200-$03FF and
$0080-$00FF are used by ProDOS, and $0000-$007F are left free for
application use.  $0100-$01FF is the stack, of course, and $0400-$07FF
is the auxliary half of the 80-column text screen.  (The screen holes in
this area must be preserved.)

If /RAM is present and is disconnected in accordance with the documented
procedures, then your application is allowed to use all auxiliary memory
locations $0800 and higher.

If /RAM is not present when your application is launched, you must
respect the reserved areas of auxiliary memory: $BF00-$BFFF, $D100-$DFFF
in language card bank 2, and $E000-$FFFF.

> >I want to be able to handle $c000 through $fffc.  Can I safely write
> >random data to AUX $fffe,$ffff?

No.  This is the IRQ vector.  If you are running on a IIe or IIc, this
vector must be set correctly or an IRQ or a BRK instruction will crash
the machine.  (The IIgs always fetches its interrupt vectors from ROM.)
Similarly, FFFA-FFFB is the NMI vector, but NMI is very rare.

The unenhanced IIe cannot handle IRQ with auxiliary memory active,
unless the code using the auxiliary language card has its own code to
deal with it (pointed to by FFFE-FFFF).  On the IIc and enhanced IIe,
the IRQ vector should point to the same location as the ROM vector (the
primary interrupt handler is in the $C3xx space for the enhanced IIe,
somewhere else in the $Cxxx space for the IIc).


A related point: there are conventions which must be followed regarding
the main and auxiliary stacks if you are going to use the ALTZP switch.

Memory locations $0100 and $0101 in auxiliary memory are used to store
the main and auxiliary stack pointers.  The two stacks are independent.

Your application's initialization code should set auxiliary memory
location $0101 to $FF.  Subsequently, when switching from main to
auxiliary memory (ALTZP switch), you must store the stack pointer at
$0100 and load it from $0101.  Before switching back to main memory,
store the stack pointer at $0101 and load it from $0100.  Interrupts
must be locked out during initialization of these variables and during
the bank/stack switch sequence.

If you break these rules, you are likely to get stack corruption when an
interrupt occurs, because the firmware and operating system expect these
locations to be valid if the auxiliary stack is used.

> >I am not bothering to write to AUX $0000 through $01ff.
> 
> I think you may have a problem because your auxiliary memory routines
> are in the zero page, and IIRC the same switch (ALTZP) switches the zero
> page and the language card.

Correct.

> Maybe you could use AUXMOVE to copy your routines (or parts thereof) over to
> the alternate zero page.

That won't work.  AUXMOVE only supports the $0200-$BFFF area, as it uses
the RDBANK/WRBANK switches.  If you want to move data into the auxiliary
zero page, stack or language card, you need to use your own code, which
runs in the $0200-$BFFF area of whichever bank is active, and uses the
ALTZP switch to enable the desired bank.

> I don't see why you couldn't write to AUX FFFE, FFFF -- the reset hardware
> automatically switches to the main page, so it won't use the auxiliary
> reset vector.

The reset vector is FFFC/FFFD, not FFFE/FFFF.