Write up on Tech Geek History Chapter 1 to 7 book form

Tech Geek History:
Explore the Scholarly Journals of Shaun Scott and explore the History of Computer Science and Groundbreaking Technology and Game Consoles that set a precedent in the World of Business and Entertainment today:
Chapter 1:
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 320200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640400 for viewability. This is the GEM desktop running on TOS displaying its desktop info screen. The actual resolution of the default display is 320200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640400 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 320200, obviously meant for viewing on a TV or composite monitor, but these screen shots have been enlarged to 640400 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:
• Accessories
• Bindings of the AES
• The desktop window
• Data exchange via the GEM clipboard
• Messages
• AES object structure
• Quarter-screen buffer
• Rectangle-list of a window
• Screen-manager
• Toolbar support
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.
See also: Style guidelines
8.2.1 Accessories
• Startup-code for accessories
• Accessories in MagiC
8.2.1.1 Startup-code for accessories
To test whether an application was launched as a program or as a desk accessory, one can proceed as follows:
• If the register a0 has the value zero at program startup, then we are dealing with a normal program launch.
• Otherwise we are dealing with a desk accessory, and register a0 contains a pointer to the (incompletely) filled BASEPAGE. The TPA has already been shrunk appropriately (to the sum of basepage size and the length of the three program segments), but a stack still has to be created.
Note: With this information there is no problem in creating the start- up code for a program in such a way that it recognizes automatically how the application was launched, and to continue the initialization appropriately. With most C compilers the external variable _app in the startup code is initialized automatically, which has the value 0 when the application was launched as a desk accessory. This makes it possible to develop applications so that they may be launched either as desk accessories or as normal programs.
See also:
About the AES Accessories in MagiC Program launch and TPA
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.
See also:
About the AES GEM Startup-code for accessories shel_write
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.
See also: About the AES wind_set WF_NEWDESK
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!
See also: Clipboard functions scrp_clear Style guidelines
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
+————-+
See also:
AES object colours Object types Manipulation flags Object status
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.
See also: Object structure in AES AES object colours
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.
See also: Object structure in AES AES object types
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.
See also: Object structure in AES AES object types
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.
See also: Object structure in AES AES object types
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.
See also: GEM
8.2.6 The rectangle-list of a window
To overcome the problem of windows that overlap each other, the AES holds for each window a so-called rectangle-list; when a window is partially obscured, GEM divides the visible portion of that window into the least possible number of non-overlapping rectangles, the details of which are then stored in the rectangle-list. Thus the elements of this list form a record of the currently completely visible working area of the corresponding window.
To redraw a window (or its contents) one first inquires with the function wind_get(WF_FIRSTXYWH) for the first rectangle of the abovementioned list. Then one checks whether this rectangle overlaps with the screen area to be redrawn; then and only then one can redraw this area with the use of vs_clip.
This method will be continued with all remaining elements of the rectangle-list, until the height and the width of a rectangle have the value zero.
See also: Clipping WM_REDRAW wind_get wind_update
8.2.7 The screen-manager
The screen-manager is always active and supervises the position of the mouse pointer when this leaves the working area of the window of other applications. The areas in question are the frames of the windows, the drop-down menus and the menu bar.
When touching the menu area, the screen-manager automatically ensures that the section of the screen occupied by the menu is saved and later restored again (the quarter-screen buffer is used for this).
Manipulation of the window controllers also do not lead to permanent changes of the screen memory; the result of the interaction with the screen-manager are the so-called message events, which inform the relevant application about the user’s actions.
Note: The ID of the screen-manager can, incidentally, be found easily by a call of appl_find(“SCRENMGR”).
See also: About the AES GEM Messages
8.2.8 Toolbar support
From AES version 4.1 onwards the operating system supports so-called toolbars. A toolbar is an OBJECT tree that is positioned below the information-line of a window (and above the working area) which makes it possible to display buttons, icons etc. in a window.
As already known from the window routines, the management of toolbars is shared betwen the AES and the application. Here the AES is responsible for the following actions:
• Adaptation of the X- and Y-coordinates of the toolbar when the window is moved or its size is changed.
• Ensuring that the window is configured to the size required by the window components and the toolbar.
• Adjustment of the toolbar’s width to the width of the window.
• Redraw of the toolbar on receipt of a WM_REDRAW message.
• Sending of AES messages when the user activates an object of the toolbar.
The application, on the other hand, must look after the following:
• Construction of an OBJECT tree for the toolbar (in particulat one has to ensure that all selectable elements of the toolbox have the status TOUCHEXIT).
• Adjustment of the width of a toolbar object if this depends on the width of the window (may be required when changing the size of the window).
• Handling of USERDEF objects.
• Redrawing all objects whose appearance is to be changed. In this case it is imperative that the rectangle-list of the toolbar is inquired for and/or taken into account.
• Problems that arise in connection with the screen resolution have to be solved. Thus, for instance, the height of an icon in the ST Medium resolution can differ from the height of the icon in the TT030 Medium resolution.
For supporting toolbars in your own programs, you should respect the following points:
• Communication with the AES window-manager
• Problems with wind_calc
• Redraw and updating of toolbars
• Toolbar support under XaAES
See also:
WF_TOOLBAR WF_FTOOLBAR WF_NTOOLBAR WM_TOOLBAR wind_get wind_set
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.
See also: Rectangle-list of a window Toolbar support
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.
See also: AES GEM Toolbar support
8.2.8.3 Problems with wind_calc in toolbar windows
When applying the function wind_calc to windows that possess a toolbar there are several problems to be taken into account:
As this function is not passed a window ID (window handle), the desired sizes cannot be calculated correctly when a toolbar is present in the window. The reason for this is that, quite simply, the AES in this case has no information about the toolbar, and specially about its size.
Hence the values returned by wind_calc in such cases have to be further refined by the application. As the program can access the relevant OBJECT tree (and with this also the height of the toolbar), this should present no problems. In detail:
• When ascertaining the border areas of the window, the height of the toolbar must be added to the height returned by the function.
• When ascertaining the working area of the window, the height of the toolbar must be added to the Y-value (couty) returned by the function.
Note: Besides the height of the actual object, the height of the toolbar should include also the space requirement for special effects (3D, shadowing, etc.).
See also: WF_FTOOLBAR WF_NTOOLBAR WM_TOOLBAR objc_sysvar
8.2.9 AES bindings
The AES is called via a single subprogram that is passed 6 parameters; these are addresses of various arrays that are used for input/output communications. To call an AES function, the following parameter block must be populated with the addresses of the arrays described below:
typedef struct
{
int16_t cb_pcontrol; / Pointer to control array */
int16_t *cb_pglobal; /* Pointer to global array */
int16_t *cb_pintin; /* Pointer to int_in array */
int16_t *cb_pintout; /* Pointer to int_out array */
int16_t *cb_padrin; /* Pointer to adr_in array */
int16_t *cb_padrout; /* Pointer to adr_out array */
} AESPB;
The address of this parameter block (which lies on the stack) must be entered in register d1, and subsequently register d0.w must be filled with the magic value 0xc8 (200). With a TRAP #2 system call the AES can then be called directly. For the Pure-Assembler this could look like this, for instance:
.EXPORT aes ; Export function
.CODE ; Start of the code-segment
aes: MOVE.L 4(sp),d1 ; Address of the parameter blocks
MOVE.W #200,d0 ; Opcode of the AES
TRAP #2 ; Call GEM
RTS ; And exit
.END ; End of the module
There is no clear information available about which registers may be altered. In fact, however, the corresponding routines in ROM save all registers.
Now to the individual arrays. With each field, designated input or output functions can be performed. The following apply:
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.
Warning: If the operating system supports threads, then it is impera tive that a multithread-safe library is used. In particular one must ensure that each thread receives its own global field (see above).
See also: Sample binding VDI bindings TOS list
8.2.9.1 Sample binding for AES functions
The function ‘crys_if’ (crystal interface) looks after the proper filling of the control arrays, and performs the actual AES call. It is passed one WORD parameter in d0 containing the funtion’s opcode minus 10 multiplied by 4 (for faster table indexing); this gives an index into a table in which the values for control[1], control[2] and control[3] are entered for each individual AES function.
AESPB c;
int16_t crys_if (int16_t opcode)
{
int16_t i, *paesb;
control[0] = opcode;
paespb = &ctrl_cnts[ (opcode-10)*3 ];
for (i = 1; i < 4; i++)
control[i] = *paespb++;
aes (c);
return (int_out[0]);
} /* crys_if */
The table used for this could be built up as follows, for instance:
.GLOBAL ctrl_cnts
.DATA
ctrl_cnts: .dc.b 0, 1, 0 ; appl_init
.dc.b 2, 1, 1 ; appl_read
.dc.b 2, 1, 1 ; appl_write
…
…
…
.END
A fuller version is given in The Atari Compendium pp. 6.39-41. Note that the rsrc_gaddr call must be special cased in a library if you want to use the crys_if binding to call the AES.
See also: AES bindings GEM

Chapter 2

Write up on Tech Geek HISTORY: CP/M (Control Program for Microcomputers)
Introduction
CP/M was a text-based operating system created by American programmer Gary Kindal of Digital Research14. Its initials stood for “Control Program/Monitor” at first, but Digital Research changed it to the more friendly “Control Program for Microcomputers” later.
As the price of microcomputers dropped rapidly in the mid-late 1970s, CP/M, paired with the Z80 CPU became a de-facto standard platform that was popular among small business computers in the late 1970s and early 1980s.
The CP/M family of operating systems is available for both 8- and 16-bit machines and achieved a tremendous degree of success in the years before it was supplanted by the MS-DOS family from Microsoft, which includes the IBM PC-DOS.
Content of the Problem
However, the recent variants, such as Concurrent DOS 386, offer a viable alternative in many situations. However, MS-DOS seems likely to continue to be the dominant single-user operating system, until around 1990 when OS/2 will take over. OS/2 offers multitasking and more sophisticated networking and graphics support. CP/M and Derivatives The first real operating system for microcomputers was CP/M (Control Program for Microcomputers), which was for a long time the dominant operating system with over two million legitimate installations and probably nearer three million including pirates. It is of decreasing importance to PC support staff, as most machines which use it are now being retired, and it is mainly of historical interest, and included in the notes for reference. CP/M was originally written as a spare time project by Gary Kildall as a replacement for paper tape loading of engineering development system software. When Intel Corporation declined to use the system, Kildall licensed the system to Lawrence Livermore Labs, who used it to control nodes in an early network system. It was then picked up by IMSAI, manufacturers of the second microcomputer, and sold as IMDOS, then Cromemco used it.
In 1982, Microsoft Chairman Bill Gates claimed that SoftCard customers represented the largest single install base for CP/M machines. Interestingly, around that same time, a new operating system based on CP/M—Microsoft’s MS-DOS—was rapidly gaining market share.
MS-DOS Borrowed a Lot from CP/M
When IBM began developing its Personal Computer (the IBM PC 5150), the firm first tried to secure a license to CP/M, but Digital Research didn’t like the proposed terms of the deal. So IBM turned to Microsoft, which licensed a product called 86-DOS from Seattle Computer Products (SCP). Some months later, Microsoft purchased 86-DOS outright for $50,000.

