Write up on Tech geek history: Atari 1979 Operating System

Atari TOS Version 1.0 TOS is the operating system designed for the Atari ST and TT series of computers. The Atari ST and TT use a Motorola 68k based CPU (The same CPU used by early Macintoshes) and was first manufactured in 1985. The operating system consists of two parts. TOS – “The Operating System”. Kind of a customized version of CP/M provided by Digital Research. GEM – “Graphics Environment Manager”. The GUI shell that runs on top of TOS. This shares much in common with the DOS version of GEM. Both TOS and GEM are stored entirely in the system’s ROM. This is the GEM desktop running on TOS displaying its desktop info screen. The actual resolution of the default display is 320*200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640*400 for viewability. This is the GEM desktop running on TOS displaying its desktop info screen. The actual resolution of the default display is 320*200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640*400 for viewability. This is a blank desktop. Instead of disk icons, there are file drawers. The drives / drawers are assigned letters A, B, C and so on, similar to how CP/M and DOS organize drives. Just imagine if IBM had gone with CP/M for the original IBM PC instead of Microsoft DOS.

We might all be running Digital Research GEM 2004 right no The windows in TOS/GEM are Mac-like and can overlap and resize. None of the versions of GEM for Atari TOS were affected by the Apple lawsuit so all of the Atari versions retained these feature The TOS is the native Atari operating system, which comes together with each Atari computer. The first version, 1.0, also known as RAM TOS was loaded from disk, each next version is burned into system ROM at the factory. Each TOS version Atari has developed, apart from the official number, is also known under an unofficial name: TOS 1.0- RAM TOS, since it was loaded from disk and resided in the system RAM. TOS 1.02- Blitter TOS was introduced with the Mega ST computer and contained routines supporting the Blitter, a graphic co-processor. TOS 1.04- Rainbow TOS, since it displays a rainbow Atari logo in the info box. TOS 1.62- STE TOS was introduced with STE computer series. TOS 2.0x- Mega TOS was developed for Mega STE computer. TOS 3.0x- TT TOS was developed for the Atari TT030. TOS 4.0x- Falcon TOS also known as 3D TOS is present in the Falcon030 computer and provides 3D-looking window elements. TOS 5.0- the real Falcon030 TOS was supposed to become the native system of Falcon computers, but has never been officially released. The only available version is a beta release known as TOS 4.92. The non-multitasking TOS, to be differentiated from the MultiTOS, is also known as the SingleTOS. System structureThe TOS consists of four main parts, each one can be replaced by a RAM-based substitute: BIOS, Basic Input/Output System, provides several hardware dependent functions and is basically compatible with PC BIOS.

Additionally, the ST-BIOS contains an enhancement, known as XBIOS(Extended BIOS). The XBIOS functions are strictly platform dependent and aren’t compatible with any other computer, but ST. GEMDOS, is the main file management subsystem. The GEMDOS has been developed by the Digital Research, Inc. and is compatible with DR-DOS. The GEMDOS may be replaced with MiNT kernel in order to use MiNT networking software. VDI, Virtual Device Interface, is a library of hardware dependent graphic functions. Generally, it is responsible for drawing basic screen elements (points, lines, filled and empty objects, fill textures, fonts etc.) and controlling the mouse. The VDI has also an optional, loadable extension called GDOS, mainly responsible for font management. Latest GDOS versions support Bitstream and True Type character sets.

The VDI may be replaced with NVDI, which is much faster and provides some additional functions. AES, Application Environment Manager, is a fully hardware independent window and application manager. The AES and the VDI, both developed by the Digital Research, Inc., are known as GEM, Graphic Environment Manager. The standard AES (version 3.40 in Falcon TOS) may be replaced with the MultiAES (AES 4.10), a part of MultiTOS 1.08 or with the Geneva, which converts the TOS to a co-operative multitasking system. Besides of that, the system ROM contains also the GEM Desktop, i.e. an application program directly responsible for user interaction with the TOS. This structure, in order to keep compatibility with the TOS, is present in some other operating systems. Short characteristicThe main advantage of the TOS is that it is fast, stable and not memory hungry – if you don’t load many TSRs, it gives you about 3,7 MB of TPA on a 4 MB machine, since it doesn’t utilize the system RAM to keep it’s own code into. But even considering that the system resides in ROM, you must prove that the TOS code is generally compact: the latest version, Falcon TOS, fits in a 512k chip together with the desktop and five resource files for five different nationalities. Also notice, that the TOS will work fine even if there is no hard drive connected – you can run the system from a floppy and have a serious chance, that all necessary system files won’t take more than 1% of the capacity on a standard 1,44M diskette.

‘ The main disadvantage of the TOS is that it doesn’t support true multitasking: only one application can be used at once together with up to six so called accessories, which have to be loaded at startup and must be present in the memory all the time the system is running. The accessories may run in parallel with the main application using some sort of cooperative multitasking – the system switches the CPU time between those seven tasks if they interact with the GEM. If the application or one of the accessories executes an operation which runs without any system call, task switching is impossible and the rest is stopped. Additionally, the TOS doesn’t support big logical drives. You can have up to 16 logical drives, 14 of them can be hard disk partitions. Each one is limited to 32766 data clusters, up to 16384 bytes each. It means, that the maximum capacity of a partition is about 512 MB. Summa summarum, the TOS cannot be currently considered as a modern operating system, but one has to remember that the latest version of the system has been released four years ago. That time big hard drives were rather rarely used in home computers and only one of popular operating systems supported true pre-emptive multitasking, namely the AmigaOS. Now the TOS is a bit out of date and has few devotees in the Atari community. Majority has moved to systems mentioned below.

