TS
The TimeSharing system software is the basic operating system of
the ORDINATOR. It supports
as much as eight simultaneous CP/M 2.2 sessions, thus fulfilling the
original goal of the ORDINATOR as a multi-user computer system.
History
Work on TS started 1984/09/15 with the creation of the TS.GLB file containing
global declarations and the TSSCH.ASM file containing the process scheduler.
Before that, we had already experimented with a rudimentary two-user BASIC
system but that was very much a prototype system, as it was hard-coded
for two processes and didn't contain any form of relinquishing the processor;
when neither process had anything to do they were just madly switching the
CPU between them. The TS system contained a real scheduler with several
process queues.
At the time, we already had a single-user CP/M system for the ORDINATOR
and didn't want to lose those facilities; therefore TS
had to support CP/M programs. We chose to use the standard CP/M BDOS,
thus committing TS to the role of a kind of multiplexed BIOS (we were
at the time unaware of the multi-user MP/M system and probably wouldn't
have used it anyway).
Initially we
used a static assignment of drive letters and character devices to processes,
but this was later made customizable with the SET command. The same
command can also be used to change the CP/M memory size, but it
doesn't take effect until the next warm boot of the user's CP/M session.
A historical document from 1985/02/27 shows statistics for the TS sources.
This version of TS was called "24K TS" because that was the size of the
CP/M systems it supported; at that time the total amount of system RAM
was only 64K, allowing for two simultaneous sessions. The statistics included the following line counts:
| File name |
File lines |
File contents |
| TS.GLB | 603 | global declarations |
| TS.ASM | 146 | system loader |
| TSBLK.ASM | 798 | block device support |
| TSCHR.ASM | 772 | character device support |
| TSDEV.ASM | 1103 | generic device support |
| TSDSK.ASM | 936 | disk device support |
| TSENT.ASM | 671 | system entry code |
| TSMEM.ASM | 194 | memory management |
| TSSCH.ASM | 254 | process scheduler |
| TSSYS.ASM | 1150 | system call handler |
| TSTIM.ASM | 210 | timer handler |
| TSVAR.ASM | 84 | variables |
This is a total of 6921 lines of source code; the total number of source
lines processed by the assembler is 12348 (the TS.GLB file is
included in all TS*.ASM files except for TS.ASM). The total assembly time
was 15:20, which amounts to about 13.4 lines per second.
The result of assembly and linking was a TS.SYS file of
of 8320 bytes, just over 8KB. Another 5KB of data space was required,
according to written notes on the document, totaling in a system
memory usage of 4 segments (16KB).
The above statistics were gathered as a reference point because
intrusive changes were being planned at the time.
These changes would allow TS to take advantage
of the new 128K memory board that had brought the total system memory
to 192K. The changes actually happened over the next six months
and culminated in TS release 31/08/85 which was used for a long time.
It used a default CP/M size
of 48K, but this could be changed with the SET SIZE command.
The changes included giving TS its own link layout; previously
it had been sharing the user's link layout in segments D-F.
A working document from the period shows the following layout:
| 0-1 | DIAMOND |
| 2-5 | VARS |
| 6-7 | VIDEO0 |
| 8-9 | VIDEO1 |
| A | DMA (floppy) |
| B | COPY (scratch) |
| C | USER |
| D-F | TS (code) |
This layout allowed for 16K of disk cache. The same working
document shows TSSYS.ASM grown to 1622 lines and
a new TSBIO.ASM module of 558 lines; the block
I/O changes were apparently extensive. New modules TSLOW.ASM
(low memory) and TSUSR.ASM (user visible) are also
mentioned, and the login: prompt was also introduced then.
In the summer of 1987, the total amount of RAM was expanded
to 384K, giving us much more space for the disk cache. To take
advantage of this, the disk cache was exported from the
system link layout. The disk cache was also enhanced to handle
non-512 byte sectors and ALIEN support was finally added to TS.
During 1989, LAN client support was added to TS
while the LAN server program was being developed.
This allowed us to move the TS_SYS volume
to the DISKSERVER hard disk, thus freeing up one
of our floppy drives.
After these additions, the TS sources totaled about 12000 lines;
it had in fact become impossible to keep the complete source
and the generated .OBJ files on a single floppy because
they simply wouldn't fit. A workaround using a second floppy
containing no sources was used temporarily until
the LAN client/server system was working.
In 1990, some small TS enhancements were made (IOBYTE,
timer guards) but nothing big happened anymore and the
system was essentially considered finished.
Development of the DISKLESS hardware and CHAOS software
would eventually have resulted in the replacement of TS,
after having served as a bootstrap environment, but
this was never finished.
Structure
As TS is a big program, it had to be carefully structured.
This sometimes included refactoring so that modules would
remain conceptually sound and not too unwieldy in size.
The module chart below shows the structure as of early 1986.
TS module hierarchy chart (from the book "THE ORDINATOR PROJECT")
BIOS
The BIOS module accepts all system calls from user programs
and routes them to the various internal modules. This requires
switching from user to system link layout, which accounts for
a sizable portion of the processor time spent on character I/O.
LOGIN and
CONSOLE
The LOGIN module implements the login: prompt.
The user does not type his name (TS has no explicit concept of user identity)
but the name of the disk he wishes to work on. A CP/M session will then
be started where the A: drive is connected to that disk.
The CONSOLE sub-module displays the names of the
disks that are currently inserted in the disk drives;
if a disk is requested for I/O a message stating this is also displayed.
PROCES
The PROCES (process) module manages the creation and
destruction of processes. Although user processes will
always run CP/M, internal processes may run the console
display or handle login: prompts.
SCHEDULER
The SCHEDULER module manages the scheduling of the
single Z80 CPU among the processes that want to use it.
The scheduler uses three
process queues: the usr queue, the sys queue and
the slp queue. This was modeled somewhat on the UNIX process
system and uses the same synchronization primitives,
sleep and wakeup, with the rendezvous points
being arbitrary 16-bit integers called a wait channels
that are by convention chosen to be the addresses of data structures
relevant to the synchronization
TIMER
The TIMER module drives the system timer hardware. The hardware
is programmed to supply a 10 Hz interrupt which is used
to kick the scheduler; the real-time clock and profiling facilities
are also handled here.
MEMORY
The MEMORY module manages memory allocation. It supports allocation
and deallocation of 4K segments without any partitioning and is thus
fairly simple.
VIRTUAL ->
REAL
The VIRTUAL -> REAL module manages the mapping of the
virtual CP/M devices (disk drives A: to D:
and character devices CON: to LST:) to the
actual disk and character devices. This includes ensuring that
at most one process uses a non-PIPE character device
and tracking the W/E
(Write Enabled) status of the disks,
which for technical reasons can only be given to
at most one CP/M session at a time, whereas W/E release
can happen only during CP/M session warm boots.
DISK CACHE
The DISK CACHE module manages the disk cache. This was
initially simple but became complex when
ALIEN support was added and the cache buffers were exported from the system link layout. The disk cache will typically use about 100K from the
available 384K of system RAM.
DISK MANAGEMENT & SUPPORT
The DISK MANAGEMENT & SUPPORT module manages the translation
from disk I/O to drive I/O, which changes when floppy disks are
inserted or removed. If a disk is not presently available,
the CONSOLE module will display a request message.
KARAKTER SUPPORT
The KARAKTER SUPPORT (character support) module contains support
routines for character lists and manages the translation from
device-independent codes to device-dependent codes (this is
mostly clear-screen as we had little use for other codes).
KARAKTER DRIVERS and
DISK DRIVERS
The DRIVERS modules perform the low-level work of actually
driving the hardware for the serial ports, video displays,
keyboard controller and floppy controller. The video driver
is complicated somewhat by the need for multiple video modes
(normally 25x80 but also 30x64 for SEDN, possibly memory-mapped)
and efficient scrolling
(which means minimizing the amount of data copied). The floppy
controller driver has to queue the I/O requests and decide
when to switch drives; this complicates it somewhat also.
The serial port and keyboard controller drivers are comparatively simple.
NETWERK DRIVER
The NETWERK DRIVER (network driver) module, which was planned
but did not yet exist when the chart was drawn, handles
the LAN network. It handler the Host side of the
network server protocol;
this requires a fair amount of bookkeeping
and timing.
DEBUG & PANIC
The DEBUG & PANIC module handles diagnostic output to
the serial console port and keeps DIAMOND synchronized so that
it can be used to debug TS. It also handles the display
of fatal error messages.
References
The TS system is described in more detail on pages 29-34 of the book "THE ORDINATOR PROJECT".