Significance of the Study
CP/M is a monitor control Program providing a disc and file handling operating system to stand alone microcomputers. It controls the computer input and output functions. It organizes the files held on disc and reports on the data storage. Finally, it enables you to load and execute programs from disc. CP/M was designed in 1976 for use on a floppy disc-based microcomputer using an 8080 microprocessor. It will only run the 8080,8085 and Z80 microprocessors, it was once the most popular operating systems in the world.
The system was under the control of a monitor holding firmware.
480Z the monitor is called ROS, the Resident Operating System; in the 380Z-D the monitor is called COS, the Central Operating System. CP/M was used to control disc operations on the two different Research Machines Systems. CP/M communicated with either ROS or COS.
The term BIOS was created by:
The Basic Input/Output System the heart of the CP/M, basic disc file operation was to read & write files allocating and reallocating disc space.
The Language was based on Machine Code “Assembly Language.”
CP/M Family CP/M was, however, completed by MAA in 1974.
A file was a single set of data (or information) records that a user gathered and stored on any permanent storage medium. All the work that one did on the microcomputer system was based on disc files.
It included a single- user file system designed to eliminate data IQSS in all but the most unlikely situations, and used recoverable directory information to determine storage allocation rather than a traditional linked-list organization. The simplicity and reliability of the file system was an important kgr-to the success of CP/M: file access to relatively slow floppy disks was im- mediate, and disks could be channeled without losing files or mixing data records. And because CP/M is a Spartan system, today’s increased storage-media transfer rates simply improve overall response.
CP/M was split into five distinct areas, only one of which is machine dependent. The BIOS is the Basic Input Output System, which contains all hardware dependent code to interface with the floppy disk controller, console, etc. The BDOS is the Basic Disk Operating System, which contains the file management system kernel, and is machine independent. The CCP is the Console Command Processor, which is loaded at warm starts to interpret the command line typed by the user at the console. The CCP can be overlaid by application programs. The TPA (Transient Program Area) is where programs are loaded and executed. Transient programs can overlay the CCP, since its functions are not needed by running programs, and they can also overlay the BDOS, provided they do not require its file system services. The Base Page area contains interrupt vectors, certain key variables and vectors to the BDOS and BIOS. Notice that CP/M itself resides at the top end of memory and extends downwards.
CP/M Plus (CP/M 3.0) CP/M Plus brings the bank selection and file system features of MP/M II (see below) to the single-user environment. This version of CP/M is able to manage additional banks of memory in “which it can store the disk directory and track buffers to achieve significantly faster disk accesses (tests indicate up to seven times improvement in accessing indexed files). CP/M Plus also supports a real time clock, permitting data and time stamping of files, as well as password protection, although this consumes disk directory entries. CP/M Plus supports customizable extensions to the operating system called Resident System Extensions (RSX). This allows additional functions to be added to the operating system and called from user programs in the same way as regular system calls. An example of an RSX is the GSX (Graphics System Extension) ANSI standard graphics driver.
CP/M and Derivatives The RMAC macro assembler and SID debugger are supplied as standard with CP/M Plus, since it is customized in a different way. CP/M Plus is rather more user-friendly than 2.2, in that the user no longer needs to type control-C when changing disks, and the system also provides input-output redirection, though in a less sophisticated manner than UNIX.
By the mid-1970s CP/M added a new philosophy to operating system design. CP/M had been implemented on several computer systems, each having a different hardware ‘interface. To accommodate these va & hard- ware environments, CP/M was de- composed into two parts: the .in- variant disk operating system written in PL/M, and a small variant portion written in assembly language.
This separation allowed computer suppliers and end users to adapt their own physical 110 drive to the standard CP/M product. Hard disk technology added yet another factor. CP/M customers re- quired support for disk drives ranging from single 5-inch floppy disks to high-capacity Winchester disk drives. In response, CP/M was totally ~designed in 1979 to become table- driven. All disk dependent parameters were moved from the invariant disk operating system to tables in the variant portion, to be filled in by the system implementer. CP/M is now a multifunction program whose exact operation is defined externally through tables and I/O subroutines. The widespread use of CP/M is directly attributed to this generality: CP/M becomes a special- purpose operating system when it is field-programmed to match an operating environment. Through the efforts of system implementers who provide this field-programming, CP/M was used worldwide in close to 200,000 installations with over 3000 different hardware configurations.
MP/M As single-user CP/M became widely accepted, Digital Research began to develop a new operating system for real-time processing. The design called for a real-time nucleus to support cooperating sequential processes, including a CP/M-compatible file manager with terminal-handling capabilities.
This operating system, called MP/M (Multiprogramming Monitor for Microcomputers), is a further refinement of the process model found in Intel’s RMX and National’s Starplex. As a side effect, the combination of MP/M’s real-time nucleus with the terminal handler and the CP/M file system produces a traditional timesharing system with multiprogramming and multiterminal features.
Timesharing allows programs to execute in increments of processor: time in a “lock-step” fashion. In a timesharing context, a printer pro- gram, often called a spooler, might have the task of printing a series of disk files which result from program output. The spooler starts with a disk-file name and, by using increments of processor time allocated by the real-time nucleus, writes each line from the file to the printer. Upon completion, the spooler obtains another disk-file name and repeats :he process. A disk file to the spooler and, while the file was being printed, the function edited another file in preparation for compilation. The spooler and editor share processor time to complete their respective tasks.
In general, many such processes share processor time and system resources. MP7M process communication is performed through queues (or waiting lines) managed by the nucleus. The spooler, for example, reads file names from an input queue posted by another process (which reads spooler command lines from the console). When the spooler is busy printing a file, additional file names may enter the input queue in a first-in first-out order. Process synchronization through queuing mechanisms is common- place, but MP/M treats queues in a unique manner, simplifying their use and decreasing queue management overhead. Queues are treated as files: they are named symbolically so that a queue can be added dynamically. Like files, queues have queue control blocks that are created, opened, deleted, written, and read. In fact, the set of queue operations closely
A matches the file functions of CP/M so that MP/M provides a familiar programming environment. The implementation of queues is transparent to an operator or system programmer, but it is important to MP/M’s effective operation on limit- ed-resource computers. Queues are implemented through three different data structures, depending upon the message length. So-called “counting semaphores” count the occurrence of an event with message length zero, and are implemented as 16-bit tallies. Single-byte messages are processed using a circular buffer. Similarly, queues containing addresses are processed using circular buffers. In all other cases, Mf /M uses a general linked list, which requires additional space and processing time. It is this sensitivity to the capabilities of limited -resource computers that makes MP/M effective: while real- time operating systems often incur 25 to 40% overhead, MP/M has been streamlined to increase available compute time by 7% over single-user CP/M. Like CP/M, MP/M is separated in- to variant and invariant portions. The file-system interface is identical to that of CP/M, with the addition of user defined functions to handle non- CP/M operations (such as control of the real-time clock). Field-reconfiguration of MP/M allows a variety of device protocols including CP/M- style busy-wait loops, polled devices, and intempt-driven peripherals. In fact, the variety of interface possibilities makes the MP/M implementer a true system-software designer, since a fine-tuned MP/M system may operate considerably faster than its initial implementation. What are. the refinements found in MP/M? First, it is a state-of-the-art operating system based on current process-synchronization technology and microprocessor real-time system design philosophies. Process communication is conceptually simple and requires minimal overhead. Finally, it is the only operating system of its type that can be field- tailored to match almost any computer configuration.

