Re: Auxilary Ram card programming info..

[Matt Jenkins <mdj@pacific.net.au>]

David Empson wrote:
> 
> Matt Jenkins <mdj@pacific.net.au> wrote:
> 
> > Phoenyx wrote:
> > >
> > > What I have is reference to the Zram 2c card. AFAIK, the info is
> > > the same for all Applied aux memory cards.
> >
> > I hope so - I'd hate to see what I'm working on not work in a //c.
> > On a similar note, does the //GS use the same system in emulation
> > mode ?
> 
> Partly.  The IIgs does emulate auxiliary memory, but only a single bank.
> Don't try to use $C073 as a bank select register - it is code in the
> IIgs (part of the interrupt handler).

OK - so the extended memory is only available in native mode on the
//GS.

> The IIgs can directly address its entire 16 MB address space by using
> long addressing modes, which are available in both native and emulation
> mode, so it doesn't need bank switching, except for compatibility with
> 8-bit machines.

OK - obviously I've come off somewhat more ignorant than I am. I aware
of
the functionality of the 65816 vs. the 65({c|8})02, although I'm only 
experienced in 6502 assembly programming, not 65816.

> > OK - I thought it'd be this simple. I think I'll still need the //e
> > technical reference to find out more about interrupts etc. in aux.
> > memory. Oh, do the same trick and limitations apply when using
> > the auxiliary bank "language card" as they do with aux. bank 0 ?
> 
> I'm not quite sure what you're referring to here, so I'll provide too
> much information.  :-)
> 
> I see you already know about RAMRD/RAMWR, and presumably you know about
> 80STORE.  There is one more softswitch of relevance here:

Yes, turn on 80store and hit the page 2 switch and you bank in $400-7FF
if I remember right. Also, if hires/double-hires is active you also get
$2000-$3FFF.

> AUXZP           Selects main or auxiliary memory for both reading
>                 and writing in $0000-$01FF (zero page and stack)
>                 and $D000-$FFFF (language card).
> 
> The AUXMOVE and XFER routines in page 3 only deal with the AUXRD and
> AUXWR switches, i.e. they can only handle the main 48K area.  You have
> to use your own code to handle auxiliary zero page, stack and the
> language card area.

Ah, this is the bit all the articles I read a few years back left out. I 
discovered the AUXZP switch somewhere else and used it, but I wasn't
aware
that it actually banked in the language card too.
 
> If you are dealing with a multi-bank card, $C073 selects the active RAM
> bank for all of auxiliary memory.
> 
> If you switch ZP/stack/language card to auxiliary memory, then you may
> have to deal with the interrupt vectors ($FFFA to $FFFF).  A multi-bank
> version extends the problem to other banks as well.

Yep, I know that $FFFA is the NMI vector - do I ever have to worry about
this?
Presumable $FFFC will get handled when someone ctrl-resets the box.
$FFFE is interrupt/break.
 
> Note that the IIgs always fetches its vectors from ROM, so you only have
> to deal with this on the IIe and IIc.

Now that's interesting. Looks like I'm writing //e-//c specific software
then :)
 
> There are also conventions for dealing with the stack pointer in main
> and auxiliary memory.  The two stacks are supposed to be independent,
> and the stack pointers and supposed to be saved and loaded in memory
> locations $0100 and $0101 in auxiliary memory (I'd have to dig out a
> manual to confirm which way around they go).

Is there a ROM routine that handles this ?
 
> There are no conventions that I know of for dealing with stacks in
> multi-bank auxiliary slot RAM cards.

I figured there wouldn't be. I guess I'd get more helpful information if
I
explained what I was trying to do...

The idea was to write a quasi-OS on top of ProDOS that provided a
console driver
and extra I/O routines so that a program could run totally in one of the
extended
RAM banks - there it could theoretically use $400-$BFFF, $D000-$FFEF for
it's
own use, which is quite a lot of memory. There'd be some spiffy routines
somewhere
in the $200-$3FF range in the aux bank the program ran in to provide the
system
call mechanism.

That's my starting point anyway. The next step would be to use the reset
vector
to provide a way to break back to the 'OS' and load another program -
thus you
could have task switching.

I'm not really setting out to write the next great OS for 8 bit Apple
II's, but
if I can get this going, who knows.

If there's any glaring holes in my theory I should know about, please
let me know.
It's a very good thing to have someone so knowledgeable about the Apple
II 
archictecure around.

Cheers,

Matt