Badly put. I do know better. A lot of the later mods for the ST were really
interesting too. Geneva, Magic and Terradisk come to mind. There was a lot
of development that came out of Germany for the ST.
Good stuff Hans.
Lawrence
> > > 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/
lgwalker_at_mts.net
bigwalk_ca_at_yahoo.com
Received on Thu Apr 11 2002 - 00:16:31 BST