Chapter 3
Write up on Tech geek history: Kermit(File Transfer Protocol)
Introduction
Kermit is the name of a file-transfer protocol and a suite of computer programs for many types of computers that implement that protocol as well as other communication functions ranging from terminal emulation to automation of communications tasks through a high-level cross-platform scripting language.
The software is transport-independent, operating over TCP/IP connections in traditional clear-text mode or secured by SSH, SSL/TLS, or Kerberos, as well as over serial-port connections, modems, and other communication methods.
Literature Review
History
At the height of the timesharing era at Columbia University, about 1980, our central computers began to suffer from a glut of files. Disk storage space was running out, and increasing numbers of students wanted to keep the computer files they accumulated over their academic careers. The problem could not be solved simply by buying more disks because, as somebody’s law states, ‘‘Usage will expand to consume all available resources2.’’ A more decentralized approach was called for. Given the means, those who cared about saving their files from term to term would take the trouble to do it themselves. The newly popular floppy-disk-based microcomputers fit the bill nicely. The diskettes were cheap, capacious, and easily carried and stored. But how could files be transferred reliably from the university’s central computers to the microcomputer floppies, and back? The problem took on a new dimension with the introduction of the IBM PC in 1981, which struck a powerful blow to centralized computing. As the new generation of personal computers began to rival the large central computers in several key application areas, PCs (not only IBM) began to appear in offices all over campus, and soon spread to the homes and dormitory rooms of faculty and students. The users of these PCs needed to communicate and share their work — professors and students, This is a corollary to Parkinson’s Law, which says that ‘‘Work expands so as to fill the time available for its completion.
The Kermit File Transfer Protocol researchers or authors in collaboration, administrators up and down the ‘‘chain of command.’’ Communication was required between PCs and the central systems, between PCs and other (possibly incompatible) PCs, and between our central systems and minicomputers in the academic departments. In short, everything had to ‘‘talk’’ to everything else. But how? Computer networks were not a practical alternative in 1981, and today they remain a costly one, even when you can find a network that provides the required connections. The only medium that all our computers had in common was the ‘‘communication port,’’ the place where a terminal or a ‘‘modem’’ is attached. The operation of the communication port is relatively well defined and standardized, but it is not an ideal medium for bulk transfers of data (for reasons that will be covered later). On the other hand, it is usually standard equipment; with appropriate software it can do the job for little or no additional hardware expense. Several communication software packages were on the market in 1980-81, but they were not available for all our systems. Even if they had been, the total cost would have been enormous when multiplied by the number of microcomputers, minicomputers, and mainframes we expected to arrive in the ensuing years. And even if the cost were bearable, it would not have been wise to depend upon a single commercial vendor for such an important function — the company could fail, or raise its prices suddenly, or decline to add support for some new system. Had we been aware of public domain communication protocols and programs, particularly MODEM3 and its derivatives, we might have been tempted to adapt them to our needs. But it turns out that MODEM would not have fulfilled one of our most basic requirements: IBM mainframe communication. Finally, for better or worse, we took the do-it-yourself approach. We invented a new protocol and called it Kermit, after Kermit the Frog, star of THE MUPPET SHOW .
As luck would have it, the few types of systems that our protocol initially had to support — DECSYSTEM-20 and IBM 370-Series mainframes, CP/M and MS-DOS microcomputers — exhibit among them nearly every imaginable quirk and idiosyncrasy of communication style and file organization, and our protocol was designed to encompass all of them. The result has turned out to be adaptable to almost every new situation; its flexibility accounts in large measure for its popularity. It must be said, however, that had we known Kermit would eventually spread all over the globe (and 3MODEM is more properly referred to as the Christensen protocol; MODEM, XMODEM, and so on, are names of programs that implement this protocol. The Kermit and Christensen protocols are compared in detail on page 314. 4Why? Mostly because there was a Muppets calendar on the wall when we were trying to think of a name, and Kermit is a pleasant, unassuming sort of character. But since we weren’t sure whether it was OK to name our protocol after this popular television and movie star, we pretended that KERMIT was an acronym; unfortunately, we could never find a good set of words to go with the letters, as readers of some of our early source code can attest. Later, Bill Catchings noticed while looking through a name book for his forthcoming baby that Kermit was a Celtic word for free, which is what all Kermit programs should be, and words to this effect replaced the strained acronyms in our source code (Bill’s baby turned out to be a girl, so he had to name her Becky
Kermit is one example of why it’s good to share software of general utility (two others are EMACS [28] and TEX [20]). If we had elected to keep it to ourselves, or to license and sell it, or to keep the source code or protocol specification secret, it would never have reached its current level of popularity. It would never have been written for so many different computers. It would not have improved and evolved through the continuous contribution of bug fixes and new versions, complaints and suggestions. It would never have threatened to become a ‘‘de facto standard.’’ If the spirit of the ’80s is ‘‘Don’t give away anything you can sell,’’ then Kermit must be a child of the ’60s. Contrary to what you might expect from the foregoing polemic, Kermit programs are not necessarily in the public domain. On the contrary, many of them bear copyright notices to protect their authors or sponsoring institutions against having their work turned into commercial products. However, these copyright notices generally grant permission to any individual or organization to use, copy, modify, or redistribute the program, source code, or documentation as long as this is not done for profit, and the copyright notice and author credits are retained. Commercial hardware and software vendors are allowed to add Kermit protocol to their products provided they do not charge their customers extra for it (at least not beyond the incremental cost of reproduction and distribution), and they agree to certain other easy terms. Kermit distribution began at Columbia in 1981. Our original policy was ‘‘send us a tape and a return mailer and we’ll send you the Kermit distribution.’’ Since we were not able to make floppy disks in a wide variety of formats, we preferred to send tapes to institutional computing centers, which could take the responsibility for ‘‘bootstrapping’’ the desired microcomputer implementations to floppy disk and distributing them in appropriate formats to their users. By early 1983 the demand for Kermit tapes had grown far beyond our capacity to produce them and still do our ‘‘real jobs.’’ To get our system programmers out of the shipping room, we began to charge a distribution fee. This fee is not a software license fee. It allows us to keep up with demand by hiring production workers, and it compensates us for media, packaging, postage, computer utilization, and printing. It does not reflect the amount of software on the tape, the quality of the software, nor the amount of effort that went into producing the software — only the ‘‘parts and labor’’ required for reproduction and shipping.
The Kermit File Transfer Protocol For the benefit of those who have trouble with the fee, every effort is made to funnel Kermit programs into alternative distribution channels. Kermit programs are submitted regularly to user group libraries, and they are available on many computer networks and dialup bulletin board systems. All who have received Kermit programs from Columbia or elsewhere are encouraged to share them with their friends and neighbors. Kermit has been an encouraging example of international cooperation on a personal and institutional level.
Kermit runs happily in both Irelands, both Chinas, both Germanys. It can be found in the USA and the USSR, in Israel and Iraq; in New Zealand and New Caledonia, Chile and Czechoslovakia; in Malaysia and Mexico, Sweden and Switzerland, Norway and the Netherlands, and practically anywhere else you can think of. If a country has computers, many of them are probably running Kermit programs — people’s basic needs are pretty much the same everywhere, and people who use computers have begun to view the ability to transmit computer data as a basic need, even a right. Kermit fosters the free exchange of information and ideas, and it works against the trend towards information as commodity (or controlled substance). Our attitudes about sharing spring from a spirit of respect for fellow humans and other creatures. I trust and urge that Kermit be used only for peaceful and humane purposes. It was not created and shared to further causes of nationalism, war, oppression, or discrimination. Please use it in the spirit in which it is offered. Kermit Versus Networks You have probably read about computer networks. Networks are based upon dedicated physical connections between computers; they are the best way to put computers into communication with each other. They’re reliable, they’re fast, they support a variety of functions, and they’re easy to use. They overcome all the same problems that Kermit must cope with, and they do it better. So why bother with Kermit? If you have a network, and it includes all the computers you care about, then you don’t have to bother with Kermit. But networks are expensive, hard to install, and often designed to work only with a particular vendor’s equipment. Many microcomputers have no network option available; even when there is one, the expense can be prohibitive. And when the expense is tolerable, the logistics get in the way — cables must be laid, holes drilled, satellites launched. So chances are that your microcomputer is not on a network, or if it is, that some day you will need it to communicate with some other computer that is not on your network. Network connections must be installed by ‘‘management.’’ They require special ‘‘interface hardware,’’ operating system software, and so forth. Kermit programs, on the other hand, run (with very few exceptions) in the computer’s ‘‘user mode,’’ with no special privileges or changes to the system software required. Once you have a copy of Kermit on your computer, you can establish your own connection to any other computer that you can dial on the telephone or reach with a cable. Unlike proprietary Introduction networks, Kermit always comes with source code and documentation, so even if there is no Kermit program for your computer, a programmer can create one in a short time based on the Kermit programs that have already been written or the examples in this book. Networks are becoming increasingly widespread and interconnected, but they will never encompass every computer in the world. Communication programs like Kermit will always be needed to make the connections that aren’t already there: from home to work, from business trip to home base, from space to earth
Over the years, the Kermit Project grew into a worldwide cooperative nonprofit software development and distribution effort, headquartered at and coordinated from Columbia University. The Kermit Project is dedicated to production of cross-platform, long-lasting, standards-conformant, interoperable communications software, and is actively engaged in the standards process. Kermit software is used all over the world in every sector of the economy.
Although terminal emulation has been largely supplanted by the Web for online access, Kermit software continues to play a role in other applications such as remote sensing and data collection, remote management and troubleshooting of networking and telecommunications equipment, cargo management, medical insurance claim submission, electronic funds transfer, and online filing of income tax returns. Kermit software is embedded in cash registers, network routers, cell-phone towers, medical diagnostic and monitoring equipment, die-cutting and stamping presses, even cardiac pacemakers.
The Kermit protocol and software are named after Kermit the Frog, star of the television series, The Muppet Show; the name Kermit is used by permission of Henson Associates, Inc.
Significance of the Study
ATARI KERMITS
The eight-bit Atari version of Kermit, by John Palevich, was written in ACTION! and then compiled. (You don’t need the ACTION! cartridge to use the program.) This Kermit is available through the Antic Arcade Catalog. Kermit is also a part of Palevich’s Chameleon Terminal Emulator. Also available through the Antic Arcade Catalog ($19.95, AP113).
A 520ST version of Kermit came with our ST development package. Its one-letter command format is very similar to UNIX Kermit.
We got both Kermits running in matching configuration on both our ST and an Atari 800 (it could have been any other 8-bit Atari). Then we ported Listing 1 over to the ST. The listing is a simple Atari Logo program that draws a star against a randomly selected background color.
HARDWARE
We used a printer cable, a null modem connector, a gender changer (female-female) and a modem cable (RS-232 to D9) to attach our ST to Port R1 of an 850 interface. See Figure 1.
SOFTWARE
We booted Kermit on the 800 and set the following parameters:
A – Back S sends (Cursor left (ASCII))
B – Baud.Rate (9600)
C – Carriage return includes line feed is (off)
D – Default disk drive (D1:)
F – File type (text)
I – I/O Port (1)
T – Dialing method (tone)
L – Local Echo (off)
P – Parity (none)
Meanwhile, we loaded the ST Kermit program from GEMDOS and typed KERMIT R which put the ST into the Kermit Receive mode.
Back at the 800, we typed S [RETURN], entered the filename of our logo program and pressed [RETURN] again to begin the transfer.
An instant later, the transfer was over. At 9600 baud, our logo file and its filename, had been “Kermited” from the 800 to our ST and automatically written to the ST’s disk. At 9600 baud, Kermit ports files very rapidly. In fact, you’d have to type for more than four hours at 40 words per minute to match the amount of information ported during a 60-second file transfer.
OPERATIONS
Most Kermits support three commands: Send, Receive and Serve. Kermit Send and Kermit Receive are used when there is a human operator present at each computer. One operator will Send while the other Receives. Most Kermits also support wildcards in filenames. For example, to port all files with a .TXT extender, you’d type *.TXT as the filename to transfer.
The Kermit Server puts one computer on “remote control,” allowing both computers to be controlled by a single operator.
Type KERMIT V to place the St into the Kermit Server mode. While in this mode, the ST will automatically receive any files (and filenames) sent to it, and save each file to disk.
MODIFYING FILES
Our sample Logo file needed only one modification before it could run on the ST. The ST Logo didn’t permit multiple drawing pens. We removed the pen number from the second line of the STAR procedure, changing that line from SETPC 1 :COLR into SETPC :COLR and the program ran correctly.
Since then, we’ve Kermited many more Logo files, LISTed BASIC programs and numerous text files to and from the Antic 52OST.
Listing 1
TO STAR :LN :COLR
SETPC 1 :COLR
REPEAT 36 [RT 170 FD :LN]
END
TO MAIN :COLR
HOME
SETBG RANDOM 16
CLEAN
FS HT PU FD 90 PD
MAKE “LN :COLR
STAR :LN :COLR
MAKE “COLR :COLR + 1
IF :COLR = 16 [MAKE “COLR 1]
MAIN :COLR
END

Chapter 3

1. Background
   The Kermit file transfer protocol is intended for use in an environment where there may be a diverse mixture of computers — micros, personal computers, workstations, laboratory computers, timesharing systems — from a variety of manufacturers. All these systems need have in common is the ability to communicate in ASCII over ordinary serial telecommunication lines. Kermit was originally designed at Columbia University to meet the need for file transfer between our DECSYSTEM-20 and IBM 370-series mainframes and various microcomputers. It turned out that the diverse characteristics of these three kinds of systems resulted in a design that was general enough to fit almost any system. The IBM mainframe, in particular, strains most common assumptions about how computers communicate.
2. Overview
   The Kermit protocol is specifically designed for character-oriented transmission over serial telecommunication lines. The design allows for the restrictions and peculiarities of the medium and the requirements of diverse operating environments — buffering, duplex, parity, character set, file organization, etc. The protocol is carried out by Kermit programs on each end of the serial connection sending “packets” back and forth; the sender sends file names, file contents, and control information; the receiver acknowledges (positively or negatively) each packet. The packets have a layered design, more or less in keeping with the ANSI and ISO philosophies, with the outermost fields used by the data link layer to verify data integrity, the next by the session layer to verify continuity, and the data itself at the application level. Connections between systems are established by the ordinary user. In a typical case, the user runs Kermit on a microcomputer, enters terminal emulation, connects to a remote host computer (perhaps by dialing up), logs in, runs Kermit on the remote host, and then issues commands to that Kermit to start a file transfer, “escapes” back to the micro, and issues commands to that Kermit to start its side of the file transfer. Files may be transferred singly or in groups. Basic Kermit provides only file transfer, and that is provided for sequential files only, though the protocol attempts to allow for various types of sequential files. Microcomputer implementations of Kermit are also expected to provide terminal emulation, to facilitate the initial connection. More advanced implementations simplify the “user interface” somewhat by allowing the Kermit on the remote host to run as a “server”, which can transfer files in either direction upon command from the local “user” Kermit. The server can also provide additional functionality, such as file management, messages, mail, and so forth. Other optional features also exist, including a variety of block check types, a mechanism for passing 8-bit data through a 7-bit communication link, a way to compressing a repeated sequence of characters, and so forth. As local area networks become more popular, inexpensive, and standardized, the demand for Kermit and similar protocols may dwindle, but will never wither away entirely. Unlike hardwired networks, Kermit gives the ordinary user the power to establish reliable error-free connections between any two computers; this may always be necessary for one-shot or long-haul connections
   Kermit is a public domain telecommunications program that lets different types of computers and operating systems swap text files with each other. Thus, software developers may write their applications on one machine and transfer the completed source code to another. Because GEM offers compatibility between different co-processors, there are many companies developing software on the IBM PC who will use Kermit to transfer their C language source code files to the Atari ST.
   MUPPET SOFTWARE
   Named aftcr Kermit the frog, this file transfer protocol monitors the flow of information between computers. Kermit can best be compared to XMODEM protocol. Files transferred through either of these protocols are broken into pieces, or “packets,” and sent individually. A checksum, similar to a TYPO II code, accompanies each packet.
   Each time the computer receives a packet, it recomputes the checksum, and compares it against the sending computer’s original. If the two checksums match, Kermit assumes the packet was received correctly.
   If the checksums don’t match, Kermit will send the packet again and again, until a rnatch is achieved. Kermit continues sending and checking packets until an entire file is successfully transferred.
   Kermit was developed by Bill Catchings and Frank da Cruz at Columbia University in 1981. The first Kermit implementation linked a DEC-20 mainframe to a CP/M-80 microcomputer. Today, more than fifty types of mainframe and micro-computers have Kermit programs

Chapter 4
Write up on Tech Geek History: Motorola 6800
Introduction
Background of the Study
The Motorola 6800, introduced in 1974, is one of the pioneering microprocessors that played a pivotal role in the evolution of computing. As one of the first microprocessors to gain significant market traction, the 6800 influenced numerous applications in both consumer electronics and industrial automation. This article explores the historical context, architectural design, key features, applications, and lasting legacy of the Motorola 6800.
The early 1970s marked a turning point in the field of computing. Microprocessors were emerging as a revolutionary technology, enabling the development of smaller, more affordable computers. Before the introduction of the 6800, many computers relied on discrete transistor technology, which was costly and cumbersome. Motorola recognized the potential for a compact, efficient microprocessor that could power the next generation of computing devices.
Significance of the Study
Development
The 6800 was developed by a team at Motorola led by Dr. Robert Noyce, a co-founder of Intel and a pioneer in semiconductor technology. The design aimed to create a microprocessor that could compete with existing offerings, such as Intel’s 8080 and the Zilog Z80. Motorola focused on creating a processor that was not only powerful but also cost-effective and user-friendly.
The result was a microprocessor with an elegant architecture, low power consumption, and a comprehensive instruction set. It was packaged in a 40-pin dual in-line package (DIP), allowing for easy integration into various devices.
Market Impact
The 6800 quickly gained popularity in various industries, becoming the foundation for several early personal computers and embedded systems. Companies like Apple, Atari, and Commodore adopted the 6800 for their products, marking a significant moment in the history of computing. The processor’s affordability and performance enabled hobbyists and small manufacturers to develop innovative computing solutions, setting the stage for the personal computing revolution.
Architecture of the Motorola 6800
The architecture of the 6800 is characterized by its simplicity, efficiency, and versatility. Below, we delve into its key components, features, and capabilities.
Registers
The 6800 microprocessor features a set of registers that are essential for its operation. These include:

1. Accumulator (A): The primary register used for arithmetic and logical operations. The accumulator holds the data being processed by the microprocessor.
2. Index Registers (X and Y): These registers are used for indexed addressing modes, allowing for efficient data manipulation and array handling.
3. Stack Pointer (SP): The stack pointer points to the current top of the stack in memory, enabling the microprocessor to manage subroutine calls and interrupts.
4. Program Counter (PC): The program counter holds the address of the next instruction to be executed, allowing for sequential execution of instructions.
5. Condition Code Register (CCR): This register contains flags that reflect the status of the processor, including zero, carry, overflow, and negative flags.
   Instruction Set
   The Motorola 6800 boasts a rich instruction set comprising 56 instructions. These instructions can be categorized into several groups:
6. Data Movement: Instructions that move data between registers and memory. Examples include LDA (Load Accumulator) and STA (Store Accumulator).
7. Arithmetic Operations: Instructions that perform basic arithmetic operations, such as ADC (Add with Carry) and SBC (Subtract with Carry).
8. Logic Operations: Instructions that perform bitwise operations, including AND, OR, and EOR.
9. Control Flow: Instructions that alter the program’s execution flow, such as JMP (Jump) and BRA (Branch).
10. Branching Instructions: Instructions that allow for conditional execution, such as BEQ (Branch if Equal) and BNE (Branch if Not Equal).
    Instruction Set
    This processor has an instruction set of only 72 instructions. The instructions + operands range with a usual size of between 1 to 3 bytes. At this size and simplicity, even putting together a simple program without an assembler could be done. Many instructions are variations on the same high-level operation with a different addressing mode. For my task goal, I don’t need to get deep into understanding of the instruction. I just needed to know what is a 1 byte operation that I could do without any additional hardware or memory needed. Many processors support an instruction often called nop, standing for “No Operation.” This instruction, as its name suggest, does nothing beyond take up space. My plan was to hard-wire this instruction into the system. This would let it run without any RAM and without causing any faults or halting conditions.
    For this processor, the numerical value for the nop instruction is 0x01. This is an easy encoding to remember. To wire this instruction in the circuit, I only need to connect the least significant bit of the processor’s data line to a high signal and tie the other ones to a low signal.
    Addressing Modes
    The 6800 supports several addressing modes, which determine how the processor accesses memory. These modes include:
11. Immediate Addressing: The operand is specified directly in the instruction. For example, LDA #$10 loads the value 10 into the accumulator.
12. Zero Page Addressing: This mode accesses memory in the first 256 bytes (zero page) for faster access. For example, LDA $20 loads the value from memory address $20.
13. Absolute Addressing: This mode allows access to any memory location directly using a 16-bit address. For example, LDA $1234 loads the value from memory address $1234.
14. Indexed Addressing: This mode uses index registers to access memory. For example, LDA $20, X loads the value from memory address $20 + X.
15. Indirect Addressing: This mode accesses memory indirectly through a pointer stored in a specified location. For example, LDA ($00) loads the value from the address pointed to by the value at $00.
    Performance
    The Motorola 6800 operates at clock speeds typically ranging from 1 MHz to 2 MHz, depending on the variant. The efficiency of the architecture allows it to execute instructions in a variable number of clock cycles, contributing to its performance. The simplicity of the design, combined with its robust instruction set, enabled the 6800 to perform a wide range of computing tasks effectively.
    Applications of the Motorola 6800
    The 6800 microprocessor has been widely used in various applications across multiple industries, solidifying its status as a classic processor. Some notable applications include:
    Home Computers
16. Apple I and II: The original Apple computers utilized the 6800 architecture, paving the way for the personal computing revolution. The Apple II, in particular, became one of the most successful home computers, featuring advanced graphics and sound capabilities.
17. Atari Consoles: The Atari 2600, released in 1977, relied on the 6800 for its gaming capabilities, contributing to the popularity of home gaming.
18. Commodore PET: The Commodore PET was one of the first all-in-one personal computers, powered by the 6800. Its user-friendly design and built-in monitor made it popular among educational institutions and hobbyists.
    Embedded Systems
    The 6800 found extensive use in embedded systems due to its low cost and efficiency. Applications included:
19. Automotive Control Systems: Many early automotive control systems employed the 6800 for tasks such as engine management and dashboard displays, enabling advancements in automotive technology.
20. Consumer Electronics: The 6800 was integrated into various consumer devices, including microwaves, washing machines, and home appliances, allowing for automation and control.
21. Industrial Automation: The 6800 was used in programmable logic controllers (PLCs) and other industrial applications, enabling improved efficiency and automation in manufacturing processes

Chapter 5
Write up on tech geek HISTORY: VISICALC
Background of the Study
Introduction
Daniel Singer Bricklin was born on the 16th of July in 1951 to a Jewish family living in Philadelphia Pennsylvania. He started programming while still in grade school at Akiba Hebrew Academy. To get a sense of who he was as a child, he wrote some extensions of FORTRAN for a science fair project. After high school, Bricklin attended MIT for mathematics, but quickly changed his major to computer science. He earned his degree in 1973. He then chose to attend Harvard Business School in pursuit of his MBA. He had seen something akin to the Mother of all Demos by Doug Engelbart, and then sitting in room 108 of Aldrich Hall, he daydreamed:
Imagine if my calculator had a ball in its back, like a mouse… imagine if I had a heads-up display, like in a fighter plane, where I could see the virtual image hanging in the air in front of me. I could just move my mouse/keyboard calculator around on the table, punch in a few numbers, circle them to get a sum, do some calculations, and answer ‘10% will be fine!’
The first prototype was in BASIC on Harvard Business School’s timesharing system in Spring of 1978. This prototype is where he figured out the rows, the columns, human-friendly naming for columns, and the status line. Riding his bike around Martha’s Vineyard in the summer of 1978, he decided he would build the product. The first home micro prototype did away with the thought of a mouse. He was working with an Apple ][ borrowed from Dan Fylstra of Personal Software, and he chose to use the arrow keys. Switching between horizontal and vertical movement was done with the space bar. This prototype was written in a weekend using Apple’s BASIC. It was rough, but it did have the columns, the rows, and the arithmetic. At this point, Bricklin’s friend, Bob Frankston, joined him in this endeavor and they took the program from prototype to polished product in two months over the winter of 1978/79.
Significance of the Study
1.1 This final product was written in 6502 assembly for the Apple II . Interestingly, for this step, the programming was done using a macro assembler for the 6502 that ran on MULTICS at MIT, which was accessed via a modem and a DEC Writer III LA-120. Due to the cost of time on the computer at MIT, development was done at night. Eventually, Bricklin and Frankston would have more hardware to write and test, and this development setup would no longer be needed.
VisiCalc was rapidly ported to both newer and older computers. Throughout 1980, VisiCalc was released for the the TRS-80 Model III, the Apple III, the IBM PC, the TRS-80 Model 2, the Commodore PET, the HP 125, and the Atari 800. 1981 saw a port to the Sony SMC-70.
1.2
Overview: The “Electronic Worksheet” The VisiCalc program was born out of the observation that many problems are commonly solved with a calculator, a pencil, and a sheet of paper three nearly universal tools. Calculating sales projections, income taxes, financial ratios, your personal budget, engineering changes, cost estimates, and balancing your checkbook are done with these tools. The VisiCalc program combines the convenience and familiarity of a pocket calculator with the powerful memory and electronic screen capabilities of the personal computer. With the VisiCalc program, the computer’s screen becomes a “window” that looks upon a much larger “electronic worksheet.” You can move or “scroll” this window in four directions to look at any part of the worksheet, or you can split the computer screen into two “windows” to see any two parts of the worksheet at the same time.
The worksheet is organized as a grid of columns and rows. The intersecting lines of the columns and rows define thousands of entry positions. At each position you can enter an alphabetic title, a number, or a formula to be calculated. Just by “writing” on the worksheet, One can set up your own charts, tables, and records. The formatting commands let one individualize the appearance of each entry, row, or column.
One could make your VisiCalc checkbook record look just like your bank statement.
But the power of the VisiCalc program lies in the fact that the computer remembers the formulas and calculations you use in solving a problem. If one changed a number you had previously written on the electronic worksheet, all other related numbers on the worksheet change before your eyes as the VisiCalc program automatically recalculates all of the relevant formulas. Recalculation makes the VisiCalc program a powerful planning and forecasting tool. You can correct mistakes and omissions, and examine various alternatives – effortlessly.
1.3
VisiCalc was the first program to employ an interface of columns and rows to create spreadsheets like those used in analog accounting books. VisiCalc’s Data Interchange Format (DIF) allowed users to enter and manipulate data without coding knowledge, making it easier to use computers for calculations and broadening the appeal of personal computers. Created by Daniel Bricklin and Robert Frankston and released in 1979, VisiCalc would be pivotal in establishing the personal computer as a viable tool for business and accounting purposes.
VisiCalc provides a method for storing data from a spreadsheet onto a special kind of disk file, called a DIF file. DIF stands for Data Interchange Format. The reason DIF is so special is that it stores data in such a way that it can be read by the VisiCalc program or by a BASIC program that you write yourself (or, for that matter, by any number of other programs that you may use on your computer.) In short, DIF files provide a THE VISICALC PROGRAM AND YOUR COMPUTER means of trading data between various programming tools
The three kinds of data entry into the VisiCalc program result in two types of data. Values are numerical data; labels are non numerical. Value references, which are the building blocks of formulas, result in numerical values.
1.4
ENTERING DATA There are three different kinds of data entry into the VisiCalc program, but they result in only two different types of data. Labels essentially represent nonnumeric data. Values and value references represent numeric data. In addition, value references can be used to build formulas for your worksheet. Put simply, a value reference is a way of duplicating the contents of any position on your spreadsheet for use in another position.
All of the functions have one thing in common. You had to enter a special “flag” character to alert the VisiCalc program of your intention to use a function. This flag is the “at” symbol on your keyboard (@). You must type this symbol as the first character of any of the functions; for example:
@SUM
@AVERAGE
@SIN
@MAX
VisiCalc had many functions that Microsoft Excell displays in its Formula Software.
VisiCalc became the first program on a personal computer to be responsible for driving sales of an entire system. By chance, the program’s developers used a borrowed Apple II to develop the program, and as a result that was the first system for which the program was released. When VisiCalc became available, sales of the previously struggling Apple II spiked, which was a boom for the company and made VisiCalc the first “killer app.”
Conclusion
By 1981 Software Arts, the company started by Bricklin and Frankston, had made over $12 million in royalties from VisiCalc. By 1983, however, more powerful programs such as the Lotus 1-2-3 had been released and outsold the outdated VisiCalc, which never regained its early industry position.
The personal computer revolutionized office spaces in the 1980s, and VisiCalc was the first application to firmly establish the need for the PC in the business environment. The importance of a spreadsheet application for businesses today is without question, and VisiCalc pioneered the spreadsheet technology that can still be seen in programs such as Microsoft Excel, Apple Numbers, and Google Sheets.

Chapter 6
Write up on tech geek HISTORY: Integrated Data Store (IDS) General Electric
Background of the Study:
Introduction:
Charles Bachman was a pioneer in the management of computer database systems. He spent his entire career in industry, working for Dow Chemical, GE, Honeywell, Cullinane Database Systems, and his own startup Bachman Information Systems. His work at GE in the early 1960’s, building the first company-wide database management system, called Integrated Data Store (IDS), allowed users across the company to access a common database. In 1973 he was awarded the ACM Turing Award for this work
Bachman created IDS as a practical tool, not an academic research project. In 1963 there was no database research community.
Literature Review:
One of the oldest DBMSs, Integrated Data Store (IDS), was developed at General Electric by Charles Bachman during the early 1960s using the network model. The Conference on Data Systems Languages (CODASYL), an organization consisting of representatives of major hardware and software vendors and users, was formed to try to standardize many aspects of data processing. CODASYL had successfully written standards for the COBOL language. In the late 1960s the CODASYL organization formed a subgroup called the Data Base Task Group (DBTG) to address the question of standardization for database management systems. Influenced by IDS, the group proposed a network-based model and specifications for data definition and data manipulation languages. In 1971 its first official report was submitted to the American National Standards Institute (ANSI), which refused to accept or reject the proposed standard. The 1971 report was succeeded by several newer versions, but it remained the principal document describing a network-based model generally referred to as the CODASYL model or the DBTG model, and several popular database management systems were based on it. In addition, it provided the vocabulary and framework for discussion of database issues, establishing for the first time the notion of a layered database architecture and common terminology. Although the hierarchical and network models were powerful and efficient, they were complex, requiring users to understand data structures and access paths to data. They were designed for use with programs rather than for interactive access by users. The logic required to locate the desired records was contained in the applications, not in the database The relational model was first proposed by E.F. Codd in 1970, in a paper called “A Relational Model of Data for Large Shared Data Banks.” It was the first model based on abstract concepts from mathematics, which provided a strong theoretical base. Early research on the model was done at the IBM Research Laboratory in San Jose, California. System R, a prototype relational database management system (RDBMS), was developed by IBM researchers during the late 1970s, and the research results, including the development of a new language, SQL (Structured Query
1.1
Historical Developments in Information Systems 13 Language), were widely published. Another important research project based on the relational model was Ingres, developed at the University of California, Berkeley, by Eugene Wong and Michael Stonebraker. Both Postgres and PostgreSQL were developed from Ingres. Recognizing the value of the relational model, Larry Ellison, along with Bob Miner and Ed Oates, founded a company to use the results of the System R project and released Oracle, the first commercial RDBMS, in 1979. IBM released its first commercial RDBMS, called SQL/DS, in 1981, followed by the announcement of DB2 in 1983. The widespread use of microcomputers beginning in the 1980s led to the development of PC-based RDBMSs. SQL, the language developed for System R, became the standard data language for relational-model databases, with ANSI-approved standards published starting in 1986, major revisions in 1992 (SQL2) and 1999 (SQL3), and further expansions in 2003, 2006, 2008, 2011, 2016, and 2019. Oracle, DB2, Microsoft’s SQL Server, MySQL, Microsoft Access, and PostgreSQL, all of which use the relational model, are popular DBMSs. The relational model uses simple tables to organize data. However, it does not allow database designers to express some important distinctions when they model an enterprise. In 1976, Peter Chen developed a new type of model, the entity-relationship (ER) model. This is an example of a semantic model, one that attempts to capture the meaning of the data it represents. It is most often used in the design phase for databases. The ER model has been extended several times to make it semantically richer, resulting in the extended entity-relationship (EER) model
1.2
Before integrated databases were created, file processing systems were used, and data used by an organization’s application programs was stored in separate files. (Note: Although the word data is plural in standard English, it is customary to use it as both singular and plural in database literature, as in “data is” and “data are.”) Typically, a department that needed an application program worked with the organization’s data processing department to create specifications for both the program and the data needed for it. Often the same data was collected and stored independently by several departments within an organization, but not shared. Each application had its own data files that were created specifically for the application and that belonged to the department for which the application was written. Personal computer databases can create a similar scenario, where individuals or departments set up their own databases or spreadsheets containing data, creating data silos, isolated collections of data that are inaccessible to other departments within an organization. Having multiple copies of the same data within isolated files or small databases can lead to flawed, outdated, or contradictory information, thus creating confusion for users. Most organizations can benefit by having the data used for sets of applications integrated into a single database. In this text, we assume the typical database is a large one belonging to a business or organization, which we will call the enterprise. However, the techniques described apply to databases of all sizes. An integrated database is a collection of related data that can be used simultaneously by many departments and users in an enterprise. It is typically a large database that contains all the data needed by an enterprise for a specific group of applications or even for all of its applications stored together, with as little repetition as possible. Several different types of records may appear in the database. Information about the structure of the records and the logical connections between the data items and records is also stored in the database, so that the system knows, for example, which faculty record is connected to a particular class record. This “data about data” is called metadata.
1.3
The Integrated Data Store (IDS), the first direct-access database management system, was developed at General Electric in the early 1960s. Revisiting the development challenges that lead to its first production version reveals the origins of DBMSs and their impact on software development and business management. IDS and its derivative systems are still in use today, supporting a thousand mainframe installations
1.4
In the late 1950s and early 1960s, no independent software vendor industry existed. Software of all kinds was developed either by computer manufacturers or by one or a group of computer users. It was either bundled with the computer at no extra cost or given away free and shared by the users who developed it, much like today’s open source movement. This article will examine the business requirements that lead to the development of the Integrated Data Store (IDS), the first direct-access database management system (DBMS),1 and will look at some of the develop[1]ment challenges that lead to its first produc[1]tion version. To this day, IDS leads a healthy, productive life, driving large transaction[1]oriented systems around the world, 50 years after its conception. When General Electric engineers first began developing IDS in 1961, there were no general purpose operating systems, no file systems, no DBMSs, and no communications systems to learn from or build on. There was no multi[1]programming, time sharing, or online debug[1]ging tools. The machines were essentially naked. For business data processing, it was a batch-oriented, serial-file-processing, load and execute one-program-at-a-time world
1.5
DEFINITION STRUCTURE The Definition Structure required by IDS is a list structure which reflects the description of the various data records of the IDS file. It defines the master/detail relationships between data records, the chain characteristics, and the physical and control characteristics of every field of every record type in the IDS file.
In the late 1950s, GE was the largest commercial user of computers in the world. GE was also the biggest manufacturer of computers for demand deposit accounting. From 1958 to 1965, the GE Integrated System Projects (ISPs) were driven by GE’s Manufacturing Services, lead by Halbert Miller. The company’s corporate services provided research, expertise, and consulting to its 100 product manufacturing departments. These product departments were in a range of product areas: atomic energy, electric energy generation and distribution, jet engines, electric motors, home appliances, light bulbs, x-ray machines, diesel electric locomotives, artificial diamonds, and general-purpose computers. At that time, GE’s Manufacturing Services management was greatly concerned that all of GE’s manufacturing businesses were investing heavily in the design and installation of computerized manufacturing systems and that the development process was slow, expensive, and error prone.
The first ISP (1958–1959) developed some interesting product ideas in the area of manufacturing simulation (later leading to SIMSCRIPT), generative engineering, and decision tables (TABSOL).
The second ISP (ISP 2) began late in 1960. Its target was to design and build a generic manufacturing control system. The project was managed by GE’s Production Control Ser[1]vice and lead by Stanley B. Williams. Williams came from the GE Large Transformer Department in Pittsfield, Massachusetts, and had 12 years of engineering and engineering systems experience. I joined the project as its chief architect, with 10 years of experience in engineering, finance, manufacturing, and data processing with the Dow Chemical Company in Midland, Michigan
The first packaged versions of IDS did lack some features later viewed as essential for database management systems. One was the idea that specific users could be granted or denied access to particular parts of the data[1]base. This omission was related to another limitation: IDS databases could be queried or modified only by writing and executing programs in which IDS calls were included. There was no capability to specify “ad hoc” reports or run one-off queries without having to write a program.
These capabilities did exist during the 1960s in report genera[1]tor systems (such as 9PAC and MARK IV) and in online interactive data management systems (such as TDMS) but these packages were generally seen as a separate class of software from database management systems. By the 1970s report generation packages, still widely used, included optional mod[1]ules to interface with data stored in database management systems.
Integrated Data Store (IDS) The IDS DBMS was created by assembling many elements that had appeared in research papers and existing systems. We combined these with some new elements so that the whole would meet the envisioned manufacturing control system’s requirements. This included the following elements: A direct access database was implemented on a virtual memory basis, with page turning, revitalized hash (calculated) addressing, data integrity control, clustered records, and database keys. The network data model, with logical records that mapped transparently onto physical records in the virtual memory and logical O/M sets, was mapped transparently onto linked lists of physical records.
A data description language, with Data Description Language (DDL) statements that defined the types of logical records with their data, relationships, and constraints that could appear within the database. A data storage and retrieval language, with Data Manipulation Language (DML) statements could be easily integrated into a record-at-a-time procedural language, such as GECOM, Comtran, Fact, Cobol, or PL/1, which were also available. The record-at-a-time data-manipulation statements included STORE, RETRIEVE, MODIFY, and DELETE. An exclusive ‘‘working storage’’ area for each record type, providing the computer memory locations where IDS and the application programs, could exchange data under tight integrity controls.

Chapter 7
Write up on Tech Geek History: FORTRAN Complier
Literature Review
FORTRAN as a Programming Language
The FORTRAN programming language was conceived in the early 1950s the name produced from the two words Formula Translation. In 1966 the language was standardized and FORTRAN IV was born.
Revision of the language led to FORTRAN 77, the language we use today. The standard for FORTRAN 90 is now available although not yet in widespread use. F77 is a subset of F90.
FORTRAN was designed for scientists and engineers, and has dominated this field. For the past 30 years FORTRAN has been used for such projects as the design of bridges and aero plane structures, it is used for factory automation control, for storm drainage design, analysis of scientific data and so on.
The Fortran Programming Language
Fortran is a programming language with a long history. Originally developed in the 1950s, it was first created in a time before the internet, laptop computers, and desktop computers before computers even have a screen. Fortran was created at a time when computers were almost exclusively designed and operated to carry out numerical operations. Programming in Fortran today is very different from how programmers introduce instructions and compile codes. During the first decades of electronic computers, programming was done with punched cards, data was stored in tapes, and results were printed with dot matrix printers. Over more than 60 years, the language itself has evolved to accommodate new ways of programming, new hardware, new levels of complexity, and new ways of using computers for numerical calculations.
Evolution of Fortran
The first versions of the language introduce many of the concepts used today in most programming languages, the idea of loops, conditionals, and variables. Those elements are so commonplace today that we do not see as anything revolutionary, but FORTRAN was the first language to introduce many of those elements in programming, at least in a way that resemble the ways we program today.
The first milestone in the language was achieved with FORTRAN 77. This standard introduces structured programming and the processing of characters. Structured programming allows us to create larger codes and reuse pieces of code in ways that are easier to understand for a human. FORTRAN 77 was so successful that took more than a decade to reach an agreement over the new milestone. Fortran 90 added array, modular and generic programming. Those elements increase the flexibility of codes to accommodate data in run time instead of requiring constant recompilation when the parameters changed. Modules allow even larger codes to introduce tools to aggregate routines with variables. Fortran 90 left behind some issues that were solved in Fortran 95. Fortran 95 clarify some aspects of the language and was the first to introduce some parallelization techniques (HPF) well before OpenMP and other paradigms proved to be more effective for that. Fortran 2003 was the next big step in introducing Object Oriented Programming in a way that makes sense for scientific computing. The most recent developments in the language come from Fortran 2008 and 2018 which includes native parallel computing in the form of Co-arrays.
With such extensive evolution of the language, the standard retained compatibility with previous versions, being far more conservative than other languages. Scientific codes are developed for decades and used even longer. Many of the codes that run today on larger supercomputers were first developed in the 1980s and could have 1 million lines of code or more. If the language specification does not retain some compatibility many of those efforts could be lost or will become attached to older compilers losing the ability to evolve themselves.
.In this Paper is discussed the Earlier Version of Fotran; the History of:
Focusing on Fotran Compliers what Fotran is most distinctive
The IBM 1401 FORTRAN compiler1 was designed as a set of phases that operate sequentially on the source program. The source program having been placed in core storage, the compiler phases enter core one at a time. Each phase overlays its predecessor, operates on the source program and, in turn, is overlaid by the next phase of the sequence. Thus, in contrast to the customary technique of passing the source program against the compiler in core, the compiler is passed against the source program which resides in core. It is assumed that the source program is more concise than the object program, and that an object program of interest can be accommodated in core.
The 1401 FORTRAN compiler was designed for a minimum of 8000 positions of core, with tape usage being optional. The fundamental design problem stems from the core storage limitation. Because the average number of instructions per phase and the number of phases selected are inversely related (at least to a significant degree), the phase organization was employed to circumvent the core limitation. The 1401 FORTRAN compiler has 63 phases, an average of 150 instructions per phase, and a maximum of 300 instructions in any phase.

---

efficiency of the compilation technique Experience with the compiler suggests that, even though the basic compilation technique requires repetitive scanning of the source program, the time required for this redundant effort is small. The experience lends some credence to the following argument.
If a phase is decomposed into two serially acting phases, assume that the average execution time is increased by a multiplicative factor r. If each component phase is again decomposed into two phases, the average total execution time of the resulting four phases increases to r2 times the original. After k decompositions, 2k phases result, with an average total execution time of rk times the original. Under this assumption, it follows that an n-phase compiler takes rlog2n times longer than a comparable one-phase compiler. Because some phases do not involve scanning, this estimate may tend to be high.
Based on experience with the present compiler, it is conjectured that r ~ 1.05 and that the redundant work occasioned by the use of 63 phases increases compilation time by a factor of 1.05log263 ~ 1.3.
However, this technique reduces compilation time elsewhere, so that the net increase can be expected to be less than conjectured. Since the phases act serially, tape searching is unnecessary. Moreover, no external sorts or merges are required. After one pass of the processor, the object program lies in core storage, ready for execution.
Also, the present technique permits an approach to coding that tends to reduce compilation time. Decomposition into an appropriate number of phases often results in more available core space for execution of an individual phase than the minimum needed.
The typical phase requires only on the order of 150 instructions, although twice that number are accommodated by the allocated region in core. Thus, most of the code can be written for efficient execution without regard to economy in the number of instructions employed. Other advantages inherent in this type of coding are that it is usually faster to write and easier to debug.
________________________________________compilation time Except for certain extreme cases in which the object program fills almost all of core, the compilation time in seconds t is approximated by a linear function of the number of FORTRAN statements n (the statements assumed to be of average complexity). If the compiler is on tape, reads the source program from cards, and punches a self-loading machine language object program, then t = (0.96n + 72) seconds. As a load-and-go system, with the punching of the object program suppressed, t = (0.76n + 22) seconds. If the system is on cards, an additional 173 seconds are required.
________________________________________compiler phases The principal function of each phase of the compiler2 is indicated below. Secondary functions are subordinated; for ex- ample, error checking occurs in almost every phase, but is seldom mentioned.
Phase 00 – Snapshot. Loads a snapshot routine into 350 positions of core storage. This routine lists a specified amount of core storage.
Phase 01 – System Monitor. Brings in the next phase from the system tape or initiates reading of the next phase from cards, depending on whether the compiler is used as a tape or card system. The monitor and snapshot routines are the only ones that exist in storage throughout compilation. Because the phases act serially, very little is required of this phase which consists of only 20 instructions.
Phase 02 – Loader. Stores the entire source program, statement by statement, with all non-significant blanks eliminated. The source program is stored backwards in order to use the 1401 machine instructions that cause address registers to decrement when processing data. Appended on the right of each statement is a three-position internal sequence number (001 for the first statement, 002 for the second, etc.). The sequenced source program is printed.
Phase 03 – Scanner. Determines the type of each statement and appends a code on the right of each statement. For example, D for DO, S for STOP, I for DIMENSION statements, etc.
Phase 04 – Sort I. Determines if there is enough free storage to expand each statement by three characters.
Phase 05 – Sort II. Statements of the same type are chained together. Each statement expands by three characters-the machine address of the next statement of the same type.
Phase 06 – Sort III. The source program is sorted3 internally by statement type. The order of sorting is determined by the order in which statements of a given type undergo specific processing by subsequent phases. For example, since DIMENSION statements are processed (Phase 09) before DO statements (Phase 46), the DIMENSION statements are grouped together lower in core than the DO statements.
Phase 07 – Insert Group Mark. This is a housekeeping phase.
Phase 08 – Squoze. The words that helped define the type of each statement are eliminated, shrinking the source program. For example, the word “DIMENSION” in DIMENSION statements is eliminated.
Phase 09 – Dimension I. The DIMENSION statements are scanned, and an array table is generated in free storage. Each table element consists of the name of an array, its dimensions, and sufficient space for additional data to be. generated by Phases 11 and 12.
Phase 10 – Equivalence I. Adds simple variables present in EQUIVALENCE statements to the array table. These variables are treated, in effect, as one-element arrays.
Phase 11 – Equivalence II. The array table is altered to show the relationship between arrays. Equated arrays are chained together. Essentially, the procedure makes known to every array whose first element is equivalent to a secondary element of another array the “distance” to the first element of the latter array.
Phase 12 – Dimension II. The object-time addresses which delimit each array are computed and inserted in the array table. These addresses are also printed.
Phase 13 – Variables I. The entire source program is scanned for variables. The following changes are made directly within the text of the source program:
Simple variables are tagged for later processing by Phase 16.
Subscripted variables with constant subscripts are replaced by the object-time address of the designated array element.
All other subscripted variables are put into a canonical form which specifies a computation in terms of variables and constants for determining the object-time address of the array element specified.
Non-subscripted array names appearing in lists are replaced by the object-time address that delimit the array named.
Non-subscripted array names appearing elsewhere are replaced by the object-time address of the first element of the array.
Phase 14 – Variables II. All free storage (including the array table) is cleared and partitioned into two tables areas-Tables I and II. Parameters needed for the randomizer of Phase 16 are computed.
Phase 15 – Variables III. Does housekeeping for Phase 16.
Phase 16 – Variables IV. The source program is scanned twice for simple variables (already tagged by Phase 13). During the first scan, the compiler looks for variables being defined, i.e., those appearing on the left of an equal sign or in input lists. By means of a randomizer that computes an indirect address (a Table I address at which is located a Table II address), each such variable and its object-time address is stored uniquely and sequentially (one after another) in Table II. The object-time address replaces the variable name in the source program. During the second scan, all other variables are picked up, and the same process is carried out, except that undefined variables are noted and Table II entries are flagged whenever referenced.
Phase 17 – Variables V. Table II is scanned. The absence of a flag indicates an unreferenced variable. The object-time address of each variable is printed.
Phase 18 – Constants I. The entire source program is scanned for constants. Each constant encountered is normalized and tagged. Tables I and II are destroyed.
Phase 19 – Constants II. All free storage is again cleared and partitioned into two table areas- Tables I and II. Parameters are now stored, each with its identifier (Phase 32), in lower core immediately to the left of the list and format “statements.”
Phase 20 – Constants III. The entire source program is scanned for normalized constants (tagged by Phase 18). By means of a randomizer (as in Phase 16), each normalized constant is stored uniquely and sequentially (next to one another) in Table II. Once stored, these constants are at their object-time address and are not disturbed for the remainder of the compilation. The object-time address replaces the normalized constant directly in the text of the source program.
Phase 21 – Subscripts. Under the action of Phases 14 through 20, the canonical form for subscripted variables (see Phase 13) now specifies a computation in terms of object-time addresses. This phase simplifies the computation, leaving only the object-time addresses which serve as parameters for a closed subroutine at object time.
Phase 22 – Statement Numbers I. Statement numbers that appear in the source program are reduced to a 3-character representation. Statement numbers within the body of a statement are moved to the front of the statement.
Phase 23 – Format I. FORMAT statements are checked to ensure that they are referenced by input/output statements.
Phase 24 – Format II. The object-time format strings are developed and stored immediately preceding the constants at the lower end of storage.
Phase 25 – Lists I. Duplicate lists are checked and eliminated to optimize storage at object time.
Phase 26 – Lists II. The object-time list strings are developed and stored immediately to the left of the format strings at the lower end of storage.
Phase 27 – Lists III. Each input/output statement is reduced to the address of the list string (when present), the address of the format string (when present), and the tape unit number (where applicable).
Phase 28 – Statement Numbers II. All free storage is again cleared and partitioned into two tables-Tables I and II. Parameters needed for Phase 29 are computed.
Phase 29 – Statement Numbers III. By means of a randomizer (as in Phase 16), statement number representations (Phase 22) appearing within statements are stored uniquely, one after another, in Table II. Each such representation is replaced by the machine address at which it is stored.
Phase 30 – Statement Numbers IV. Statement number representations are matched against Table II entries via the randomizer of Phase 29. The sequence number of the statement (Phase 02) replaces the Table II entry. The Table II address (which now contains the sequence number) replaces both the representation and the sequence number in the source program. Undefined and multiply-defined statement numbers are checked.
Phase 31 – Statement Numbers V. Table II is scanned for unreferenced statement numbers (representations).
Note: Whereas the source program originally was composed of constants, variables, and statement numbers of arbitrary length, it is now highly structured and is composed of 3-character machine addresses. Machine addresses substituted for constants and variables are their object-time addresses. Machine addresses substituted for statement numbers are indirect addresses which currently reference Table II entries-sequence numbers of labeled statements. Eventually (Phase 51) these indirect addresses are replaced by the object-time addresses of the labeled statements, i.e., the addresses of object programs compiled from these statements.
Phase 32 – Input/Output I. The residue of each I/O statement other than BACKSPACE, REWIND, and END FILE is substituted into an object-time mask. The filled-in mask and an identifier are stored in lower core immediately adjacent to the last entry in Table II. The identifier is the sequence number (Phase 02) or, only when the statement originally had a statement number, the machine address of the sequence number stored in Table II (Phase 30).
Phase 33 – Arith I. All arithmetic expressions appearing in the source program are scanned. Switches are set to indicate which function routines must be loaded by Phase 52. Minor changes are made to expressions, and sufficient error testing is done to expedite Phase 34.
Phase 34 – Arith II. By means of a transition matrix,4 each arithmetic expression is broken down into a sequence of one or two operand sub-expressions involving temporary dummy storage locations.
Phase 35 – Arith III. Initialization for Phase 36.
Phase 36 – Arith IV. Redundant references to temporary dummy storage locations are eliminated by forming maximal strings of operands and operators from each sequence of sub-expressions. Each string specifies the computation in which (1) unary operators act on the entire substring immediately to their left and (2) binary operators combine this substring with the operand on their right.
Phase 37 – Arith V. Exponentiation operators are replaced by substrings involving log and anti-log functions. Implied mode changes are made explicit by inserting (or deleting) fix or float operators in the strings. The Table II addresses (Phase 29) appearing within IF statements (involving arithmetic expressions) are substituted into masks of object-time instructions. The filled-in mask replaces the addresses in the source program.
Phase 38 – Arith VI. The arithmetic strings are altered so that temporary storage areas are shared whenever possible. Machine addresses are determined for these areas and substituted for the dummy addresses in the strings. Previous arithmetic and IF statements are now stored, each with its identifier (Phase 32), in lower core immediately to the left of the list and format “statements.”
Phase 39 – End file, Rewind, Backspace.
Phase 40 – Computed Go To.
Phase 41 – Go To.
Phase 42 – Stop/Pause.
Phase 43 – Sense Light.
Phase 44 – If (Hardware).
Phases 39 through 44 are essentially the same. In each phase, the residue of statements of the indicated type are substituted into masks of in-line, object-time instructions. The filled-in masks are stored with their identifiers (Phase 32) at the next available locations in lower core.
Phase 45 – Continue. No object-time instructions are generated for these statements. Only the identifiers (Phase 30) are stored in lower core.
Phase 46 – Do. DO statements are analyzed for nesting. Illegal nesting is noted. The residue of each DO statement is substituted into an object-time mask; but in general, the exit address is left blank. The partially filled-in mask and its identifier are stored in lower core. An unconditional branch is generated (uniquely) to follow (via Phase 49) the last statement within the range of the DO.
Note: At thus point, the entire source program has been transformed into (essentially) object program procedure. For simplicity, we continue to write “statement” when we mean “procedure compiled from statement.”
Phase 47 – Resort I. An area is made available for a table to assist in resorting the statements into their original order.
Phase 48 – Resort II. The resort table is filled with the current location of each statement.
Phase 49 – Resort III. The statements are resorted back into their original order with the identifiers eliminated. The Table II entries (sequence numbers of statements originally labeled with statement numbers) are replaced by the current machine ad- dresses of those statements. Exit addresses are substituted into the procedure generated for DO statements (Phase 46). For each executable statement, the sequence number and the object-time starting address of the generated procedure are printed.
Phase 50 – Resort IV. The statements are shifted to the places they will occupy at object time. The Table II entries are bumped accordingly.
Phase 51 – Replace I. The entire object program procedure is scanned for indirect addresses (see note following Phase 31). Each indirect address is replaced by its direct address-now available in Table II.
Phase 52 – Function/Subroutine Loader. Relocatable function routines and subroutines (which comprise Phase 53) are selectively loaded. A table of starting addresses of these routines is created in free storage.
Phase 53 – Relocatable Package. This phase consists of the relocatable routines loaded by Phase 52.
Phase 54 – Format Loader. The object-time format routine, which is included in this phase, is loaded.
Phase 55 – Replace II. Those instructions in the generated object program that should branch to the relocatable routines are modified (via the table of Phase 52) to show the object-time addresses of these routines.
Phase 56 – Snapshot. A snapshot of the generated program is printed if initially requested and if no source program errors have been detected that would make program execution unrewarding.
Phases 57, 58, 59, 60 – Condensed Deck. When requested and if there are no input errors, these phases punch and list the object program as a self-loading condensed card deck.
Phase 61 — Geaux I. This phase prints the end-of-compilation message, initializes the sense lights, and prepares the branch into the object program coding.
Phase 62 – Geaux II. The arithmetic routine (Phase 63) is read into storage. Communication between this routine and the relocatable routines is established. The object program is executed on option.
Phase 63 – Arithmetic Package. This phase consists of the arithmetic routine loaded by Phase 62.
The First IBM Fotran Compiler is discussed on a more Technical -High End Scale Point:
The IBM FORTRAN Pre-Compiler is a program that detects and permits correction of errors in a FORTRAN source program before the object program is compiled. The Pre-Compiler detects many of the more common programming errors in individual source statements, and indicates possible logical errors in the source program as a whole. Two versions of the Pre-Compiler are provided, one for use with the IBM 1621 Paper Tape Reader and IBM Tape Punch, and the other for the IBM 1622 Card Read Punch.
A FORTRAN source program which is to be processed was to be punched in paper tape or cards, or may be entered directly from the typewriter.
The operation of the Pre-Compiler could be divided into two phases: Error Analysis and Final Program Summary. During the error analysis phase, each statement in the FORTRAN program is analyzed for an error. If an error is detected, an error code is typed, the statement containing the error is typed, and the program halts so that you can type the statement correctly.
During this phase, a new FORTRAN source program was punched in paper tape or cards. After all statements have been analyzed and corrected, if desired, a final program summary is typed. The final program summary phase includes information about possible sources of errors not detectable in individual source statements. An additional feature of the Pre-Compiler program, using the 1620 program switches, permits you to easily alter the functions of the error analysis phase for individual requirements. The following options are available.
The following were Instructional Sets based on the Original Fotran Complier:

1. You can suspend the halt and error correction routines, thereby providing a quick error analysis only. These routines can be suspended for the entire program or for individual error halts during normal processing.
2. You can enter the program through the console typewriter rather than by card or paper tape input.
3. You can eliminate punching of an edited source program.
4. You can have correct program statements typed, in addition to the normal operation in which only incorrect statements are typed. The standard 1620 FORTRAN Pre-Compiler system contains all of the functional subroutine names included in the standard FORTRAN system. If you make alterations to the functional names, or if you add additional subroutines to the FORTRAN system, you must make the corresponding alterations and additions to the PreCompiler system.
   Operation of the Pre-Compiler Program Error Codes 72 Before you process any program on the Pre-Compiler, you should be familiar with the nature of the errors that the program is deSigned to detect.
   During the error analysis phase of the program, each statement is analyzed for one or more specific errors. These errors consist of 51 of the most common errors usually found in FORTRAN source programs.
   As an aid in evaluating these errors, they have been grouped into seven categories: Arithmetic statements Arithmetic Statements Variables in Arithmetic
   Expressions DO Loops Constants Variables in arithmetic statements DO loops Constants Statement numbers Transfer statements General
   When an error is detected, an error code is typed on the console typewriter. This code consists of an alphabetic abbreviation of one of the categories listed above, followed by a number that designates the particular error in the category. ARITH
5. Unacceptable form to left of == sign.
6. Multiple == signs.
7. This code has been deleted.
8. Successive operation symbols, or a function which is followed by an operation symbol. 5. Missing operation symbol or operand.
9. Right parenthesis encountered before corresponding left parenthesis.
10. Missing right parenthesis.
11. Mixed mode expression (expression contains fixed and floating point).
12. No variable to the left of equal sign.
13. Involution of a fixed point variable or constant. VAR
14. Variable name longer than 5 alphameric characters.
15. Variable appearing in an expression or as a subscript not previously defined in an input statement; as the index of a DO loop; or defined as the left side of another arithmetic statement.
16. Variable written with a subscript has not been previously defined in a DIMENSION statement.
17. Variable previously defined in a DIMENSION statement has not been subscripted correctly: subscript is in unacceptable form, number of subscripts does not agree with the number specified in DIMENSION statement, numerical subscript is greater than maximum allowed by DIMENSION statement or is less than
18. DO 1. In the statement DO n i == m], m 2 , m,J, the indices m}, m 2 , and m.l , if given, are not all unsigned fixed point variables or constants greater than zero. There are more than 3 indices given.
19. The second index, m2 , is less than mJ, when botq are constants.
20. The third index, m.l , is signed, is zero, or is missing when specified as a constant.
21. The statement number n is not in acceptable form or is missing.
22. The variable name has either been omitted, or is incorrectly stated, or the DO statement is incorrect.
23. The statement specified as the end of an outer loop in a nest of DO’S has been found before an inner loop is complete.
24. A DO loop terminates with a transfer statement, GO TO, computed GO TO, or
    IF. CONST
