Molecular 18 Software Development

A typical Molecular 18 software development kit for LOS comprised:

Programmers normally prepared their coding sheets at their desk. When you were ready to try out your code, you found an available terminal in the computer room and used the OP utility to load it in six-digit octal words. Beginners would first write all the octal machine code onto the coding sheets but after a little practice this became counter-productive except occasionally, when constructing subroutine control words for example. With just the two registers, page addressing, a modest instruction set and the adoption of octal notation everyone quickly became expert at assembling machine code on the fly at the terminal, especially as the OP utility echoed back the assembler decode as you typed.

No matter how carefully you checked your code, there was always a fair chance it would crash first time. So you always warned anyone else on the machine before you ran a test, waited two or three seconds so they could save their work to disc, then let it rip. Whilst your test ran you could use the OP utility to examine or indeed amend any memory location. Thanks to page addressing you could easily find your code and data and watch what was happening. If your test crashed you could inspect the debris through the control panel. Any subsequent amendments needed to coding sheets would be clearly marked with an asterisk in the margin, to be rubbed out after loading.

By the 1990's I often worked remotely, logging-on through an intermediate Epson QX10 using a 300bps modem connection to load whole new programs directly onto users' live systems. This would only be done by prior arrangement after everyone had gone home; when the time came to run the new code it could be a little nerve-racking knowing that any crash could not be dealt with until the next morning.

Completed coding sheets were stored in Foolscap Lever Arch files in Overlay Module sequence, with record layouts and any other overview information at the front. A complete set of documentation for one client could run to five hefty volumes, which we would carry with us on site visits.

The LOS Programmers’ Manual

A reconstruction of the first edition (October 1977) of the LOS Programmers’ Manual, with some later additions from LOS Bulletins as dated.



Optional Extras

On-line Security (Immediate back-up of all disc updates)

Sort Utility (A disc file sort using a combination of the Quicksort and Bubblesort algorithms)

LOS Source Code Extracts

All discs used by an installation carry a loadable copy of LOS in a reserved area. Executing the five-step Bootstrap code (manually pre-loaded at core address 00/0100) instructs the Drive 70 Disc Controller to read the 128-word Boot Sector 000000 from its exchangeable disc into core starting at address 00/0000. Execution then loops (i.e. waits) at 00/0104 until the instruction at 00/0104 is overwritten by the Boot Sector.

Throughout normal operation of LOS the five-step bootstrap is retained at 00/0100, enabling a quick reboot from the control panel should this become necessary. In the original Molecular 18 MK 1 the bootstrap was twelve steps located at 7/1600, where it proved particularly vulnerable to being wiped out by program bugs (such as calling Clear Block of Core with an incorrect length parameter). Moving the bootstrap to 00/0100 meant it survived most software crashes. Furthermore, it minimised the number of control panel switch flicks required to reload the bootstrap when necessary. Anyone who had to talk or be talked over the phone through the process of loading the bootstrap flick by flick appreciated the relative robustness and brevity of the LOS bootstrap.

The following are downloadable PDF files of the original hand written coding sheets, opening in a new window.

The Boot Sector
This sector is read from disc into the first 128 words of memory by the Bootstrap procedure, replacing the bootstrap's loop at 00/0104 with a jump backwards to wait until the disc drive's Done flag indicates the entire sector transfer is complete. If all continues to go well the code within the now resident Boot Sector reads the 95-sector raw LOS code from disc into 00/0200 to 13/1777 and jumps to the "Initiator" at 06/0000 within the now resident raw LOS, using the values stored within the Boot Sector to locate the required components. Subsequently, the Initiator will refer back to this sector to locate the installation's Configuration Table and any installation recovery data.

The "raw" LOS code as at Version 92 (February 1979)

Page 00 (Zero Page)
Bootstrap, resident Constants, Initiator support tables and templates.
Page 01
Resident Library routines, Interrupt Handler.
Page 02
Resident Library routines, Mains Off handler, Task 0 (System task), Device Interrupt Service table, Command routine.
Page 03
Printer Service templates, On-line Security routines, Resident Library routines.
Page 04
Resident Library routines, Printer Control Program.
Page 05
Initiator support routines and templates.
Page 06
Initiator, DRI tape punch utility, Recovery routine, Disc Service templates.
Page 07
Resident ISAM routines, Printer Service templates, Resident system text.
Page 10
OP utility Decode routine, Initiator support routines and templates.
Page 11
Start-up Intercept routine, Stand-alone OP utility as at LOS Version 88 (August 1978).
Page 12
Resident Spooling routines, resident File Handling routines, resident Disc Access support routines.
Page 13
Resident Input/Output Library routines, resident File Handling support routines, Task Scheduler.

The Initiator (at 06/0000) converts the raw LOS into a functioning operating system by reading the installation's configuration table to create the required task partitions, device drivers and any associated workspace. It then executes any recovery copying requested by the control panel switch settings. Next it opens all active file tables, loads resident overlays, reads the system control record, launches all tasks and survives thereafter as Task 0, the resident System Task at 02/0600.

Workspace for device drivers, printer buffers, file tables etc. is obtained (by calling the resident Getmain routine JSBR IZ 1704) from the Free Core Table in the Configuration Table, plus the table at 10/1600 of unused memory within LOS.

If disc drives are ready and no recovery copying is required, a reboot and initiation is accomplished in under one second.

Configuration Table
This template is adapted at each installation to define the available peripherals, allocate the available memory and locate the System Catalogue.
System Control Record
This template sets out the installation's dynamic data LOS needs to retain across re-boots. Applications may add their own control data to the System Control Record, which is permanently "cached" at 00/0477 to 00/1177 in Zero Page and is thus directly accessible to all tasks. This data is likely to include File Status Blocks, latest Serial Numbers, Control Balances, Stock Balances, VAT rates and so forth. When any such control data is updated the record must be committed to disc by JSBR IZ 1667 Stow System Control Record. As this is properly the last in any uninterruptible sequence of committals to disc, stowing the Control Record may be considered similar to making a UNIX sync system call (though in practice LOS commits each individual disc write to disc before resuming the calling task).
Task Control Areas
This is the area reserved for system use in the topmost column of each task partition (in a modern Object Orientated implementation this would be the private and protected data of the Task object).
System Overlay Module 001
13 sectors comprising system utilities LIST, PMAP, ZERO, READ, R, OP, HALT and CDL. The OP utility relocates itself in the task buffer areas (3200- to 3677-) thus enabling any overlay module to be amended at its runtime offset within the task's overlay area (0000- to 3177-).
System Overlay Module 005
1 sector implementing Copy Sectors. Loads into 3000- to 3177-.
System Overlay Module 006
4 sectors implementing Disc Security. Loads into 2000- to 2777-. Calls the Copy Sectors overlay (see above) and uses 0000- to 1777- as the 1K transfer buffer.
System Overlay Module 011
This module is "fine tuned" at each installation to ensure various system utilities respond appropriately.  This Includes Line-up Command parameters for each print queue, the table of file names for the SE utility and entry points for the Disc Security programs.
Overlay Module 012
5 sectors implementing the System Enquiry utility.
Overlay Module 013
5 sectors comprising system utilities FLAG, KICK, DAY, DATE and RP (Reprint document).
Overlay Module 025
An optional system module (written in 1987) to implement the Sort utility.
System Overlay Module 037
Implements the MEND utility within the On-line Security option.
Overlay Module: Electronic Interface
 An optional system module (written in 1983) to implement "Dynamic Data Exchange" between the Molecular 18 computer and compatible terminal emulation software on a microcomputer or PC.