Payton Byrd wrote:
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.
Any Apple with at least 64K of RAM can bank out the ROMs as well. The mechanism is different of course, but if it's abstracted in Kernel routines that shouldn't matter.
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).
It's $D000 to $DFFF. But otherwise you're right.
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?
In the Apple the I/O space lives at $C000 to $CFFF and unlike the C64 it can't be banked out. The ROM space is $D000 to $FFFF and can be banked out on 64K or higher systems, but only as a single whole; that area is either all ROM or all RAM. Instead of the unusable (for RAM) $C000 area, there are two different banks of RAM that can be made visible from $D000 to $DFFF (in addition to the ROM).
The Apple is more restricted regarding the memory location of the visible hi-res screen than the C64. It can live only at $2000 to $3FFF or at $4000 to $5FFF, and the memory is organized differently. So any applications that write directly to screen memory will not be compatible. Also, the resolution is different, it's 280x192 instead of 320x200 (provided Apple GEOS runs at "Standard Hi-Res", not "Double Hi-Res"; the latter would be 576x192). Any applications that depend on 320x200 won't work on the Apple.
Beyond 64K and at double-hires resolution, things start to be very different between the C128 and the 128K Apple IIe. The Apple does 80-char text and double resolution graphics by using parallel sections of memory from both banks. The C128 has a second, very different graphics chip for this (the VDC), with its own dedicated VRAM. Programs that depend on this sort of stuff are most likely going to be incompatible.
And of course, the floppy disk formats are different and Apple 5.25" disks have only 140KB capacity; bootable disks need an OS, including the low-level disk handling routines, on the disk, unlike the Commodores which have disk handling routines in the drive ROM. Commodore drives are a computer of their own with its own CPU, RAM and ROM; Apple drives are not, all the hard work is done by the host CPU. This means also that Apples can't really do much anything else (including reacting to the mouse) while reading from or writing to the disk, since this has to happen in very tight loops that leave no time for other things. No idea if that would be any problem for GEOS. Also the file structure on Apple disks is usually different from commodore disks, there aren't any pointers in the first two bytes of a sector, instead all files are organized a bit like Commodore's "relative files", with side sectors. Programs that depend on the low-level file organization are therefore probably not portable, unless Apple GEOS copied the Commodore's file structure instead of using the usual Apple structure.
Apples don't have sorta-kinda-protected RAM area, such as the Commodore has at $C000. Therefore, it's probably not possible to exit to BASIC from GEOS, run a BASIC program, and then be able to reenter GEOS with the Kernel usually still intact.
-- Linards Ticmanis