25. Fixed point constant longer than 4 digits.
26. Floating point constant outside the allowable range.
27. Decimal point omitted from floating point constant that is written with a decimal exponent.
    The FORTRAN Pre-Compiler Program
    73 Statement Numbers Transfer Statements General
    74
28. The decimal exponent following the E in a floating point constant is incorrectly expressed in form or size.
29. The exponent following an E has been omitted.
30. Floating point number followed by an alphabetic character other than E.
    STNO
31. Statement number longer than 4 digits.
32. Statement number has been previously defined.
33. Unnumbered CONTINUE statement. (Should be numbered when used as last statement in a DO loop.)
34. Statement immediately following a transfer statement is not numbered, and is therefore inaccessible to the source program. (If the previous statement is a transfer, the only way the program can process this statement is by a transfer to it, and therefore it must always be numbered.)
    TRANS 1. Statement numbers in a transfer statement (GO TO, computed GO TO, or IF) are not acceptable fixed point numbers; there is no comma between statement numbers, or there is not the required number of statement numbers. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. 6. Comma missing after the right parenthesis in a computed GO TO statement. Index in a computed GO TO statement is not a fixed point variable, or is missing. Nonnumerical character follows right parenthesis in an IF statement. In an IF statement, a character other than a left parenthesis follows the word IF. No arithmetic statement within the parentheses after the IF. (However, empty parentheses in an arithmetic statement will not be detected.)
    GEN Misspelled or unacceptable nonarithmetic statement. Statement contains an unacceptable character. More than 72 characters in statement (not applicable to cards). Symbol table full (occupies more than 2,500 digits in storage). Statement contains decimal point that is not in a floating point constant. Input/output statement contains no FORMAT number, or is incorrectly stated.
