Re: [cc65] Apple2 file io - here: memory management questions

Oliver Schmidt wrote:

>Hi,
>
>as memory is always a very precious resource on the Apple2 I'd like to shed
>some light on the memory management side of file io...
>
>The Apple2 has lower memory from $0000 to $BFFF (48 k). At least for text
>mode programs $0800 to $BFFF (46 k) is available. Then there is a memory
>mapped io area from $C000 to $CFFF (4 k). From $D000 to $FFFF (12 k) we have
>upper memory.
>
>
>  
>
I agree.  Depending on the machine - the ROMs are in the $D000-FFFF 
range,  the IIc, IIe & IIGS have auxillary memory to play with.

>1. scenario: DOS 3.3 : $800 - $9600
>  
>
<snip> I assume most people using 3.3 would be here.  Might be another 
target (.cfg) though.

>2. scenario: DOS 3.3 in upper memory
>  
>
<snip>

>3. scenario: ProDOS 8 with command interpreter
>  
>
<snip>

>4. scenario: ProDOS 8 without command interpreter
>
>  
>
<snip>

I assume that the simplest scenario for both is $2000-$9600 which is  
29.5 K. Once the file io tests pass, then I'll start putting in the 
extras. Out of that 29.5K, I allocate 8K for static buffers.  Overkill ? 
Maybe.  Which leaves 21.5K for a text program.  Someone who wants to use 
hires will lose another 8 - 16K for ~22K total or 13.5K program - buffers.

>- The application has to call a special quit API on exit. The called quit
>routine will then allow the user to load the next application (for example
>the command interpreter).
>
>  
>
The crt0.s is per library - there really is nothing stopping us from 
adding a jsr to a __filecleanup which can close files and "quit" instead 
of a "JMP RESTOR" or back to basic.  The DOS 3.3 cleanup would be back 
to basic.

    jsr __closeallfiles

; put back zero page stuff
    ...
    jmp __dos_quit  ; used to be a jmp   RESTOR

Most of the functions will have the same signature which will be 
structured as  (synopsis of the last couple of emails)

Apple2 -> main functions
                  dos33 (dir) -> dos 3.3 functions
                  pdos8 (dir) -> ProDOS 8 functions

Make file will build main apple2.o & apple2.lib with a2dos33.o 
a2dos33.lib and a2pdos8.o a2pdos8.lib

Most developers will have to :
   cl65 -t apple2 -L a2dos33 myprog.c
OR
   cl65 -t apple2 -L a2pdos8 myprog.c

Problem: What if developers don't want a DOS link ? A nodos directory 
with __dos_quit ?

>Results for ProDOS 8
>
>As scenario 3. leaves only 35,5 k for a text mode program it is desirable to
>support scenario 4. with 45,7 k of available memory. For applications with
>large amounts of CODE + RODATA + DATA (in other words a large binary file)
>it may simply be impossible to load the file at $2000. Therefore the
>approach with a small loader seems to be appropriate.
>
>The major part of this loader could be written in C and use the new file io
>library to load the main binary at $0800 and jump to it. It would have a
>custom startup code relocating the loader from $2000 to let's say $B000.
>This area would then wiped out later by the BSS, heap or stack of the main
>executable.
>
>  
>
$D000 - $FFFF : Bank Switched memory & ROMs
$C000 - $CFFF : Slot & softswitches
$9600 - $BFFF : Misc use. A ProDOS "System" program can use.
$6000 - $9600 : available
$4000 - $5FFF : hires 2
$2000 - $3FFF : hires 1
$0800 - $1FFF : available (~6k)  OR $0C00 - $1FFF : available (3K)
                                                            $0800 - 
$0BFF is text screen 2

I need to read up on the config file again.  I was thinking of:
    RAMLOW: start=$800, size=$17FF;
    RAM: start = $2000, size = $7600, file = %O;
    HIRES1: start = $2000, size = $1FFF;
    HIRES2: start = $4000, size = $1FFF;
    RAMHIGH: start = $6000, size = $3600; # $9600 begin prodos

HIRES1 & 2 could be "DATA"

>The loader would be identical for all cc65 applications and just have a
>different name. ProDOS 8 supports "argv[0]" so the loader could detect from
>that the path of the main binary with a pattern like MYAPP.SYSTEM for the
>loader and MYAPP.BINARY for the main binary.
>  
>
Loader - hrrmmm...  load into HIRES1, run from RAMLOW ?  I'm not sure 
how this will work -yet.

>A benefit of this approach would be that the startup code for DOS 3.3
>binaries and ProDOS 8 main binaries could be shared. Just the last call at
>the very end of the startup code would have to go into the file i/o
>libraries instead of being hardcoded in crt0.s. A destructor which never
>returns doesn't look like a clean solution - does it?
>
>Setting up a RESET handler for closing files 
>
Again - the crt0.s can be modifed to call "quit" .  I need to understand 
"condes" better.

>Oliver
>  
>

Great stuff !  Gives me a lot to consider.

Thanks
Jim

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.