MultiTOSThe multitasking TOS The MultiTOS has been developed by Atari Corp. to be a TOS replacement for those who would like to have a true multitasking system. Unlike the TOS, the MultiTOS is a fully RAM-based system and in fact consist of the MiNT kernel (that is described in one of the further sections) and a new, multitasking version of the AES (MultiAES). Due to this reason, the MultiTOS can theoretically support all of the MiNT possibilities, since in fact it is nothing else than the MiNT configured to be TOS and GEM compatible.

The MultiTOS provides the true, pre-emptive multitasking and supports many additional functions which are needed in such a system, e.g. memory protection, multiple filesystems, startup sequence scripts, standardized system enhacements, easy task selection, window iconification, loadable accessories, unlimited number of concurrent applications and many more. Additionally, it is much more configurable than the TOS and follows the general trend in programming of a modern operating system. Unfortunately, bad financial condition in 1993. has enforced the Atari Corp. to drop all ST-line support. MultiTOS was one of the victims of that decision. The latest official version, 1.04, was not perfect and has been quickly forgotten by the Atari community. Interestingly, the latest unofficial beta, MultiTOS 1.08, was way better and has began a general guideline for programmers developing software and replacement operating systems. In fact, the MultiTOS 1.08, never officially released, never officially supported and used only by a few heroical devotees – has become a standard. MagiCA way to new hardware The MagiC has been introduced to the market about two years ago by a German company called Application Systems Heidelberg, previously known as the developer of a C compiler (Pure C) and has become popular very quickly, breaking the Atari community into Magic’s devotees and enemies

. The MagiC is a modern operating system without any doubt. It is probably also the only and unique complete TOS replacement, which doesn’t use any of the TOS components. It follows the main MultiTOS guidelines (though some of the MultiAES, or even Falcon AES, functions are missing) and, furthermore, tries to enforce a new standard for software developers by supporting many of Digital Research GEM/2 functions (which are missing in the Atari GEM) as well as several own enhancements. Besides of the multitasking (both pre-emptive or co-operative, depending on a user selection), the MagiC supports a new filesystem in order to allow you to use long filenames and really big disks, easy task management, background DMA transfers, fast GEMDOS, fast AES, fast VDI and many more features. Additionally, although it is a RAM-based system, it is compact and not memory hungry – the whole system takes less than 300 kilobytes. Furthermore, it opens a way for the Atari community a way to use GEM applications with newer hardware – since there’s no hope to see new products of the Atari Corp. as the company is dead, the Application Systems Heidelberg released the MagiC versions for Apple computers and PCs. They are claimed to be GEM compatible and are supposed to allow you to use GEM applications on these platforms. MiNTA bridge to Unix The MiNT is a system originally based on the BSD package ported to ST computers by Eric R. Smith. It was supposed to be a backdoor for the Atari community to the Unix world with loads of BSD based network applications. A short (1992-94) romance of the MiNT and Atari Corp., which decided to convert the system to the MultiTOS kernel, has caused a birth of an unique TOS/Unix hybrid, which gives you simultaneous access to both GEM and BSD application libraries. Since the MiNT is the MultiTOS’s kernel, it has kept all the features described above and, if an AES replacement is installed, it can show you a new face of the MultiTOS. Unlike the MultiTOS however, the Unix-like MiNT is based on a different filesystem, which is much faster and more flexible than the TOS FS. Furthermore, thanks to the excellent network support, the MiNT gives you an unique possibility to convert your Atari to a true Internet server, which will still be able to run GEM and TOS applications! Thanks to this feature, the MiNT has a lot of devotees in the Atari community(they’re recently considered as MiNTquisitors) and is the main competitor for ASH’s MagiC.’

Unlike the Linux, the MiNT contents itself with Motorola 68000 without an FPU, but similarly to other Unix systems it requires much more memory to work in a decent setup. A 4 MB is an absolute minimum, if you want to have a multiuser configuration however, and to run GEM applications at the same time, it will require at least 8 MB or more Operating system summaries Sampling Criteria Problem of Content the five years between 1978 and 1983, the videogame industry saw a huge surge in popularity, a halcyon period of soaring profits and new consoles.

The operating system consists of two parts.

TOS – “The Operating System”. Kind of a customized version of CP/M provided by Digital Research.

GEM – “Graphics Environment Manager”. The GUI shell that runs on top of TOS. This shares much in common with the DOS version of GEM.

Both TOS and GEM are stored entirely in the system’s ROM.

This is the GEM desktop running on TOS displaying its desktop info screen.

The actual resolution of the default display is 320*200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640*400 for viewability.

The development started in 1983. It was marketed into the 1990’s, both as a GUI shell sold as GEM Desktop for operating systems such as CP/M, DOS and FlexOS but also as a shell less graphics library primarily sold on an OEM basis as that could be used to develop and ship graphical applications that worked on the aforementioned OS’s even though they did not have a graphical shell installed.

