[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 16-bit GS software?



ruud.dingemans <ruud.dingemans@wanadoo.nl> wrote:

> I'm wondering, what software ever came out for the IIGS that
> specifically used the 16-bit CPU in this machine? AFAIK, GS/OS did, but
> what were the (most popular/best?) others?

Every program which runs natively under ProDOS-16 or GS/OS by definition
must use the native mode of the 65816 CPU, and therefore operates in
16-bit mode (except while temporarily using 8-bit native mode, e.g. to
manipulate 8-bit data such as text).

A program running natively under GS/OS should not be confused with a
ProDOS-8 application which you happen to launch while booted into GS/OS
- you can tell the difference by the fact that GS/OS actually runs
ProDOS-8 for you when you launch a ProDOS-8 application (and quitting
that application will usually return you to your GS/OS-based program
launcher, such as Finder).

There are also some programs which run under ProDOS-8 which make use of
the 16-bit mode of the CPU.

The first example which occurs to me is the Merlin 16 assembler, which
ran under ProDOS-8, and required a 65816 or 65802 processor, using
native mode to get a significant speed improvement over Merlin 8, which
only required a 6502 processor and ran in 8-bit mode.   Merlin 16+ was a
significantly improved version of Merlin 16, which ran natively under
GS/OS.

Some parts of AppleWorks 2.0 and later make use of 16-bit mode in the
IIgs to allow access to all the RAM, rather than being limited to the
first 128K.

> Any games?

I'd expect that most IIgs-native games would make full use of the 16-bit
mode in the CPU, except where dealing with legacy firmware, which
requires the CPU to be in emulation mode.

> Word processors or paint programs?

AppleWorks GS is the obvious example.  There were several other
GS/OS-native word processing and paint programs.

> And was the difference actually noticeable?

It depends what you mean.  There are three main issues:

- Speed of code execution.

Calculations which are able to make use of 16-bit mode will be
substantially faster than a comparable 8-bit program.  An ideal example
of this is ShrinkIt GS, which is considerably faster than any 8-bit
version of the program.

- The ability to access more memory.

A program which is restricted to using 8-bit mode is also limited to the
memory available in an 8-bit Apple II, i.e. 64 KB, with bank switching
to get access to an additional 64 KB.  Programs which make use of the
native mode of the 65816 are able to use the Memory Manager to reserve
memory areas outside the first 128K.  Increasing the available address
space makes a big difference.  Classic AppleWorks would be an ideal
example of this.

- User interface.

Most GS/OS applications run in graphical mode, making use of the toolbox
provided by the operating system to present a user interface with menus,
windows, the mouse, etc. ("desktop" metaphor).  The fact that the
program is running graphically will tend to slow it down in comparison
to an 8-bit application running in text mode, simply because there is a
lot more data to be processed when dealing with a graphical user
interface.

The big advantage of the graphical user interface is that it is
consistent between applications.  Text-based 8-bit software tends to be
a complete hodge-podge of user interfaces, with each program working
differently from others.  There have been some attempts at
standardisation, such as the classic AppleWorks filecard-based
interface, which is used in several other programs.

There are some 8-bit applications which present a graphical user
interface similar to GS/OS: MousePaint, MouseDesk and Publish-It! come
to mind.  GS/OS native applications have a major advantage over these
programs because the user interface is consistent over all GS/OS
programs (rather than being implemented directly by each application,
with subtle differences), and desk accessories are available which can
be used in any application.