Okay, AUXMEM comes with the ALTZP feature, but beside the zero page
and the stack the only memory not switched is the language card.
However, the MAIN language card is used by ProDOS and access to the
AUX language card can't be combined with access to the MAIN "base"
memory. So all in all, ALTZP is pretty much useless.
Sure it can, as long as there are no calls to Prodos or ROM. If you have a routine in the AuxLC, you would have to transfer temporary control to the Main48 area to make any Prodos or ROM calls, but I find that area pretty handy to store fonts and shapes,
and also to make calls to Aux48k routines. I find it easier to use then AUXMOVE ($C311) and XFER ($C314).
To call to Aux48k memory, the route would be Main48 switches in AuxLCZP. Transfer any zero-page bytes used, such as the $E0.EF range for graphics, or 80-col zero-page usage. Then call the routine above $D000. Then have the AuxLCZP routine switch in
the lower Aux48k, and jump to a routine there.
You can have any combination switched in of Main48k + MainLCZP, Main48k + AuxLCZP and Aux48k + MainLCZP and lastly Aux48k + AuxLCZP. I use the AuxLCZP quite a bit for storing fonts and shape tables to be drawn to the dbl-hi-res screen, as that doesn't
require any calls to ROM, but does require updating pointers in Aux-zero-page.
I have a working SPLIT that can run an applesoft program both in each of Main memory and Aux memory. The Aux memory program can even make calls to Prodos and save/load a file to disk as normal. Each zero-page has its own set of pointers for keeping
track of the cursor on the 80-col screen. I had uploaded a demo where the Main program used the top half of the text screen and the Aux program used the bottom half.
Entrance 80STOREON: The innovative(?) approach is setting hires mode (HIRESON) to make 80STOREON act on the address space $2000-$4000 but
staying in text mode (TEXTON). This allows for both setups:
1. MAIN: $800-$2000, AUX: $2000-$4000, MAIN: $4000-$BF00
2. AUX: $800-$2000, MAIN: $2000-$4000, AUX: $4000-$BF00
This is incorrect. 80STORE allows the PAGE1/PAGE2 softswitches ($C054/$C055) to act differently.
With 80STOREOFF ($C000) allows $C054 switch to text screen 1 ($400.7FF) or Hi-res screen 1 ($2000.3FFF), and $C055 switch to text screen2 ($800.BFF) or Hi-res screen2 ($4000.5FFF).
With 80STOREON ($C001), $C054 allows loads/stores to Main text screen ($400.7FF) or Main memory Hi-res screen ($2000.3FFF) and $C055 allows loads/stores to Aux memory text screen ($400.7FF) or Aux Hi-res screen ($2000.3FFF)
So one can
a) use $2000-$4000 as rather small fixed memory and switch $800-$2000/$4000-$BF00.
b) use $800-$2000/$4000-$BF00 as pretty large fixed memory and switch
only $2000-$4000.
You can store data or a routine to the Hi-res screen memory in Aux memory $2000.4000, but you cannot jump there and have it execute without the use of AuxXFER ($C314). This will still have the same problems when calling ROM routines to print to either
the text screen or graphics screen.
Especially option a) is very attractive - of course for text based
programs only.
Notes:
1. The setups described here don't preclude 80 column text in any way.
2. For a more sophisticated program it's of course possible to
consider both memory areas ($800-$2000/$4000-$BF00 as well as
$2000-$4000) as switched. It can always use "the other" memory area as trampoline.
Unfortunately it doesn't quite work that way, but you could use the $2000.3FFF memory of Aux to be used as a data transfer area to/and/from Aux memory routines, but this requires a double move. From other Aux memory to Aux memory at $2000.3FFF, then a
read from the Main memory. This is time consuming and there are easier methods.
So far so good, but there's also something in there for graphics
programs: Again setting 80STOREON with HIRESON, but this time with
TEXTOFF. However, the innovative(?) idea is here to _not_ activate
DHGR, but stay with HGR (80COLOFF). This allows for two interesting
setups:
80STOREON/OFF is a misdemeanour and has nothing to do with the 80-col card, other than changing a few LDA/STA instructions to act upon Main memory or Aux memory.
1. Don't bother with memory switching for parts of the program code at
all. Just enjoy the contiguous memory area $800-$BF00, which is
especially useful for high level language tool chains not optimized
for the Apple II memory layout. Only the actual graphics code needs to
be aware of memory switching - and needs to be located outside of $2000-$4000. Simply copy the program code at $2000-$4000 from MAIN to
AUX using AUXMOVE after loading the program before accessing the hires
video RAM. There's no need to touch RAMRDOFF, RAMDRON, RAMWRTOFF or RAMWRTON. Just make sure to have PAGE2ON on during normal program
operation and temporarily set PAGE2OFF for hires video RAM access.
It is by far more efficient to use Aux memory as a Ramdisk and load modules into your program in main memory. It alleviates a lot of the headache of trying to make ROM calls to be used with either the text screen or graphics screen.
Note:
The rest of AUX may still be used as /RAM disk: Instead of using
AUXMOVE, just use ProDOS to save the program code at $2000-$4000 to
the otherwise empty /RAM disk. The file is guaranteed to be placed at $2000-$4000 in AUX.
This is a popular method of reserving the $2000.3FFF memory space in Aux memory, by just saving a file that is $2000 bytes in length, to the /RAM disk.
2. In general like 1.), but use AUX $2000-$4000 as trampoline to
switch $800-$2000/$4000-$BF00 between MAIN and AUX. The code accessing
the hires video RAM can be located in either MAIN or AUX.
I hope what I have stated so far makes sense and shows why this method cannot be used.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)