It is based on the GSX vector graphics interface library that was primarily built on components the company licensed from Graphic Software Systems and development of it was started as soon as GSX had shipped in 1982 although GEM itself was not officially shipped as a desktop retail product until February 1985 (OEM software was sent out in 1984, though). GEM was highly influenced by both the Xerox Star and the original Apple Macintosh and featured a user interface somewhere in between those two, this was not unexpected as GSS Inc. head honcho Lee Lorenzen had worked on the development of the graphics engine and Interpress for the Star at Xerox.

While not a big seller for the company it did manage to outsell Microsoft Windows by a considerable margin up until the release of Windows 3. The best known version of the system was on Atari ST computers where it was used as the GUI component of TOS. A number of European vendors of IBM PC and other Intel based hardware used the system, most notably Amstrad with their PC compatible budget computers and Apricot with their Sirius compatible systems.

There was also a lawsuit brought in by Apple in 1985 that ran into 1986 that stopped USA based computer manufacturers from shipping it with their systems since Apple had threatened to go after any maker that shipped GEM with their system and Digital Research simply did not have the financial wherewithal to offer OEM’s indemnity from Apple’s lawsuit.

Even as if not a big hit it became quite an influential product in the PC world, not the least since Microsoft Windows was developed in response to it, but there was the air of a missed opportunity about the whole project. GEM worked on hardware that was much slower than what the competition was using for their GUIs which was mostly processors like the 68000, Z8000 and 320016 which outran the 4.77MHz in an IBM XT class machine GEM was designed for quite comfortably, but at the same time GEM on an XT was quite reasonable if not exactly fast.

Even though the basic vector drawing engine in GEM was considerably stronger than what Windows had to offer. The Windows version was simply bog slow compared to GEM and almost unbearable on an XT, showing that DRI’s software was much better optimised for low power hardware such as XT class machines than Microsoft’s shell.

GEM simply gave customers a much better experience on the hardware of the time. Also Digital Research had released a GUI word processor and other graphical applications but for some reason did not develop these products any further.

The Apple lawsuit somehow managed to take the wind out of the marketing of GEM and DRI’s CEO Gary Kildall was by that time showing much more interest in his Grolier CD-ROM project than in promoting GEM. Development of the system and related software was cut down considerably in late 1986 although a GEM 3 was eventually released in 1988, but that release had none of the features that had been in shown in the GEM/XM beta of 1986.

8.2 AES fundamentals

