AUX memory question
Dennis Jenkins
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.
(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. I want
to be able to handle $c000 through $fffc. Can I safely write random data
to AUX $fffe,$ffff? I am not bothering to write to AUX $0000 through
$01ff.
Matthew Russotto
Dennis Jenkins <den...@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.
> (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. I want
>to be able to handle $c000 through $fffc. Can I safely write random data
>to AUX $fffe,$ffff? 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. Maybe you could use AUXMOVE to copy your
routines (or parts thereof) over to the alternate zero page. Then
when you hit ALTZP you'd continue executing instead of crashing and burning.
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. But it's been a long time since I worked with this
stuff and I don't have my manual at hand.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Dennis Jenkins
>
> In article <XN1l6.3027$7e6.1...@homer.alpha.net>,
> Dennis Jenkins <den...@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.
Yes, I must use prodos, I'm writing some ProDOS system software. When
it runs,
it detaches /RAM from s3,d2 and then uses $200 through $bfff for it's
own purposes.
I'd like to use $c000 through $ffff as well.
>
> > (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. I want
> >to be able to handle $c000 through $fffc. Can I safely write random data
> >to AUX $fffe,$ffff? 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. Maybe you could use AUXMOVE to copy your
> routines (or parts thereof) over to the alternate zero page. Then
> when you hit ALTZP you'd continue executing instead of crashing and burning.
No problems. I never swap pages 0,1. I always leave those set to MAIN.
Keep in mind that I don't plan to execute any code sitting in AUX
memory, I'm
just using it to store data.
> 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. But it's been a long time since I worked with this
> stuff and I don't have my manual at hand.
Ok. Thanks for the hardware details.
ps- I tried to write my routines to use a 61K file in /RAM, and
implemented my own
"byte array assessor" functions to use the prodos MLI. Way to slow. So
I re-wrote to
do prodos block read/writes from s3,d2. Still way to slow.
I now just hit the memory from my little page zero routine. Very fast.
I just want
to use as much of it as I possibly can (and still be compatible with an
Apple IIe w/ 128K ram).
--
den...@usb.com Universal Savings Bank.
The three most dangerous things are a programmer with a soldering
iron, a manager who codes, and a user who gets ideas.
Matthew Russotto
>Matthew Russotto wrote:
>>
>> 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. Maybe you could use AUXMOVE to copy your
>> routines (or parts thereof) over to the alternate zero page. Then
>> when you hit ALTZP you'd continue executing instead of crashing and burning.
>
>No problems. I never swap pages 0,1. I always leave those set to MAIN.
You misunderstand. You HAVE to swap pages 0,1. The same switch that
swaps 0,1 also swaps the language card RAM. So if you want to access
that last 16K, you either need to be running somewhere outside 0,1 or
you need to have a copy of your code on AUX 0,1.
Dennis Jenkins
>
> In article <3A9583B6...@usb.com>, Dennis Jenkins <den...@usb.com> wrote:
> >Matthew Russotto wrote:
> >>
> >> 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. Maybe you could use AUXMOVE to copy your
> >> routines (or parts thereof) over to the alternate zero page. Then
> >> when you hit ALTZP you'd continue executing instead of crashing and burning.
> >
> >No problems. I never swap pages 0,1. I always leave those set to MAIN.
>
> You misunderstand. You HAVE to swap pages 0,1. The same switch that
> swaps 0,1 also swaps the language card RAM. So if you want to access
> that last 16K, you either need to be running somewhere outside 0,1 or
> you need to have a copy of your code on AUX 0,1.
AH! That is exactly what I wanted to know. I'll put my code in both
banks then, using AUXMOVE to load the stub.
David Empson
> In article <XN1l6.3027$7e6.1...@homer.alpha.net>,
> Dennis Jenkins <den...@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.
David Empson
> Matthew Russotto wrote:
> >
> > In article <XN1l6.3027$7e6.1...@homer.alpha.net>,
> > Dennis Jenkins <den...@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.
>
> Yes, I must use prodos, I'm writing some ProDOS system software. When
> it runs,
> it detaches /RAM from s3,d2 and then uses $200 through $bfff for it's
> own purposes.
You cannot use $0200-$03FF or $0080-$00FF, or you will destroy the code
which supports /RAM, requiring a reboot when your application
terminates. You also can't use auxiliary $0400-$07FF for arbitrary
purposes, since it is the auxiliary half of the text screen, and the
screen holes are used by the IIc firmware (and possibly other systems).
> I'd like to use $c000 through $ffff as well.
There isn't any RAM in $C000-$CFFF, so I'm not sure what you are trying
to achieve. The remaining 16KB address space of the RAM is within the
"language card", which is sandwiched into the 12KB space $D000-$FFFF,
overlaying the ROM.
The name comes from the card originally supplied by Apple with the Apple
II Language Systems (Apple II Pascal), which was installed in slot 0 of
an Apple ][ or ][+. The functionality of the language card was built
into the motherboard for the Apple IIe and later machines.
The following description applies to the traditional language card, and
its corresponding implementation in main memory of the Apple IIe. For
auxiliary memory, there is an identical language card in the same
address space. The soft switches described here affect the memory map
in exactly the same way for both language cards.
The ALTZP switch determines whether main or auxiliary RAM is being
accessed for the relevant RAM read/write operations. ALTZP also selects
main or auxiliary memory in the $0000-$01FF area.
So, the language card:
There are two 4K banks in $D000-$DFFF, and a common bank in $E000-$FFFF.
The soft-switches which control the bank switching within this area are
as follows. All are accessed via read operations.
$C080 Read RAM bank 2, write protected
$C081 Read ROM, write RAM bank 2
$C082 Read ROM, write protected
$C083 Read/write RAM bank 2
$C088 Read RAM bank 1, write protected
$C089 Read ROM, write RAM bank 1
$C08A Read ROM, write protected
$C08B Read/write RAM bank 1
"Bank 1" and "Bank 2" refer to the two alternate 4K banks in
$D000-$DFFF. There is no distinction between the banks as far as
$E000-$FFFF are concerned.
Locations $C081/3/9/B require two accesses to enable language card
write.
e.g.
LDA $C082 ; Select the ROM, write protect RAM
...
LDA $C080 ; Select RAM, bank 2 enabled, write protected
...
LDA $C081 ; Read from ROM
LDA $C081 ; Second access write-enables RAM bank 2
...
LDA $C083 ; Read from RAM bank 2
LDA $C083 ; Second access write-enables RAM bank 2
The Read ROM/Write RAM combination ($C081 or $C089) is typically used to
copy data from the ROM to the language card.
Matthew Russotto
David Empson <dem...@actrix.gen.nz> wrote:
>Matthew Russotto <russ...@wanda.pond.com> wrote:
>
>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.)
What the technote says and what the truth is, particularly if you
don't call any system services while auxiliary memory is switched in,
might be two different things.
>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.
Or you could just disable interrupts throughout the whole fetch from
auxiliary memory and save yourself some trouble.
>> 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.
Sorry, was working from memory here.
David Empson
> In article <1epca4c.sf5woy64dob4N%dem...@actrix.gen.nz>,
> David Empson <dem...@actrix.gen.nz> wrote:
> >Matthew Russotto <russ...@wanda.pond.com> wrote:
> >
> >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.)
>
> What the technote says and what the truth is, particularly if you
> don't call any system services while auxiliary memory is switched in,
> might be two different things.
The lower part is quite clear: the main body of ProDOS's /RAM driver
lives in auxiliary memory $0200-$03FF, and it uses $0080-$00FF. If you
overwrite this area, then it will not be possible to reconnect /RAM upon
termination of your application.
The auxiliary screen holes are used by the IIc firmware (e.g. for
default settings for the serial ports). I'm not aware of them being
used on other systems.
The auxiliary language card area is less clear. No version of ProDOS
has used this area, but Apple always reserved it to allow for future
expansion, and there are some other pieces of system software that can
use this area (the technote cites a version of SANE which loads at $E000
in the auxiliary language card).
> >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.
>
> Or you could just disable interrupts throughout the whole fetch from
> auxiliary memory and save yourself some trouble.
True, as long as you aren't doing it too long. On the IIgs in
particular, there may be software that is dependent on timing-critical
interrupts (AppleTalk is a notable example).
David Empson
> David Empson wrote:
> > See TN.PDOS.026 (Polite Use of Auxiliary Memory) for details.
>
> What is the URL of this document?
It doesn't look like Apple have the Apple II technotes on their FTP
server any longer, but I expect they will be available on one of the
archive sites (ground, for example). Have a look through the FAQs for
pointers to them.
Assuming Apple's organisation is retained, there should be a TN.About
and TN.Index file at the root level (plus FTN.About and FTN.Index), with
a subdirectory for each technote category. The "PDOS" subdirectory
contains ProDOS-8 technical notes, and the individual files are named
TN.PDOS.nnn (nnn is the technote number), similarly for other
categories.
The technote isn't critical - it just explains the rules for using
auxiliary memory areas in different circumstances. You also need the
ProDOS-8 Technical Reference (memory map near the end) so that you can
identify the normally reserved areas.
> Maybe I should start from the top. This is what I want:
>
> 1) I am developing a prodos application (SYS file).
> 2) I am using the CC65 cross compiler. My code is a mix of asm and C.
> 3) I use $800->$1fff (main) to store prodos buffers.
> 4) I use the 80 column text screen and sometimes double low-res
> graphics.
> 5) I wish to use as much of AUX memory (from $800->$feff ??) to store
> a fairly large byte array in. As far as my C code is concerned, I
> will be accessing this memory from wrapper functions:
> unsigned char ReadAuxMemory(void *ptr);
> void WriteAuxMemory(void *ptr, unsigned char c);
You should be able to use up to $FFF9 safely, and can probably get away
with $FFFA through $FFFD, but should avoid $FFFE-$FFFF.
$FFFE-$FFFF in the auxiliary language card should be set to the same
value as in the ROM. This will allow interrupts to be handled correctly
on the IIc and enhanced IIe. (As mentioned earlier, this is not an
issue on the IIgs.) The unenhanced IIe can't handle interrupts with the
auxiliary language card active, but you aren't all that likely to have
an interrupt source on a IIe.
You can minimise problems by ensuring interrupts are locked out at all
times while the auxiliary zero page/stack/language card are switched in.
> 6) In general, I will not be executing any code in AUX memory, just
> the minimum code required to read or write bytes.
> 7) I can deal with the memory hole at $c000->$cfff.
One convenient way of dealing with this area would be if your routine
pretended that the second $D000-$DFFF bank was located in $C000-$CFFF.
> Currently, I load two 9 byte stubs into main memory at $e0 -> $f3. I
> have asm wrappers that pop my C args from the virtual stack (it is what
> cc65 uses for passing args). These functions test my argument ranges,
> then call the appropriate read/write function at $e0 or $e9. These
> functions just store the accumulator to the softswitch $c002/$c004 (as
> required), lda/sta my byte, then set the softswitch back to main memory,
> then return to the caller.
OK, that code will work fine for $0800-$BFFF, but it won't work for the
auxiliary language card area ($D000-$FFFF or the second bank in
$D000-$DFFF), because you need to use different soft-switches, and
switching in the auxiliary language card will switch out the main memory
zero page (and stack).
If you haven't already used the $0200-$03DF area in main memory, I
suggest adding four stub routines in there which will deal with the
auxiliary language card area (read bank 1, write bank 1, read bank 2,
write bank 2).
Your main ASM wrapper code should check for three address ranges:
$0800-$BFFF go to your existing zero-page routine.
$C000-$CFFF go to the read/write aux bank 1 routine, with the high byte
patched by adding $10 (thus $C000-$CFFF map to $D000-$DFFF).
$D000-$FFF9 go to the read/write bank 2 routine, with an unpatched high
byte.
(You can use either bank 1 or 2 to access $E000-$FFFF. It is only the
$D000-$DFFF area which changes according to the bank selection.)
The stub routines to access the auxiliary language card area are as
follows:
RDAUX1 SEI ; No interrupts!
LDX C088 ; Read-enable language card bank 1
STA C009 ; Switch in auxiliary language card, etc.
LDA xxxx ; Read target location (patched)
STA C008 ; Switch in main language card, etc.
LDX C08A ; Switch the ROM back in
CLI ; Enable interrupts
RTS
WRAUX1 SEI ; No interrupts!
LDX C08B ; Read/write language card bank 1
LDX C08B ; (must access twice)
STA C009 ; Switch in auxiliary language card, etc.
STA xxxx ; Write target location (patched)
STA C008 ; Switch in main language card, etc.
LDX C08A ; Switch the ROM back in
CLI ; Enable interrupts
RTS
RDAUX2 SEI ; No interrupts!
LDX C080 ; Read-enable language card bank 2
STA C009 ; Switch in auxiliary language card, etc.
LDA xxxx ; Read target location (patched)
STA C008 ; Switch in main language card, etc.
LDX C082 ; Switch the ROM back in
CLI ; Enable interrupts
RTS
WRAUX2 SEI ; No interrupts!
LDX C083 ; Read/write language card bank 2
LDX C083 ; (must access twice)
STA C009 ; Switch in auxiliary language card, etc.
STA xxxx ; Write target location (patched)
STA C008 ; Switch in main language card, etc.
LDX C082 ; Switch the ROM back in
CLI ; Enable interrupts
RTS
The C008/C009 switch controls both read and write access, unlike the
switches for the main $0200-$BFFF area, but note the different
instruction sequences needed to control read enable and read/write
enable for the language card area. (You could set up the language card
for write-only access using C081 or C089 instead of C083 or C08B, but it
won't make the code any shorter.)
> I do disconnect /RAM, and I don't care if /RAM is to be re-attached when
> I'm done.
Are you sure about that? If your application disconnects /RAM, then it
is the responsibility of your application to reconnect it again when you
terminate. The only reasonable exceptions to this would be an
application which installs its own replacement RAM disk driver, or a
special-purpose application which never quits.
The /RAM volume is there for the convenience of the user. If you don't
restore it, then subsequent applications which need to use it won't be
able to, and some application won't be able to use auxiliary memory at
all if there is no /RAM volume present (others might assume that they
have full rein, and overwrite anything you might have left there).
.
Dennis Jenkins
> One convenient way of dealing with this area would be if your routine
> pretended that the second $D000-$DFFF bank was located in $C000-$CFFF.
I realized that last night on the bus ride home. :)
>
> > Currently, I load two 9 byte stubs into main memory at $e0 -> $f3. I
> > have asm wrappers that pop my C args from the virtual stack (it is what
> > cc65 uses for passing args). These functions test my argument ranges,
> > then call the appropriate read/write function at $e0 or $e9. These
> > functions just store the accumulator to the softswitch $c002/$c004 (as
> > required), lda/sta my byte, then set the softswitch back to main memory,
> > then return to the caller.
>
> OK, that code will work fine for $0800-$BFFF, but it won't work for the
> auxiliary language card area ($D000-$FFFF or the second bank in
> $D000-$DFFF), because you need to use different soft-switches, and
> switching in the auxiliary language card will switch out the main memory
> zero page (and stack).
>
> If you haven't already used the $0200-$03DF area in main memory, I
> suggest adding four stub routines in there which will deal with the
> auxiliary language card area (read bank 1, write bank 1, read bank 2,
> write bank 2).
>
> Your main ASM wrapper code should check for three address ranges:
>
> $0800-$BFFF go to your existing zero-page routine.
> $C000-$CFFF go to the read/write aux bank 1 routine, with the high byte
> patched by adding $10 (thus $C000-$CFFF map to $D000-$DFFF).
> $D000-$FFF9 go to the read/write bank 2 routine, with an unpatched high
> byte.
>
> (You can use either bank 1 or 2 to access $E000-$FFFF. It is only the
> $D000-$DFFF area which changes according to the bank selection.)
>
Here comes the good stuff (A real implementation using the soft
switches):
Since the above code is for hitting the language card at >$bfff, I
assume that I can leave the above code in my main code segment (er, um,
whatever it is called...) in MAIN memory. Is this correct, or do I need
to shove it all into zero page (along with my other stubs)?
> The C008/C009 switch controls both read and write access, unlike the
> switches for the main $0200-$BFFF area, but note the different
> instruction sequences needed to control read enable and read/write
> enable for the language card area. (You could set up the language card
> for write-only access using C081 or C089 instead of C083 or C08B, but it
> won't make the code any shorter.)
Why did they bother with write only access to this ram?
> > I do disconnect /RAM, and I don't care if /RAM is to be re-attached when
> > I'm done.
>
> Are you sure about that? If your application disconnects /RAM, then it
> is the responsibility of your application to reconnect it again when you
> terminate. The only reasonable exceptions to this would be an
> application which installs its own replacement RAM disk driver, or a
> special-purpose application which never quits.
>
> The /RAM volume is there for the convenience of the user. If you don't
> restore it, then subsequent applications which need to use it won't be
> able to, and some application won't be able to use auxiliary memory at
> all if there is no /RAM volume present (others might assume that they
> have full rein, and overwrite anything you might have left there).
> .
I never thought about being "polite". In my normal usage of an Apple
II, I reboot it quite often. Rebooting (or doing -prodos) reinitializes
/RAM. I can add code to re-attach and reformat /RAM, but I will now
have to make sure that I don't trash important memory areas that ProDOS
would like me to preserve. I'll try to find that technote.
If I am free to use the RAM in the language card, then I assume that
ProDOS 'lives' in the upper 16K (or 12K?) of the AUX memory proper,
accessed via the ALTZP switch?
And I thought that PCs had funky memory layouts!
Dave,
Thank you very much. I finally understand how the Apple II memory is
layed out. Your post makes much more sense than a simple list of
softswitches.
Matthew Russotto
>
>Why did they bother with write only access to this ram?
Probably because it lets you do stuff like poke the language card
write-only softswitch, then load INTBASIC or FPBASIC (under DOS) from
disk into that RAM.
David Empson
> Here comes the good stuff (A real implementation using the soft
> switches):
>
> David Empson wrote:
> >
> > The stub routines to access the auxiliary language card area are as
> > follows:
> >
> > RDAUX1 SEI ; No interrupts!
> > LDX C088 ; Read-enable language card bank 1
> > STA C009 ; Switch in auxiliary language card, etc.
> > LDA xxxx ; Read target location (patched)
> > STA C008 ; Switch in main language card, etc.
> > LDX C08A ; Switch the ROM back in
> > CLI ; Enable interrupts
> > RTS
> > [etc]
>
> Since the above code is for hitting the language card at >$bfff, I
> assume that I can leave the above code in my main code segment (er, um,
> whatever it is called...) in MAIN memory.
Correct. (I should have suggested that in the first place - there is no
need to have extra stub routines in $0200-$03DF.)
> Is this correct, or do I need to shove it all into zero page (along
> with my other stubs)?
You _cannot_ put this code in zero page, because the STA C009
instruction will switch out the zero page!
> > The C008/C009 switch controls both read and write access, unlike the
> > switches for the main $0200-$BFFF area, but note the different
> > instruction sequences needed to control read enable and read/write
> > enable for the language card area. (You could set up the language card
> > for write-only access using C081 or C089 instead of C083 or C08B, but it
> > won't make the code any shorter.)
>
> Why did they bother with write only access to this ram?
The major benefit is that it allows code in ROM to remain available for
use while copying data into the language card. For example, the
standard memory move routine provided by the monitor can be used to copy
data from main memory (or ROM) into the language card area.
One example of this is late versions of DOS 3.3, which were able to save
disk space on the system master by not including a copy of the monitor
firmware in the FPBASIC and INTBASIC files (saving 8 sectors per file).
The LOADER.OBJ0 program reads whichever file is appropriate into the
language card at $D000-$F7FF (using the write-only mode), then copies
the monitor firmware from the ROM to the language card ($F800-$FFFF).
This means that you end up with the "native" monitor firmware for the
machine.
By comparison, earlier versions of DOS 3.3 included a copy of the
"autostart" (Apple ][+) monitor ROM in FPBASIC and INTBASIC. If you run
this version on an Apple //e, then you lose several //e-specific
features if you switch to Integer BASIC. The 80-column firmware has a
workaround for this: if it detects the "wrong" monitor in the language
card, it copies the monitor firmware from the ROM.
> > [Disconnecting /RAM]
>
> I never thought about being "polite". In my normal usage of an Apple
> II, I reboot it quite often. Rebooting (or doing -prodos) reinitializes
> /RAM. I can add code to re-attach and reformat /RAM, but I will now
> have to make sure that I don't trash important memory areas that ProDOS
> would like me to preserve. I'll try to find that technote.
The only memory areas you need to protect are auxiliary memory zero page
($0080-$00FF) and auxiliary memory $0200-$03FF.
Reattaching /RAM is basically the reverse process for removing it. The
only extra step is to issue a FORMAT call to its device driver (which
requires a few steps to get the memory into the right state). This will
create a fresh directory on /RAM (unlike formatting other volumes).
If you don't have all the details, I should be able to E-Mail you a copy
of the relevant technotes.
> If I am free to use the RAM in the language card, then I assume that
> ProDOS 'lives' in the upper 16K (or 12K?) of the AUX memory proper,
> accessed via the ALTZP switch?
Apart from the /RAM driver code, ProDOS lives entirely in main memory:
$BF00-$BFFF is the global page (entry points, data structures, hook
routines, etc.), and the kernel is in $D000-$FFFF (main memory language
card). There is also the quit code (program selector) in the second
language card bank ($D100-$D3FF).
I'm not sure what you mean about "the upper 16K of AUX memory proper".
That is the auxiliary language card area, which I was telling you how to
use in my previous message in this thread.
Have you seen a complete diagram of the 128K IIe memory map? It
certainly helps when trying to understand all this. Here is a rough
version (not to scale vertically).
MAIN RAM AUX RAM I/O ROM
______________ ______________
0000 |Main zero page| |Aux zero page |
|______________| |______________|
0100 | Main stack | | Aux stack |
|______________| |______________|
0200 | | | |
| | | |
0300 | | | |
|______________| |______________|
0400 | | | |
| | | |
| Main text/GR | | Aux text/GR |
| | | |
| page 1 | | page 1X |
| | | |
| | | |
|______________| |______________|
0800 | | | |
| | | |
| Main text/GR | | Aux text/GR |
| | | |
| page 2 | | page 2X |
| | | |
| | | |
|______________| |______________|
0C00 | | | |
| | | |
... ...
| | | |
|______________| |______________|
2000 | | | |
| | | |
| Main Hi-res | | Aux Hi-res |
| | | |
| page 1 | | page 1X |
| | | |
| | | |
|______________| |______________|
4000 | | | |
| | | |
| Main Hi-res | | Aux Hi-res |
| | | |
| page 2 | | page 2X |
| | | |
| | | |
|______________| |______________|
6000 | | | |
| | | |
| | | |
... ...
| | | |
| | | |
BFFF |______________| |______________| _____________
C000 | Motherboard |
| I/O |
|_____________|
C090 | Slot I/O |
| (DEVSEL) |
|_____________| _____________
C100 | | | |
| Slot CX ROM | | Int CX ROM |
| (IOSEL) | | |
| | | |
|_____________| |_____________|
C300 | Slot C3 ROM | | Int C3 ROM |
| (IOSEL) | | |
|_____________| |_____________|
C400 | | | |
| | | |
| Slot CX ROM | | Int CX ROM |
| (IOSEL) | | |
| | | |
| | | |
| | | |
|_____________| |_____________|
C800 | | | |
| Slot ROM | | |
| (IOSTROBE) | | Int C3 ROM |
| | | |
| shared | | |
| between | | |
| slots | | |
CFFF ______ ______ ______ ______ |_____________| |_____________|
D000 | || | | || | | |
| Main || Main | | Aux || Aux | | |
| || | | || | | |
| LC || LC | | LC || LC | | |
| || | | || | | |
| bank || bank | | bank || bank | | |
| 1 || 2 | | 1 || 2 | | Applesoft |
|______||______| |______||______| | |
E000 | | | | | BASIC |
| | | | | |
| | | | | ROM |
| | | | | |
| | | | | |
| Main | | Aux | | |
| | | | | |
| Language | | Language | | |
| | | | | |
| Card | | Card | | |
| | | | | |
| | | | |.............|
F800 | | | | | Monitor |
| | | | | |
| | | | | ROM |
FFFF |______________| |______________| |_____________|
(If you have a RAMWorks or similar bank-switched card in the auxiliary
slot, then any 64K bank on the card can be switched into the auxiliary
memory space. "Normal" auxiliary memory, which contains the video
buffers, is bank 0 on the card.)
The major soft-switches for bank switching control areas as follows:
AUXZP/MAINZP selects main or auxiliary RAM in 0000-01FF (zero page and
stack), and in D000-FFFF (language card), for read/write access. The
language card area is further affected by language card soft-switches
(see later).
RDMAIN/RDAUX selects main or auxiliary RAM in 0200-BFFF for read access
only. Text page 1/1X and Hi-res page 1/1X may be excluded depending on
the state of the 80STORE and HIRES soft-switches.
WRMAIN/WRAUX selects main or auxiliary RAM in 0200-BFFF for write access
only. Text page 1/1X and Hi-res page 1/1X may be excluded depending on
the state of the 80STORE and HIRES soft-switches.
80STORE enables 80-column switching of text/lo-res page 1 (0400-07FF).
The active page (main or auxiliary) is determined by the PAGE1/PAGE2
soft switch. 80STORE gives read/write access to whichever page is
active.
If 80STORE and HIRES are both enabled, then PAGE1/PAGE2 also control
switching of hi-res page 1 (2000-3FFF).
There is no special bank switching support for text or hi-res page 2/2X.
Using the double resolution modes with these pages requires using
another bank switching technique.
SLOTCXROM/INTCXROM determines whether the slot address space or
motherboard ROM is enabled for $C100-$C2FF and $C400-$C7FF.
SLOTC3ROM/INTC3ROM determines whether the slot address space or
motherboard ROM is enabled for $C300-$C3FF.
The $C800-$CFFF area (I/O Stobe) is shared between all slots, and may be
used by the internal ROM if INTC3ROM is active. An access to the
$CN00-$CNFF page (N=1 to 7) enables the expansion ROM space for slot N,
if supported by that card. An access to $CFFF disables the expansion
ROM space for all cards.
I listed the language card soft-switches in an earlier article in this
thread (message ID <1epcaw8.16zv8ma1pa69hcN%dem...@actrix.gen.nz>).
There are eight of them, and between them they control selection of RAM
bank 1 or 2, read enable for RAM or ROM, and write enable for RAM.
Dennis Jenkins
David Empson wrote:
> > Why did they bother with write only access to this ram?
>
> The major benefit is that it allows code in ROM to remain available for
> use while copying data into the language card. For example, the
> standard memory move routine provided by the monitor can be used to copy
> data from main memory (or ROM) into the language card area.
>
> One example of this is late versions of DOS 3.3, which were able to save
> disk space on the system master by not including a copy of the monitor
> firmware in the FPBASIC and INTBASIC files (saving 8 sectors per file).
> The LOADER.OBJ0 program reads whichever file is appropriate into the
> language card at $D000-$F7FF (using the write-only mode), then copies
> the monitor firmware from the ROM to the language card ($F800-$FFFF).
> This means that you end up with the "native" monitor firmware for the
> machine.
>
> By comparison, earlier versions of DOS 3.3 included a copy of the
> "autostart" (Apple ][+) monitor ROM in FPBASIC and INTBASIC. If you run
> this version on an Apple //e, then you lose several //e-specific
> features if you switch to Integer BASIC. The 80-column firmware has a
> workaround for this: if it detects the "wrong" monitor in the language
> card, it copies the monitor firmware from the ROM.
Wow! This architecture has more hacks in it than any I have ever seen!
It is amazing that most of the Apple II software from the late 70's
still works on an Apple II[e|c|gs].
>
> > > [Disconnecting /RAM]
> >
> > I never thought about being "polite". In my normal usage of an Apple
> > II, I reboot it quite often. Rebooting (or doing -prodos) reinitializes
> > /RAM. I can add code to re-attach and reformat /RAM, but I will now
> > have to make sure that I don't trash important memory areas that ProDOS
> > would like me to preserve. I'll try to find that technote.
>
> The only memory areas you need to protect are auxiliary memory zero page
> ($0080-$00FF) and auxiliary memory $0200-$03FF.
>
> Reattaching /RAM is basically the reverse process for removing it. The
> only extra step is to issue a FORMAT call to its device driver (which
> requires a few steps to get the memory into the right state). This will
> create a fresh directory on /RAM (unlike formatting other volumes).
>
> If you don't have all the details, I should be able to E-Mail you a copy
> of the relevant technotes.
I have details on how to detach, re-attach and reformat /RAM from a book
about ProDOS by Gary Little (got on Ebay). I don't remember the exact
title, but it is an excellent book.
> > If I am free to use the RAM in the language card, then I assume that
> > ProDOS 'lives' in the upper 16K (or 12K?) of the AUX memory proper,
> > accessed via the ALTZP switch?
>
> Apart from the /RAM driver code, ProDOS lives entirely in main memory:
> $BF00-$BFFF is the global page (entry points, data structures, hook
> routines, etc.), and the kernel is in $D000-$FFFF (main memory language
> card). There is also the quit code (program selector) in the second
> language card bank ($D100-$D3FF).
> I'm not sure what you mean about "the upper 16K of AUX memory proper".
> That is the auxiliary language card area, which I was telling you how to
> use in my previous message in this thread.
I guess I meant what you refered to as the "main memory language card".
> Have you seen a complete diagram of the 128K IIe memory map? It
> certainly helps when trying to understand all this. Here is a rough
> version (not to scale vertically).
I have never seen a full memory map of this detail. It seems that a
128K IIe has far more than just 128K of addressable bytes. I knew about
the expansion ROM switching, but I never understood the full
capabilities of the language card. I thought it simply allowed you to
swap the 12K main ROM for 12K of ram. Into this ram one would load
INTBASIC or ProDOS (I've always used Applesoft from ROM).
>
> MAIN RAM AUX RAM I/O ROM
[lots of stuff deleted]
This is the part that always confused me. I'm going to tape a print out
of this to my wall near my computer so I can refer to it all the time.
I wonder who will take it down first, my wife or my cats...
> CFFF ______ ______ ______ ______ |_____________| |_____________|
> D000 | || | | || | | |
> | Main || Main | | Aux || Aux | | |
> | || | | || | | |
> | LC || LC | | LC || LC | | |
> | || | | || | | |
> | bank || bank | | bank || bank | | |
> | 1 || 2 | | 1 || 2 | | Applesoft |
> |______||______| |______||______| | |
> E000 | | | | | BASIC |
> | | | | | |
> | | | | | ROM |
> | | | | | |
> | | | | | |
> | Main | | Aux | | |
> | | | | | |
> | Language | | Language | | |
> | | | | | |
> | Card | | Card | | |
> | | | | | |
> | | | | |.............|
> F800 | | | | | Monitor |
> | | | | | |
> | | | | | ROM |
> FFFF |______________| |______________| |_____________|
>
> (If you have a RAMWorks or similar bank-switched card in the auxiliary
> slot, then any 64K bank on the card can be switched into the auxiliary
> memory space. "Normal" auxiliary memory, which contains the video
> buffers, is bank 0 on the card.)
How does one switch this memory? My current code will not relay on
having more than 128K of ram, but it would be neat to know. My IIe
emulator card for my Mac LC-II insists on creating a 256K /RAM7, so I
assume that it follows the same spec. Actually, I'll post a different
thread to ask about accessing memory beyond 128K from an IIe and IIgs
(in 8 bit mode).
David Empson
> (rubywand, I suggest putting this excellent memory map into the FAQ)
Ditto. Ideally, it should be supplemented with more details on the
memory locations of each of the relevant soft switches.
> David Empson wrote:
> >
> > (If you have a RAMWorks or similar bank-switched card in the auxiliary
> > slot, then any 64K bank on the card can be switched into the auxiliary
> > memory space. "Normal" auxiliary memory, which contains the video
> > buffers, is bank 0 on the card.)
>
> How does one switch this memory?
I've never worked with one of these cards, but the principle is quite
simple: the card implements a write-only register at either $C071 or
$C073, into which you store the desired bank number.
ProDOS and the motherboard firmware have no built-in support for these
cards, so it is necessary to load a driver from disk (e.g. to create a
larger RAM disk). If you wanted to use the card for something other
than a RAM disk, it would be necessary to comply with some kind of
guidelines for allocation of banks within the card. I don't know if any
such guidelines exist.
The auxiliary slot cards have no ROM, hence no firmware. A RAM disk on
one of these cards cannot be used to boot the machine.
By comparison, standard slot RAM cards have firmware and appear to
ProDOS as a normal block device; you can boot from such a card.
Applications are supposed to use the SmartPort firmware interface to
access memory on the card, to allow for compatibility with various cards
that might implement the hardware interface differently.
Apple's own card uses a one byte memory window in the I/O space,
together with a three byte address register. The driver code writes the
address within the card's memory into the address register, then reads
or writes data one byte at a time using the data register. Each read or
write access automatically increments the address register.
> My IIe emulator card for my Mac LC-II insists on creating a 256K /RAM7, so I
> assume that it follows the same spec.
That will be a standard slot RAM card (an emulated one), not an
auxiliary slot card. I wouldn't expect the IIe card for the LC to
emulate the hardware interface, only the firmware interface.
> Actually, I'll post a different thread to ask about accessing memory beyond
> 128K from an IIe and IIgs (in 8 bit mode).
The IIgs is yet another kettle of fish. There is one fundamental rule:
if you use any memory outside of the ProDOS-8 area (main and auxiliary
memory, corresponding to banks 0 and 1 on the IIgs), you _must_ use IIgs
Memory Manager toolset to reserve the appropriate memory areas. (This
requires a little extra work to set it up correctly if you boot directly
into ProDOS-8.)
In general, you cannot assume that any particular memory range may be
available: the normal memory allocation technique is to ask for a block
of memory of a specified size at an unspecified location, lock it down
(so it won't move) then use pointers to access the content of the
memory. The memory block should be unlocked again if not in use for a
while, since this allows the system to move reserved memory around to
make space for a subsequent allocation.
No bank switching is required to access memory in the IIgs: you can set
up three-byte pointer variables on zero page, and use the 65816 indirect
long addressing modes to directly access the entire 16 MB address space.
The IIgs also emulates the memory map of the IIe, with bank switching as
described in my previous article, except that the $C100-$CFFF ROM space
works a little differently. It is also somewhat more complicated by the
presence of two pairs of banks which mirror the IIe memory layout (banks
0 and 1, and banks $E0 and $E1). The video buffers are actually in
banks $E0 and $E1, and hardware or software shadowing techniques are
used to mirror them into banks 0 and 1.
Rubywand
>
....
ref. David Empson wrote ....
>>
Have you seen a complete diagram of the 128K IIe memory map? It
certainly helps when trying to understand all this. Here is a rough
version (not to scale vertically).
MAIN RAM AUX RAM I/O ROM
______________ ______________
CFFF ______ ______ ______ ______ |_____________| |_____________|
D000 | || | | || | | |
| Main || Main | | Aux || Aux | | |
| || | | || | | |
| LC || LC | | LC || LC | | |
| || | | || | | |
| bank || bank | | bank || bank | | |
| 1 || 2 | | 1 || 2 | | Applesoft |
|______||______| |______||______| | |
E000 | | | | | BASIC |
| | | | | |
| | | | | ROM |
| | | | | |
| | | | | |
| Main | | Aux | | |
| | | | | |
| Language | | Language | | |
| | | | | |
| Card | | Card | | |
| | | | | |
| | | | |.............|
F800 | | | | | Monitor |
| | | | | |
| | | | | ROM |
FFFF |______________| |______________| |_____________|
<<
> (rubywand, I suggest putting this excellent memory map into the FAQ)
>
....
Good idea. The map plus David's related softswitch info will make a juicy
addition.
Rubywand
Paul Schlyter
Rubywand <ruby...@swbell.net> wrote:
>Dennis Jenkins writes ...
>>
> ....
>
>
>ref. David Empson wrote ....
>>>
>
>Have you seen a complete diagram of the 128K IIe memory map? It
>certainly helps when trying to understand all this. Here is a rough
>version (not to scale vertically).
Nice memory map! It inspired me to draw a similar map
explaining the memory usare of SoftCard CP/M:
Apple II Softcard CP/M memory usage
0100H Z-80 address
$0100 6502 address
44K CP/M: does not use Language Card
56K CP/M: uses Language Card, bank 2 only (TPA)
60K CP/M: uses Language Card: bank 2 for TPA, bank 1 for parts of BDOS+BIOS
Note that the Apple II hi-res graphics screens are situated right in
the middle of the Softcard CP/M TPA. Hi-res graphics programming on
SoftCard CP/M therefore requires special precautions. Microsoft
GBASIC solves this by reserving an 8K large memory area, right in the
middle of the Basic interpreter, for hi-res graphics.
Z80 addr 6502 addr
______________ ______________
0000H |CP/M zero page| $1000 | |
|______________| | |
0100H |CP/M TPA start| | |
| | | |
| | | |
| | | |
| | | |
|______________| |______________|
1000H | | $2000 | |
| | | |
| | | Aux Hi-res |
| CP/M TPA | | |
| | | page 1X |
| | | |
| | | |
|______________| |______________|
3000H | | $4000 | |
| | | |
| | | Aux Hi-res |
| CP/M TPA | | |
| | | page 2X |
| | | |
| | | |
|______________| |______________|
5000H | | $6000 | |
| | | |
| CP/M TPA | | |
| | | |
| | | |
| | | |
... ...
| | | |
| | | |
| | | |
| | | |
| | | |
|______________| | |
9400H | 44K BDOS | $A400 | |
| starts here | | |
| | | |
| | | |
| CP/M 56/60K | | |
| TPA | | |
| | | |
| | | |
| | | |
| 44K BIOS end | | |
AFFFH |______________| $BFFF |______________| ______________
B000H | | $D000 | || | | |
| | | LC || LC | | |
| | |bank 1||bank 2| | |
| CP/M 56/60K | | || | | |
| TPA | | 60K || Used | | |
| | | BDOS+|| by | | |
| | | BIOS || CP/M | | Applesoft |
| | |______||______| | |
C000H | | $E000 | | | BASIC |
| | | | | |
|______________| | | | ROM |
C400H | 56K BDOS | $E400 | | | |
| starts here | | | | |
| | | Language | | |
| | | | | |
| | | Card | | |
| | | | | |
|______________| | | | |
D400H | 60K BDOS | $F400 | | | |
| starts here | | | |..............|
D800H | | $F800 | | | Monitor |
| 56K BIOS end | | | | ROM |
|______________| |______________| |______________|
DFFAH | 6502 vectors | $FFFA | 6502 vectors | | 6502 vectors |
DFFFH |______________| $FFFF |______________| |______________|
_____________
E000H $C000 | Motherboard |
| I/O |
|_____________|
E090H $C090 | Slot I/O |
| (DEVSEL) |
|_____________|
E100H $C100 | |
| Slot CX ROM |
| (IOSEL) |
| |
|_____________|
E300H $C300 | Slot C3 ROM |
| (IOSEL) |
|_____________|
E400H $C400 | |
| |
| Slot CX ROM |
| (IOSEL) |
| |
| |
| |
|_____________|
E800H $C800 | |
| Slot ROM |
| (IOSTROBE) |
| |
| shared |
| between |
| slots |
EFFFH $CFFF |_____________|
______________ ______________
F000H | Unused by Z80| $0000 |6502 zero page|
|______________| |______________|
F100H | Unused by Z80| $0100 | 6502 stack |
|______________| |______________|
F200H | I/O cfg blk | $0200 | Keybd buff |
| Device driv | |______________|
F300H | Patch area | $0300 | Page 3 |
|______________| |______________|
F400H | | | |
| | | |
| Text/lores GR| | Text/lores GR|
| | | |
| | | page 1 |
| | | |
| | | |
|______________| |______________|
F800H | | $0800 | |
| | | Text/lores GR|
| CP/M | | |
| | | page 2 |
| RWTS | |______________|
FC00H | | $0C00 | |
| | | |
| | | |
FFFFH |______________| $0FFF |______________|
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch