> > > Don't forget Diamond which is a GEM TOS "look-alike" version designed for the
> > > Atari 8bits which original came on disk and then came on Super Cartridge
> > > format. Designed by Reevesoft.
> > Does the GEM TOS have any relationship to the GEM OS that was available
> > for the PC? (Other then name)
> They had a common origin in GEM 1.2. The ST GEM ran on top of TOS.
Well, yes and no. first of all, it didn't run ontop of TOS ...
TOS was tha name given by Atari to the whole OS software,
including GEM.
TOS looks like:
BIOS/XBIOS
GEMDOS (and GEM BIOS)
VDI (and GDOS)
AES
DESKTOP
The lowest layer is the BIOS, which is quite similar to a PC BIOS.
Youll find most of the PC BIOS functions - realy, it looks amazing
similar. Beside the BIOS there's the XBIOS for extended Functions,
like screen base handling etc. The XBIOS also included functions
for sound handling (interrupt driven play lists etc.) or the basic
keyboard maps. On the falcon the DSP handling was done thru XBIOS
calls. I'm not shure, but IIRC the very basic graphic primitives
(set point, line draw, any kind of bitblit operations) where also
handled by the XBIOS thru a service called Line A function, a
feature provided by the 68K CPU - all opcodes sarting with Ax
where reserved and lead to an exception. The basic idea of in the
ST desin was to make graphic primitives as extened opcodes, so
they could introduce a graphic coprocessor later on to speed up
tha execution - and until then do it by software.
The BIOS handles all basic setup stuff and the 'boot' process -
usualy scanning disks for boot code to be executed. These boot
files are usualy onl add ons (like hard disk drivers) and return to
the BIOS, which finaly loads GEMDOS from ROM. Of course there could
be a real boot process of a different OS, or a (newer) disk version
of TOS.
Next in Row is the GEMDOS. If you ever played with the DOS interface
(Int 21h) of PC DOS >2.0, you know exactly what you find. Literaly a
copy of DOS. Even the function numbers are the same. Due the different
processor structur parameter passing was different. You had to push
all parameters on the stack and issue a TRAP instruction (The BIOS
did it the IBM way in registers). Even some internal structures where
_very_ similar to MS-DOS 2.x - inclunding the bufeer handling.
To be correct, internaly GEMDOS had anoter part called GEM BIOS,
which was supposed to be a hardware independent BIOS ... well, or
something like that. the structures where somewhat mixed, so one
should considere GEMDOS/GEM BIOS as one thing.
What DRI/Atari did until here was more or less recreating a PC DOS
like environment, so GEM could be running on top. GEM itself was
composed of two parts: the VDI (Virtual Device Interface) and the
AES (Aplication Environment Services).
The VDI did handle all graphic operations available to GEM programms.
from line drawing to text output. All programm operations where made
on to virtual devices, while the VDI did map them to real coordinates
on real devices. To load new device drivers the GDOS (Graphics Device
Operating System) was supplied. On the ST the GDOS was quite important,
since the ROM only included a driver for the standard ST screen, mouse
and keyboard. To use the device independant luxury of GEM with printers
or whatever, new Drivers had to be made ... now, such a concept was in
1986 still revolutionary, so a lot of programms still used classic
style printer drivers. It took several years (until ~ 1990) to get most
applications realy use the advantages of the VDI (and GEM). Doesn't that
sound like the storie of Win 3.x :)
Well, the next (and for GEM topmost) layer is the AES. The AES did all
the usual work of a GUI: Dialog boxes, menue bars, pop up menues, input
fields, drop worn lists, window handling, etc. pp. The AES also offered
services to support a desktop application - linke reading and writing
the shell file (Which would be called WIN.INI under Windows :)
As the final part, TOS included the DESKTOP.APP application, which
supplied the user visible dektop.
CP/M compatibility:
As for the CP/M issue someone mentioned. I'm not shure if there ever
was a GEM for CP/M. but there was the GSX (Graphic System eXtension).
which incooperates most features of VDI and AES. Even things like
the "application controll block" (Sorry, no idea about the original
name), a structure which held all information about the actual prog,
the used resources etc., basicly the root to build a multi tasking
or at least multi application system (a part of the AES) was already
available in GSX. Also all sata structures used for the VDI where
exactly the same as found in the GSX. GEM is a real sraight foreward
development from GSX (and CP/M 3.0).
It may be true that the tale of CP/M 68k beening an accessor of TOS
is originated on the fact that the first development tools sold by
Atari where one on one ports of DRI tools for CP/M 68K - and noone
did edit the manuals at all - you you found CP/M 68K mentioned on
every other page. Also, if you where an early developer, you got a
development version of CP/M 68k to run on a ST.
> The guy who wrote it for DRI (Lee Lorenzen) was one of the Xerox Parc
> people who really developed the GUI as well as mouse usage. Jobs
> glommed his Mac ideas as well as numerous coders from Parc and then
> sued DRI for copying the Mac. He won and DRI was forced to cripple later
> versions and never marketed it very seriously even tho it preceded Windows.
Interesting.
> For some reason Apple didn't go after the ST or Ventura Publisher which
> used GEM. Lorenzen was one of the founders of Ventura.
GEM and the PC:
On the PC only the AES and VDI parts made up GEM. Apple never sued
DRI about GEM itself. All the wuss was about DESKTOP.APP, the shell.
When DRI lost, only the shell had to be changed, which lead to the
infamous two window design of DESKTOP.APP in GEM 3 and up. Application
programms where not included. And the Publisher didn't use DESKTOP.APP,
but was the application itself.
DRI did continue to develop GEM afterwards for some time, but with
the 'fixed' DESKTOP.APP, sales where not as good as it could be.
GEM itself did get some inprovements, especialy with additional
drivers and so on for GEM 3 and 4 - and all you had to do is install
the new version and then copy back your old DESKTOP.APP :)
In fact GEM was a real good example of hardware independant
programming. At this time I used a SIEMENS PC-D as main computer.
A 80186 machine with NO IBM hardware compatibility at all. GEM 1.2
was the only Version ever ported to this computer, but is was no
problem at all to install GEM 2 and GEM 3 on the machine from
standard PC distributions. All I had to do was to put the SIEMENS
specific drivers back into the right directories and add their name
to the driver lists. I liked it a real lot.
Anyway History
H.
--
VCF Europa 3.0 am 27./28. April 2002 in Muenchen
http://www.vcfe.org/
Received on Wed Apr 10 2002 - 14:08:20 BST