The AES(Application Environment Services forms the highest level of GEM. It deals with all those parts of GEM that go above elementary graphic output and input functions. As the AES works exclusively with VDI and GEMDOS calls, it is completely independent of the graphic hardware, of input devices as well as of file-systems.

The AES manages two types of user programs: Normal GEM applications with file extensions ‘.PRG’, ‘.APP’ or ‘.GTP’, and desk accessories with file extensions ‘.ACC’.

Unless you are using a multitasking operating system such as MagiC, MiNT or MultiTOS, the AES can only run one application and six desk accessories at a time. Desk accessories (with an ‘.ACC’ extension) allow quasi-multitasking even with plain TOS: They are usually special GEM programs loaded (wholly or partially) at boot-up from the root directory of the boot drive (normally C:\), which remain in memory and can be called at any time from GEM (and some TOS) programs by clicking on their entry in the first drop/pulldown menu. In other words, desk accessories can be called and used while another application is running and has its window(s) open, even with a single-tasking operating system such as TOS. Note that this is not real multi-tasking, as the main application is suspended while the accessory is executing and only resumes when the accessory is exited.

Unlike applications, desk accessories don’t interact with the user immediately; most just initialize themselves and enter a message loop awaiting an AC_OPEN message. Some wait for timer events or special messages from other applications. Once triggered, they usually open a window where a user may interact with them. Under TOS, accessories should not use a menu bar and should never exit after a menu_register call. Loading of any resources should happen before the accessory calls menu_register, and these resources should be embedded in the desk accessory rather than being post-loaded, as on TOS versions earlier than 2.06 memory allocated to a desk accessory is not freed at a resolution change; thus memory allocated with rsrc_load is lost to the system after a change of resolution with the early TOS’s.

When a desk accessory is closed under TOS, it is sent an AC_CLOSE message by the system. Following this it should perform any required cleanups to release sytem resources and close files opened at AC_OPEN (the AES closes the accessory’s windows automatically). Following this it should reenter the event loop and wait for a later AC_OPEN message.

The following points are covered in this section:

For the AES too there have been some interesting developments, as various programmers have meanwhile announced their own AES clones; at present one can mention projects such as N.AES and XaAES. Besides constant evolution one may hope also for source texts of these GEM components.

8.2.1.2 Accessories in MagiC

Under MagiC, desk accessories are almost equal to programs. Their windows are maintained at program changes. They may have menus and desktop backgrounds, post-load programs, allocate memory, open/close/ delete/copy files etc.

As there is no longer any reason to close windows at program changes, there is no AC_CLOSE message any more. The system does not distinguish desk accessories from programs, apart from the fact that they may not terminate themselves. As under GEM/2, accessories can also deregister themselves in the menu, using the AES call menu_unregister.

In place of accessories, under MagiC it is more sensible to use applications that simply register one menu bar with one menu, and lie in the APP autostart folder. These applications can be loaded when required, and also removed again afterwards.

Note: As of MagiC 4, desk accessories can be loaded also while the system is running (not just at boot-up). Furthermore accessories can be unloaded by clicking on the corresponding accessory entry in the first menu while the [Control] key is held down. One disadvantage is that at present accessories may not perform Pexec with mode 104.

8.2.2 The desktop window

Of the available windows, the desktop or background window plays a special role. It has the ID 0, occupies the whole screen area, is always open and also cannot be closed. The working area is the area below the menu bar. Only in this working area can other programs output to the screen or open their own windows.

Normally the working area of the desktop appears as a solid green area (in colour resolutions) or as a grey raster pattern (in monochrome operation). The screen-manager attends to the screen redraws all on its own; with a call of wind_set, other application programs can anchor any other object tree as a background. In that case too the screen-manager looks after any required redraws of sections of the image. Although this possibility is very alluring, there are several reasons that point against the use of the desktop window; the most important:

Even under a multitasking-capable GEM (MagiC or MultiTOS), there can be only one screen background. This should be reserved for the program that can make the most use of it – as a rule this is the desktop or a desktop replacement such as the Gemini shell, Thing or Jinnee for instance.

To sum up: If possible, the desktop background should not be used in your own programs.

8.2.3 Data exchange via the GEM clipboard

To store files in the clipboard, one should proceed as follows:

Delete all clipboard files that match the mask ‘scrap.*’ and ‘SCRAP.*’. Note: The mask ‘SCRAP.*’ must be allowed for because old programs knew nothing of alternative and case-sensitive file-systems.
Save the data to be stored in one or several formats.
Send the message SC_CHANGED to all applications in the system and SH_WDRAW to the system shell.

The filename is always ‘scrap.’, the extension (suffix) depends on the selected format here; if possible one should always support one of the following standard formats:

Suffix	Meaning
gem	Vector graphics in metafile format
img	Pixel images in XIMG format
txt	ASCII text file, each line terminated with CR/LF

In addition one can support one or more of the following formats (the receiver then has the option of using the option with the greatest amount of information):

Suffix	Meaning
asc	ASCII text file, each paragraph terminated with CR/LF
csv	ASCII file with comma-separated numbers
cvg	Calamus vector graphic format
dif	Export file of spreadsheets
eps	Encapsulated PostScript
1wp	Wordplus format
rtf	Microsoft Rich Text Format
tex	TeX

The receiving program should first check which of the available files contains the most information, and then use this file.

Important: Each of the files in the clipboard contains the same information on principle, just in different formats. The text processor Papyrus, for instance, imports ‘scrap.rtf’ only if its own format ‘scrap.pap’ could not be found.

It should be clear from the above explanation that only one data object (though in different formats) can be present in the clipboard at any time.

Note: A few old programs, such as First Word and First Word Plus, are promiscuous and the clipoards they create automatically are scattered all over the place – usually the directory they are launched from. Some other applications may then use this clipboard rather than the ‘official’ one on the boot drive!

8.2.4 The object structure

Although the data structure of the object tree is not a tree in the sense of a binary tree, it nevertheless possesses within a pointer the logical chaining of a tree, with predecessors and successors (generally called ‘parents’ and ‘children’ respectively). The speci fication of parents and children is made via indices to an array.

The tree structure of the individual objects can be illustrated best with a simple example: A menu is composed at first of the menu bar. This in turn contains several title texts. The title texts therefore are contained directly in the menu bar, and are both children of the object ‘menu bar’, so they move on the same hierarchical level. The object menu bar refers with ob_head to the first menu title and with ob_tail to the last menu title. In the first menu title the pointer ob_next serves for addressing the next menu title. Thus the chaining shows the following structure:

Menu bar:

+———+———+——–+

| ob_head | ob_tail | … |

| o | o | |

+—-|—-+—-|—-+——–+

| +————————-+

V V

+———+———+——–+ +———+———+——–+

| … | ob_next | … | … | … | … | … |

| | o | | | | | |

+———+—-|—-+——–+ +———+———+——–+

1st menu title | n-th menu title

+—–> 2nd menu title

The actions that may be performed with a given object is specified in ob_flags. The state of an object is held in the entry ob_state. The entry ob_type determines the object type.

For an exact definition some objects need an additional data structure such as TEDINFO or BITBLK. In that case a pointer to this additional structure will be stored in ob_spec.

Summarising again the total setup of the data structure for objects OBJECT:

+————-+

| ob_next | Index for the next object

+————-+

| ob_head | Index of the first child

+————-+

| ob_tail | Index of the last child

+————-+

| ob_type | Object type

+————-+

| ob_flags | Manipulation flags

+————-+

| ob_state | Object status

+————-+

| ob_spec | See under object type

+————-+

| ob_x | Relative X-coordiante to parent object

+————-+

| ob_y | Relative Y-coordinate to parent object

+————-+

| ob_width | Width of the object

+————-+

| ob_height | Height of the object

+————-+

8.2.4.1 AES object types

The following types of object are available for selection:

Type	Meaning
G_BOX (20)	Rectangular box with optional border; ob_spec contains sundry information about border width, colour and similar matters
G_TEXT (21)	Formatted graphic text; ob_spec points to a TEDINFO structure
G_BOXTEXT (22)	Rectangular box with formatted graphic text; ob_specpoints to a TEDINFO structure
G_IMAGE (23)	Monochrome image;ob_specpoints to BITBLK structure
G_USERDEF (24)	User-defined function for drawing a customized object; ob_spec points to a USERBLK structure. (Note: In some libraries this is called G_PROGDEF for a programmer-defined function)
G_IBOX (25)	Transparent rectangle that can only be seen if the optional border does not have zero width; ob_spec contains futher information about the appearance
G_BUTTON (26)	Push-button text with border for option selection; ob_spec points to a text string with the text that is to appear in the button New as of MagiC Version 3.0: If the object flag WHITEBAK is set, and bit 15 in object status = 0, then the button will contain an underscored character; for this, (high byte & 0xf) of ob_state gives the desired position of the underscore (with a suitable library one can make the underscored character when pressed together with the [Alternate] key select the button in the dialog of a running application) On the other hand if bit 15 = 1 then we are dealing with a special button (radio-button or checkbox) Further specialties: WHITEBAK = 1, bit 15 = 1 and in ob_state: Highbyte = -2 Group frames Highbyte = -1 Special button, no underscore Highbyte != -1,-2 Special button, with underscore (Here again (high byte & 0xf) of ob_spec is the underscore position). The presence of these features is best established via the function appl_getinfo (opcode 13).
G_BOXCHAR (27)	Rectangle containing a character; in ob_spec both the appearance of the border and the character are defined
G_STRING (28)	Character string; ob_spec points to the string New as of MagiC Version 3.0: If the object flag WHITEBAK is set, and the high-byte of ob_state != -1, then a character of the string will be underscored; the underscore position is determined by (high byte & 0xf) of ob_state With WHITEBAK flag set and high byte ofob_state= -1 the complete string will be underscored. The presence of these features is best established via the function appl_getinfo (opcode 13).
G_FTEXT (29)	Editable formatted graphic text; ob_spec points to a TEDINFO structure
G_FBOXTEXT (30)	Rectangle with editable formatted graphic text; ob_spec points to a TEDINFO structure
G_ICON (31)	Monochrome icon symbol with mask; ob_spec points to the ICONBLK structure
G_TITLE (32)	Title of a drop-down menu; ob_spec points to the string. As of MagiC 2 one can also underscore one of the characters. This is done as follows: Set WHITEBAK in ob_state (ob_state >> 8) & 0xf Position of the underscore (ob_state >> 8) & 0xf0 is 0
G_CICON (33)	Colour icon (available as of AES V3.3); ob_spec points to the CICONBLK structure
G_CLRICN (33)	Colour icon; ob_spec is a pointer to an ICONBLK structure. Supported in the ViewMAX/3 beta and in FreeGEM.
G_SWBUTTON (34)	Cycle button (i.e. a button which alters its text cyclically when clicked on); ob_spec points to a SWINFO structure. The presence of this object type should be inquired with appl_getinfo (opcode 13).
G_DTMFDB (34)	For internal AES use only: desktop image. The ob_spec is a far pointer to a MFDB structure. Supported in the ViewMAX/3 beta and in FreeGEM.
G_POPUP (35)	Popup menu; ob_spec points to a POPINFO structure. If the menu has more than 16 entries, then it can be scrolled. The presence of this object type should be inquired with appl_getinfo (opcode 13). Note: G_POPUP looks like G_BUTTON but the character string is not centred, so as to line up with the other character strings in the menu if possible.
G_WINTITLE (36)	This object number is used internally by MagiC to depict window titles. The construction of this object type may change at any time and is therefore not documented.
G_EDIT (37)	As of MagiC 5.20 an editable object implemented in a shared library is available; ob_spec points to the object. Warning: This type is not yet supported by the functions form_do, form_xdo, form_button, form_keybd, objc_edit, wdlg_evnt and wdlg_do at present, i.e. the corresponding events need to be passed on to the object (with edit_evnt).
G_SHORTCUT (38)	This type is treated in a similar way to G_STRING, but any keyboard shortcut present is split off and output ranged right. The presence of this object type should be inquired for with appl_getinfo (opcode 13). The introduction of proportional AES fonts required new strategy for the alignment of menu entries. So as to align keyboard shortcuts ranged right, objects of the type G_STRING inside a menu are therefore split into commands and shortcuts. This strategy however fails for menus that are managed by the program itself, e.g. within a window or a popup menu. This new object type had to be introduced in order to achieve usable alignment in that case too.
G_SLIST (39)	XaAES extended object – scrolling list.

Note: For G_BOX, G_IBOX and G_BOXCHAR, the component ob_spec of the OBJECT structure does not point to another data structure, but contains further information for the appearance of the object. The following apply:

Bits	Meaning

24..31	Character to be depicted (only for G_BOXCHAR)
16..23	0 = Border width 1..128 = Border lies 1..128 pixels at the inside of the object -1..-127 = Border lies 1..127 pixel at the outside of the object
12..15	Border colour (0..15)
08..11	Text colour (0..15)
7	Text transparent (0) or opaque (1)
04..06	0 = Hollow 1 = Increasing intensity 2 . . 7 = Solid area
00..03	Inner colour (0..15)

The high byte is used by the AES only for submenus. If the highest bit of ob_type is 0x8000 and the bit SUBMENU in ob_flags is set, then the bits 8..14 specify which submenu is coupled with the menu entry. Hence each application can have a maximum of 128 submenus. MagiC only reads the low byte from ob_type, apart from the submenu handling. TOS reacts cleanly to unknown object types (such as the purely MagiC types G_SWBUTTON etc.), i.e. the objects are not drawn.

8.2.4.2 AES object colours

The following table contains the predefined object colours. Of course particulars depend on the selected screen resolution, as well as any settings made by the user.

Number	Colour	Standard RGB values
WHITE (00)	White	1000, 1000, 1000
BLACK (01)	Black	0, 0, 0
RED (02)	Red	1000, 0, 0
GREEN (03)	Green	0, 1000, 0
BLUE (04)	Blue	0, 0, 1000
CYAN (05)	Cyan	0, 1000, 1000
YELLOW (06)	Yellow	1000, 1000, 0
MAGENTA (07)	Magenta	1000, 0, 1000
DWHITE (08)	Light grey	752, 752, 752
DBLACK (09)	Dark grey	501, 501, 501
DRED (10)	Dark red	713, 0, 0
DGREEN (11)	Dark green	0, 713, 0
DBLUE (12)	Dark blue	0, 0, 713
DCYAN (13)	Dark cyan	0, 713, 713
DYELLOW (14)	Dark yellow	713, 713, 0
DMAGENTA (15)	Dark magenta	713, 0, 713

Note: These colours also correspond mostly to the icon colours used under Windows and OS/2. With a suitable CPX module one can set the correct RGB values for the frst 16 colours.

8.2.4.3 AES object flags

The manipulation flags of an object determine its properties. The following options can be chosen:

Flag	Meaning
NONE (0x0000)	No properties.
SELECTABLE (0x0001)	The object is selectable by clicking on it with the mouse.
DEFAULT (0x0002)	If the user presses the [Return] or [Enter] key, this object will be selected automatically and the dialog exited; the object will have a thicker outline. This flag is permitted only once in each tree.
EXIT (0x0004)	Clicking on such an object and releasing the mouse button while still over it will terminate the dialog (see also form_do).
EDITABLE (0x0008)	This object may be edited by the user by means of the keyboard.
RBUTTON (0x0010)	If several objects in an object tree have the property RBUTTON (radio button, similar to those on a push-button radio), then only one of these objects can be in a selected state at a time. These objects should all be children of a parent object with the object type G_IBOX. If another object of this group is selected, then the previously selected object will be deselected automatically.
LASTOB (0x0020)	This flag tells the AES that this is the last object within an object tree.
TOUCHEXIT (0x0040)	The dialog (see also form_do) will be exited as soon as the mouse pointer lies above this object and the left mouse button is pressed.
HIDETREE (0x0080)	The object and its children will no longer be noticed by objc_draw and objc_find as soon as this flag is set. Furthermore this flag is also evaluated as of MagiC 5.20 by form_keybd, if objects for keyboard shortcuts are searched for. Input to hidden objects is still possible, however. To prevent this, the EDITABLE flag has to be cleared.
INDIRECT (0x0100)	ob_spec now points to a further pointer that in turn points to the actual value of ob_spec (see also OBJECT). In this way the standard data structures such as TEDINFO etc. can be extended in a simple way.
FL3DIND (0x0200)	Under MultiTOS this object creates a three-dimensional object (under MagiC as of Version 3.0 only from 16-colour resolutions onwards and when the 3D effect has not been switched off). In 3D operation this will be interpreted as an indicator. As a rule, such objects are buttons that display a status, e.g. radio-buttons.
ESCCANCEL (0x0200)	Pressing the [Esc] key corresponds to the selection of the object with this flag. Therefore there may be only one default object in a dialog. Only effective in ViewMAX/2 and later.
FL3DBAK (0x0400)	In 3D operation this object will be treated as an AES background object, and drawn as such. It is recommended to allocate the ROOT object with this flag in dialogs with 3D buttons. The same applies for editable fields and text objects, as only in this way will a consistent background colour be maintained. See also (0x4000).
BITBUTTON (0x0400)	This flag was introduced with ViewMAX beta, but not used there. Presumably a button with this flag contains a bitmap in place of a text. Only effective in ViewMAX/2 and later.
FL3DACT (0x0600)	In 3D operation this object will be treated as an activator. As a rule such objects are buttons with which one can exit dialogs or trigger some action.
SUBMENU (0x0800)	This is used in MultiTOS and from MagiC 5.10 on to mark submenus. menu_attach sets this bit in a menu entry to signify that a submenu is attached to it. The high byte of ob_typethen contains the submenu index (128..255) i.e. bit 15 of ob_type is always set simultabeously with SUBMENU.
SCROLLER (0x0800)	Pressing the [PAGEUP] key corresponds to the selection of the first object with this flag in the dialog; pressing the [PAGEDOWN] key corresponds to the selection of the last object with this flag. Only effective in ViewMAX/2 and later.
FLAG3D (0x1000)	An object with this flag will be drawn with a 3D border. From ViewMAX/2 on every button will be drawn automatically with a 3D border. The colour category (see USECOLOURCAT) will be used for this. Only effective in ViewMAX/2 and later.
USECOLOURCAT (0x2000)	USECOLOURCAT (0x2000) The colour of the object is not a colour index of the VDI, but an entry in a table with colours for designated categories. This table has 16 entries. ViewMAX uses the following categories: CC_NAME (8) Inactive title-bar CC_SLIDER (8) Scroll bar background CC_DESKTOP (10) The desktop CC_BUTTON (11) Buttons and other 3D widgets CC_INFO (12) Window information-line CC_ALERT (13) Alert boxes (not used in ViewMAX or FreeGEM) CC_SLCTDNAME (14) Active title-bar Probably it is intended to let the categories 0 to 7 be defined by the application, while 8 to 15 are reserved for the system. The settings are stored in ViewMAX.INI (GEM.CFG in FreeGEM) and consist of one foreground, one background, a fill-style and a fill index in each case. Only effective in ViewMAX/2 and later.
FL3DBAK (0x4000)	3D background (sunken rather than raised). To check for this feature, use appl_init and check that bit 3 of xbuf.abilities is set.
SUBMENU (0x8000)	Not implemented in any known PC AES.

8.2.4.4 AES object stati

The object status determines how an object will be displayed later on the screen. An object status can be of the following type:

Status	Meaning
NORMAL (0x0000)	Normal representation.
SELECTED (0x0001)	Inverse representation, i.e. the object is selected (except for G_CICON, which will use its ‘selected’ image).
CROSSED (0x0002)	If the object type is BOX, the object will be drawn with a white diagonal cross over it (usually this state can be seen only over a selected or coloured object). See also below.
CHECKED (0x0004)	A checkmark tick will be displayed at the left edge of the object.
DISABLED (0x0008)	The object will be displayed greyed out and is no longer selectable.
OUTLINED (0x0010)	The object gets a border.
SHADOWED (0x0020)	A shadow is drawn under the object.
WHITEBAK (0x0040)	With PC-GEM this causes the icon mask not to be drawn with the icon, which can speed up output is some circumstances. As of MagiC 3 this controls the underscoring of character strings. This feature can be ascertained with appl_getinfo (opcode 13).
DRAW3D (0x0080)	An object is to be drawn with a 3D effect. This flag is of interest only for PC-GEM, and will be ignored by the Atari AES (and also in MagiC).
HIGHLIGHTED (0x0100)	An object with this status will be surrounded by a dashed line that is drawn with MD_XOR. This status was introduced with ViewMAX beta.
UNHIGHLIGHTED (0x0200)	An object with this status will be drawn with the surround explicitly set by the status HIGHLIGHTED removed. For this one has to proceed as follows: First the status HIGHLIGHTED must be cleared, then the status UNHIGHLIGHTED set and following this the object must be redrawn with the function objc_draw. A redraw of the object without the status UNHIGHLIGHTED would not remove the surround, as it lies outside the area that the object occupies. After the redraw the status UNHIGHLIGHTED should be cleared again. This status was introduced with ViewMAX beta.
UNDERLINE (0x0f00)	This opcode is available in MagiC from Version 2.0 onwards, and sets the position and size of the underscore for objects of the type G_STRING, G_TITLE and G_BUTTON.
XSTATE (0xf000)	This opcode is available in MagiC from Version 2.0 onwards, and serves for switching for the various button types (G_STRING, G_TITLE and G_BUTTON).

In GEM/5, CROSSED makes the object draw in 3D:

If an object is both CROSSED and SELECTABLE, then it is drawn as a checkbox.
If it is CROSSED, SELECTABLE and an RBUTTON, it is drawn as a radio button.
If it is a button or a box and it is CROSSED, then it is drawn as a raised 3D shape, similar to Motif.
If a button is CROSSED and DEFAULT, a “Return key” symbol appears on it (rather like NEXTSTEP).
Boxes and text fields that are CROSSED and CHECKED appear sunken.

GEM/5 can be detected by calling vqt_name for font 1. If nothing is returned, GEM/5 is running.

Recent FreeGEM builds contain a system based on the GEM/5 one, but extended and backwards-compatible. The DRAW3D state is used instead of CROSSED:

If an object is both DRAW3D and SELECTABLE, then it is drawn as a checkbox.
If it is DRAW3D, SELECTABLE and an RBUTTON, it is drawn as a radio button.
If a button is DRAW3D and DEFAULT, a “Return key” symbol will be on it.
If an object with a 3D border has the WHITEBAK state, then the 3D border will not have a black edge.
If a radio button or checkbox has the WHITEBAK state, then it will be drawn with a white background rather than in the colour used by 3D objects.

To check for these abilities, use appl_init and check that bit 3 of xbuf.abilities is set.

8.2.5 The quarter-screen buffer

The quarter-screen buffer is required by the screen-manager to save the contents of the menu background when drop-down menus drop down. The ‘QSB’ (the usual abbreviation) is also used for the display of alert boxes. Normally its size should depend on the number of colour planes and the size of the system font, but not on the total size of the screen.

A good formula would be:

500(characters) * space of one character * colour planes

In ‘ST High’ resolution this would give a value of exactly 8000 (i.e. a quarter of the screen memory). Unfortunately in many cases the AES is not so clever. The following table contains a summary of the algorithm used by some GEM versions:

GEM version	Method for setting the QSB
1.0 and 1.2	Static, 8000 bytes
1.4	Dynamic, a quarter of the screen memory
3.0	Dynamic, half of the screen memory

Note: The GEM versions 1.0 and 1.2 (i.e. up to and including TOS Version 1.02) are not prepared by this for colour graphics cards – one of several reasons why even with the use of a special VDI driver under these GEM versions one can not make use of colour graphics cards.

8.2.8.1 Redraw and updating of toolbars

For redraws of (parts of) the toolbar, one has to pay respect to the rectangle-list as usual. As the previous wind_get opcodes WF_FIRSTXYWH and WF_NEXTXYWH only respect the working area of a window, however, two new parameters (WF_FTOOLBAR and WF_NTOOLBAR) were introduced, with whose help the rectangle-list of a toolbar can be interrogated.

A redraw of (parts of) the toolbar may be necessary in the following situations:

The toolbar contains user-defined objects (USERDEF‘s).
The status of an object in the toolbar was altered. The area to be redrawn here consists of the size of the object plus the space required for special effects (3D, shadowing, outlining etc.).

Redraw is not necessary in the following cases, for instance:

The relevant window is iconified. The application does not have to take on any management of the toolbar; this is only required at the restoration of the iconification, the so-called uniconify.
The toolbar present in the window is to be replaced by another one. In this case a call of wind_set with the opcode WF_TOOLBAR and the address of the new OBJECT tree will suffice.
The toolbar present in the window is to be removed. In this case a call of wind_set with the opcode WF_TOOLBAR and NULL parameters will suffice.

8.2.8.2 Toolbars and the window-manager

For handling toolbars an application can have recourse to the window- manager of the AES. In detail:

For tacking on a toolbar to a window, it is sufficient to call wind_set(handle, WF_TOOLBAR, …) with the address of the toolbar object tree. If this call is executed while the window is open, then it is itself responsible for the correct calculation of the height of the toolbar.

To exchange a toolbar for another one, one can have recourse to a call of wind_set(handle, WF_TOOLBAR, …) with the address of the new toolbar. If this call is executed while the window is open, then it is itself responsible for the correct calculation of the height of the (new) toolbar.

To remove a toolbar from a window, it is necessary to call wind_set(handle, WF_TOOLBAR, …) with NULL parameters. If this call is executed while the window is open, then it is itself responsible for the correct calculation of the height of the toolbar.

In addition the following points have to be taken into consideration:

If a window is closed with wind_close, then any toolbar present will not be removed. At a later reopening the toolbar will be in place once more.
If a window is removed with wind_delete, then its link to a toolbar will be dissolved.
To be able to recognize mouse-clicks on toolbar objects, these have to possess the status TOUCHEXIT. When such an object is clicked on, the AES creates a WM_TOOLBAR message which is sent to the relevant application.

int16_t control[5]	With this field information about the called function and its parameters can be determined. The following apply: control[0] = Function number (opcode) control[1] = Number of elements in int_in array the function is being sent control[2] = Number of elements in int_out array the function is being sent control[3] = Number of elements in addr_in array the function returns control[4] = Number of elements in addr_out array the function returns There is no clear information about which elements must be set before an AES call. It is required in each case for elements [0],[1] and [3]. It seems less sensible for the elements [2] and [4] – after all the AES functions know how many values they return in the output fields.
int16_t global[15]	This field contains global data for the application and is used partly by appl_init and partly by other AES functions, and is filled automatically. The following apply: global[0] Version number of the AES global[1] Number of applications that can run concurrently; with a value of -1 there is no limit global[2] Unique ID number of the application global[3,4] Miscellaneous information that only has meanning for the application, and can be set and read by it global[5,6] Pointer to a list of pointers to the object trees of the application (is set by rsrc_load) global[7,8] Address of the memory reserved for the resource file. Only documented by Digital Research and not by Atari. global[9] Length of the reserved memory. Only documented by Digital Research and not by Atari. global[10] Number of colour planes. Only documented by Digital Research and not by Atari. global[11,12] Reserved global[13] Maximum height of a character, which is used by the AES for the vst_height call. This entry is only available as of AES Version 4.0, and also only documented by Atari. As of PC-GEM Version 2.0 this value is interpreted as a bit-vector with the drives registered with the desktop (bit 15 = Drive A:). global[14] Minimum height of a character, which is used by the AES for the vst_height call. This entry is only available as of AES Version 4.0, and also only documented by Atari. As of PC-GEM Version 2.0 this value is interpreted as a bit-vector that specifies which of the drives listed in global[13] can be regarded as hard drives.
int16_t int_in[16]	All 16-bit-sized input parameters are passed with this field.
int16_t int_out[10]	All 16-bit-sized return values are supplied by the AES via this field.
int32_t addr_in[8]	This field serves for the transmission of pointers (e.g. pointers to character strings) to the AES functions.
int32_t addr_out[2]	All 32-bit-sized return values are supplied by the AES via this field.

Write up on Tech geek history: Atari 1979 Operating System

Leave a Comment Cancel Reply