35. First character in an input/ouput list is not alphabetic, or the final character is not a letter or a digit.
36. In a DIMENSION statement, a nonalphabetic character precedes the first variable name or a dimension, or three dimensions have been specified ( only two-dimensional arrays are permitted).
37. A specified dimension is incorrect: a parenthesis has been omitted, a floating point constant or an unacceptable fixed point constant has been used, etc.
38. Unnumbered FORMAT statement.
39. Incomplete FORMAT statement: invalid or incorrect specification, missing parentheses, character after right parenthesis, etc.
40. In an input/output statement, comma is missing after the FORMAT statement number, or the list is missing or invalid.
41. The total record width specified in a FORMAT statement exceeds 87.
42. A variable in a DIMENSION statement has been previously defined.
43. a. The letter H orX is missingin an alphameric FORMAT statement or the width of an alphameric FORMAT statement is greater than
44. b. A FORMAT statement does not contain any of the specification types, I, H, X, E, or F. Error Analysis Phase Restart Procedure Final Program Summary After an error has been detected in a statement, and the appropriate error code has been typed, the original error statement is typed. If switch 3 is off, the carriage is returned and the program halts to wait for a corrected statement to be typed in. After reviewing the erroneous statement and the error code or codes indicated, you can, in most cases, make an immediate correction to the statement. Type the correct statement (followed by a record mark), then press the release and. start keys.
    The program resumes by analyzing the statement just typed to determine if any errors still exist. If the statement is correct, the program will begin analyzing the next statement in the FORTRAN program. In some cases, it may not be possible to re-enter a corrected statement without certain modifications because part of the statement has already been processed as a correct statement. For example, if an error is discovered in a transfer statement (GO TO), you must enter the correct statement with a statement number to avoid error STNO 4, or enter it twice without a statement number. (The program considers the first part of the GO TO to be correct, and requires that any statement following a transfer statement must contain a statement number). When a statement containing a statement number is partially processed due to an error, you cannot re-enter the statement with the statement number because an error STNO 2 will result. In an erroneous DIMENSION statement, for example DIMENSION C ( N ), the C is stored as a nonsubscripted variable and cannot be used later in the program as a subscripted variable. In case of C( 10,N), the C is stored as a one-dimensioned variable. Restart of the Pre-Compiler is necessary.
    For expressions involving involution (raising to a power), the exponent cannot have an involution operation. For example, A * * (B * * 2. +.1) will result in erroneous operation of the Pre-Compiler. This restriction also applies to the arithmetic expression in an IF statement. There is no check for the termination of a DO loop.
    If a dimension specification exceeds the capacity of the storage, erroneous results will follow. If an immediate correction cannot be made, you can resume testing of the next statement by manually branching to BEGIN (see RESTART PROCEDURES). It is important to note that if a new source program is being punched, bypassing the error correction routine will result in the incorrect statement being punched into the output tape or cards.
    The normal operation of the Pre-Compiler program is to type incorrect statements only. If you require a typed copy of all statements, turn on program switch
