Re: Apple IIGS ROM listings and a general OS question

["Mark Cummings" <NOTfigjams@primus.com.au>]

> A second question. I have been told that GS/OS allows hardware
> abstraction (ie a compliant app can access all system resources though
> the OS and does not need to know about the underlying HW) how complete
> is this abstraction? Do most programs use it or do they bit-bang the
> physical hardware locations??

This is true and recommended by Apple. Basically all GS/OS use a system of
tool calls. The user loads up the parameters to pass to the tool, the tool
number and makes the call. The rest is handled by the tool. If the tool gets
upgraded or bugs removed, the program doesn't need to be changed.

Apple realized the problem of hardware specific bit handling much further
back than GS/OS, and developed this principle with the IIe & ProDOS &
interface cards. The Platinum IIe was stated as having a 95% (as best as I
can remember) compatability with all software for the IIe. The ones that
weren't compatable were mainly those that didn't follow the documented
calls.
It was recommended for programmers to use only the documented entry points
so that when Apple made changes to the ROM, the programs would still run.
This is why sometimes when disassembling the newer ROM you will see a jump
to some other location to do the work. This principle then carried on to the
operating systems, and I believe is what made Apple a superior developmental
machine.

Of course there are very good programs for the GS that don't adhere to
Apple's rules of using tool calls, FTA is one such company that wrote a
couple of classic and very fast programs, one I know of is Photonix, a disk
copy utility. If Apple decided to change the hardware or firmware, this
program may not be compatable. There is little reason to worry about that
ever happening now, but this is the main reason that this program can't quit
to GS/OS, because it breaks the rules and mucks up memory.

Mark