I have the Official GEOS Programmer's Reference Guide for GEOS 1.x from
Berkley Softworks, which is what prompted my questions. It describes
the GEOS kernel and in it that GEOS applications should be portable
since the kernel is responsible for preparing and driving the screen,
handling I/O (including a rich disk handling API), etc. It uses
drivers for input and printing to abstract out these functions as one
would expect. So, when I recently saw the message on C.S.CBM
indicating some successfull level of compatibility between the 64/128
and +4 versions of GEOS, it seemed natural that an Apple II version
should be compatible as well.
Obviously, the C64 uses the 6510 CPU instead of the 6502, which has
some fundamental differences are far as memory management is concerned.
In GEOS for the 64, the Kernel has routines for mapping in/out the ROM
that underlies the system's RAM via ZP $01. This allows GEOS
applications to be compiled to bank the BASIC and CBM Kernel ROMs
in/out and write applications that use them. Obviously, such
applications would not be portable to the Apple II, but I believe if
you stuck with the GEOS Kernel's routines, and didn't do any bank
switching, you should be OK.
It may be a matter of practicality. On the 64, GEOS takes over the
entire 64K of RAM, completely banking out the system except for the I/O
space at $DF00 to $DFFF (if I remember correctly). This gives
approximately 22K free. If you tell GEOS not to provide a secondary
screen buffer, your application can have 30K free, but it becomes
responsible for repaints from showing dialogs and menus. I don't know
how much memory the Apple II version of GEOS would have availabe for
applications. What is the capability of the Apple II to bank out ROM
and use RAM at those locations?