45. You may find it necessary during processing to interrupt the normal operation of the program. To allow such interruptions, the following re-entry points, given by symbolic label and storage location, are available: CLEAR location 01208: The symbol table and table of statement numbers referenced by DO statements are cleared. CLEAR is the restart point for a new program to be tested. INITL location 01340: The table of statement numbers referenced by DO statements is cleared
46. . BEGIN location 01472: No tables are cleared, but the program will continue to read source program statements. BEGIN is the normal entry point for restarting after a check stop or other interruptions of the Pre-Compiler. After the END statement in a source program has been processed by the PreCompiler program, a final program summary was a typewritter
    ENTER SOURCE PROGRAM THEN PUSH START and the program will halt. Set the console program switches for the correct input I output options, mount the source tape or load the source deck, and begin processing by pressing the start key. After the END statement in a source program has been processed, the final program summary will be typed on the console typewriter. This will consist of the following four messages, together with the related lists of statement numbers and relocatable subroutines called by name in the source program.
    UNDEFINED STATEMENT NUMBERS UNREFERENCED STATEMENT NUMBERS RELOCATABLE SUBROUTINES CALLED OBJECT PROGRAM DATA TABLE XXXXX STORAGE POSITIONS
    The absence of one of the first three messages indicates that no undefined or unreferenced statement numbers have been found, or that no relocatable subroutines have been used by name in the source program. Undefined statement numbers are those referenced by a transfer, DO or Ilo statement, but not defined. After the final summary has been typed, the following message will be typed on the console typewriter and the program will halt.
    PROCESSING COMPLETE Pressing the start key causes the program to clear the symbol table compiled during the processing of the previous source program and to prepare to process a new program. When this has been done, the program will type the message which calls for the entry of the source program.
    The 1620 FORTRAN Pre-Compiler program deck was made up of four sections, identifiable by sequence number as follows: 00000-00001 Loading routine 00002-00361 Pre-Compiler program 00362-00367 Arithmetic tables 02001-02007 Relocatable subroutine data The relocatable subroutine data consists of a card containing the number of relocatable subroutines included in the program deck, and the following cards contain the names of these subroutines. These cards must be in the proper sequence.
    If they are out of sequence, an error message will be typed and the 1620 will halt. Restore the sequence of these cards (including the two cards from the reader stacker), press the reader start and start keys to continue the operation. General Make-up of Program Tape Tape Data Duplicating the Pre-Compiler Tape The relocatable subroutine cards are punched with the function name starting in column 1 and the sequence number in columns 76 through 80. Subroutine names added to the system must be punched in the same manner.
    The 1620 FORTRAN Pre-Compiler tape consisted of a loading routine which loads the multiply and add tables, and the program which follows. The last seven records are the relocatable subroutine data containing the number and names of the relocatable subroutines included in the program. These records must be exact duplicates of the corresponding records which are included in the 1620 FORTRAN processor tape. Additions to the list of relocatable subroutines in the system must be made to the Pre-Compiler tape in exactly the same form as prescribed for the 1620 FORTRAN processor tape. For the purpose of tape identification, a title and data message have been incorporated in the 1620 FORTRAN Pre-Compiler tape. The first two records of the tape contain the title and data information. After these records have been read into the 1620, the following message will be typed: 1620 FORTRAN PRECOMPILER 11/15/61 Normal processing continues after the message has been typed.
    The FORTRAN Pre-Compiler tape was duplicated and/or modified by the use of the program for duplicating the FORTRAN processor and subroutine tapes, in the manner described for duplicating the processor tape.
    References::
    http://www.bitsavers.org/pdf/ibm/1620/C26-5619-4_1620_Fortran_Mar64.pdf
    https://ibm-1401.info/1401-IBM-Systems-Journal-FORTRAN.html