CADO Systems Technical Information

This article documents the CADO Systems Architecture. Initially developed in 1976 for CADO Business Systems running on CAT machines, it was ported to Contel's Tiger ATS platform in 1983 and later to the VERSYSS hardware in the 1990s.

System Overview[edit]

The CADO architecture is designed to allow multiple users to run business applications in a multitasking environment. The emphasis is on rapid software development and deployment. The primary software development language is CADOL.

It was possible to write Intel 8080-based instructions directly into CADOL code by means of an "escape to ASM" instruction MACH, and return to CADOL with an "escape to CADOL" instruction MACH RETURN. This was rarely done as assembly machine code programming:

Was beyond most CADOL programmers (who were trained for rapid application development)
Suspended multitasking on your 8-user transaction processor.
And an assembly bug could result in the entire machine crashing. (Whereas a bug in CADOL code would only terminate that user's session.)

Assembly-language routines were not portable beyond the Tiger ATS series because the assembly code was incompatible between 8085A machines (CADO 20/IV) and 8086 machines (TIGER ATS). Also the programming in assembly code was done by HEX instructions. In addition, the code ran in the Z-buffer, as did many of the operating system lib 0 programs, so if you were to write in assembly (which was possible if it was hand coded), you needed to code for a specific address base.

Compiled CADOL code runs in a private, memory protected, compartment on the machine. Each user is allowed 1 program to run at a time. From an applications standpoint there are no threads, or shared resources. However the user program can trigger a "background" process by a RELEASE TERMINAL command which free the user process redirecting to the program 0 of the current library. There wasn't shared variables or buffers between these processes.

CADOL[edit]

CADOL is a BASIC-like language which is "compiled" into an intermediate language bytecode (IL). Each CADOL instruction becomes from one or more bytes depending on complexity. For example N5 = 1 becomes two IL bytes, but IF N5 = 15 RESET becomes 5 IL bytes (push 15, test N5, intra-segment goto, reset).

Internally each IL instruction maps to an Assembly language routine in the OS to manipulate the correct registers, or perform I/O.

Originally in CADOL II, programs were limited to 256 IL bytes each. Later in CADOL III, chained program segments were allowed. Thus, at the end of one 256-byte block of code, the next segment would be loaded. Longer, more complex programs can be built in CADOL III. However in CADOS (CADO for PC) the technology goback to the programs limited to 256 bytes.

Many of the other, later, additions to the CADOL language are syntactic sugar over older IL statements. Thus, a FOR loop is simply broken down to an assignment, conditional check, and a pair of GOTO instructions. IF statements that could perform other instructions (i.e. IF N5 = 1 RETURN) were broken down into a negated IF,GOTO pairing.

A CADOL III compiler can produce CADOL II code, if it's written carefully and does not exceed 256 bytes of IL.

It was not uncommon for CADOL programmers to become familiar with the IL instructions themselves. Many program fixes were distributed as patches to the IL code and the operating system came with a utility for patching programs.

Libraries[edit]

CADOL programs are stored in special files called Libraries. CADOL Libraries can contain up to 256 programs in numbered slots.

Calling other programs can be done through the LOAD instruction, which causes an immediate branch to the other program. Or the GOSUB instruction which places a return address onto a call stack, and runs the other program until a RETURN instruction is reached whereupon the caller resumes running.

CADO/Contel/VERSYSS distributed a library of system routines which could be addressed with a GOSUB instruction to a negative program number. So GOSUB -100 will call program 100 in the system library instead of program 100 in the current library. The system routines reside on library 0 (system library) so we can program system routines and keep on library 0 for general use.

Calling between libraries (other than a system library) is difficult and required a system call to perform it. So typically, a library will contain an entire functional application (Payroll, Patient History) along with a reserved block of "utility" programs for that library. These "utility" programs are often standardized within a programming team or a project. For example, programs 1-50 might be reserved for "variable initilization", "date conversion routines", or "sort setup".

Since each CADO/Contel/VERSYSS location was run as a separate office, they were rarely standardized between applications.

Terminal[edit]

CADOL programs assume a standard output device. This device is based (loosely) on a VT100-type terminal (actually the Micro-bee).

Each cell on an 80x24 terminal contains two types of information: a display character, and an attribute. Display characters are 7-bit ASCII characters. A status line (the 25th line) could also be overwritten with messages if the programmer was familiar with ESC-code sequences. It normally contain status values such as the system clock, Etc.

Attributes marked regions of the screen as protected, unprotected, dim, bold, or blinking. When a CLEAR instruction is processed, all characters in unprotected fields on the screen are removed but the attributes remain behind. If a RESET instruction is processed all characters and attributes are removed.

CADO terminals had two special keys that were treated as exceptions if they were pressed while the system was waiting for input:

ESCAPE—Will cause Program 0 of the current library to load. This can be trapped for a special behavior (i.e. to force the user to finish the current task) but that generally isn't done.

CANCEL—Will cause the current program to restart at Segment 0, IL byte 0.

Additionally, there is an ESCAPE and a CANCEL instruction.

Screen layouts can be designed by programming through a series of ATT and DISPLAY instructions, or using an external program called a mask editor. The masks can then be loaded onto a blank screen via a system routine.

Buffers and Memory[edit]

User memory is private, protected by the OS. Accessing memory outside of the assigned area causes a memory fault for that user. Memory space is fixed and global, with the exception of being able to temporarily allocate an 8k track buffer (only on later Tiger models). Each user's memory footprint is 8k including variables, buffers and call stack space.

Each user of the system has available:

26 6-byte integer registers, labeled N, N1 to N25.
9 Alpha registers.
- A, B, and C of 40 bytes each
- A1, A2, B1, B3, C1, C2 of 20 bytes each
The alpha registers are arranged in A, A1, A2, B, B1, B2, C, C1, C2 order. If a register overflows, it will be continued into the next register. Thus, there is room for 240 bytes of alpha storage in the A register as long as you didn't use the other 8.
A special-purpose 20 byte alpha register called KEY for file I/O.
A special-purpose 6 bytes numeric register called rec also for file I/O.
5 256-byte Buffers: R, Z, X, Y, W
- The R buffer is where records are read into by READ, READ REC, and READ KEY statements. Also the records can be updated from the R buffer by WRITE BACK .
- The Z buffer was a general-purpose buffer, but was often overwritten by system-level functions. The MERGE command, which was used in combination with a FETCH command to create sort lists of records "on the fly" used the Z buffer. Also the Z buffer is often used as workspace by the system routines.
- The X and Y buffers are general-purpose buffers.
- The W buffer is typically where records are written from by the WRITE, WRITE REC and WRITE KEY instructions.

Calling conventions for subroutines and other programs generally means placing the arguments in low numbered registers (N,N1-N5, A, A1) and making the call. Well behaved programs will document which registers will be used so that the programmer can re-load them after the call if necessary.

Strings[edit]

String values in CADOL are stored with the high-bit on for the length of the string, and then the high bit off on the final character to designate the end of string. Thus "Hello, World" becomes (in hex):

C8 E5 EC EC EF AC C0 D7 EF F2 EC '44'

This is done to save space as there's no need for a trailing Null character.

Record Structure[edit]

Records are keyed by an up-to-20 character alphabetic key. The record structure isn't externally defined for the file (as with an SQL data base) or in a header (as with a C struct). Alpha and numeric fields are lumped together and accessed by skipping fields you aren't interested in:

   READ KEY 1 100    # Read a record
   INIT RP           # Initializes Buffer R Pointer
   INIT RP2          # Initializes Buffer R Page Pointer
   SKIP R(A)4        # Skip 4 alphabetic fields
   SKIP R(12)        # Skip 12 additional bytes
   N4 = R(2)         # Move two bytes to N4
   SKIP R(-6)        # Skip back 6 bytes
   MOVE (4) R TO W   # Move four bytes to W Buffer

Files and disk I/O[edit]

Disk storage on CADO systems is arranged in a series of nested containers. The Device represents a single disk drive. A Volume is a contiguous area on a Device where all files are contained. A Device can have multiple Volumes. Within a Volume, file and library names must be unique. Allocation for files and libraries is done when they are created, must be contiguous, and cannot be expanded once created.

This creates a major problem on systems with large files that are tight on space. If a file spans 20 tracks and is full, to allocate an additional track there must be 21 contiguous tracks free on the disk. If there are not, the system must be backed up, files deleted, a new file allocated, records copied, the original file removed, and then the rest of the system restored from tape, floppy diskette (8-inch) or pertec platter.

Files on CADO systems are one of three types:

Text files. These are rarely used, and usually only for word-processing applications.
Sequential files.
Hashed files.

Hashed and sequential files are fixed sized. The entire extent of the file is reserved when the file is created. The extent is calculated based on the number of records, the length of the key for the record, and the average size of the records in the file. Some adjustment to the record size during declaration (usually reducing it) can be done to avoid wasted space at the end of a track.

On 20/IV, 20/VIII and CAT Systems, for programming purposes, files are not named, they are numbered. Normally a fileset is opened which consists of nine files. Once the proper fileset is opened, a program would move on to read and write those files in known positions (e.g. an employee file as file 6, invoice file as file 7, options file as file 9, etc.). By convention, one file was usually reserved for usage as a sort file. Which specific file number depended upon the vertical market application (such as using file 7 for sorting for the utility billing system sold in the Pacific Northwest). File zero was always considered a system file, and could be used for specific configuration records as long as the first byte of the record did not overlay an existing system type (for example: a screen mask=21 in the first byte). It also could be set up to open a file zero that was specific to a given filemap (e.g. one could set up 10 companies all with their own tables and just switch the file zero to open the next company).

On TIGER ATS Systems, up to 20 files can be opened at one time by any user.

Record locking is achieved through the LOCK and UNLOCK statements. To avoid deadlocking and keep lock management simple, only one record can be locked by any user at one time. Attempting to lock a second record results in an error.

Track format[edit]

Each file is a collection of 8192 tracks, divided into 32 256-byte sectors. Some of the sectors in each track are designated as key sectors, some as data sectors.

When a record is written, the key is hashed to determine which track it belongs to. That track is read and (if possible) the key is written into a key sector, and the data is written into a data sector. If the key will not fit (the key sectors are full) or the data will not fit (the data sectors are full), then it is written to the next available track. As a consequence, deleted records are simply marked as deleted on the track, but the space is left allocated. The file must be compressed to removed deleted data or re-hashed to another file to removed deleted keys.

Sequential files are identical to hashed files, except that the hashing algorithm is disabled so each record is written to the first track and overflows as necessary.

Structured Query Language[edit]

"Just Ask" is the name of the English language structured query language used with the Cado file system. Just Ask has Create, Read, Update, Delete, Sorting, Grouping and conditional selection functionality.

The database definitions are created and stored independently of the actual hashed or sequential data files.

References[edit]

Kent, Allen. Encyclopedia of Microcomputers, CRC Press, ISBN 0824727037.

External links[edit]

99 Bottles of Beer as done in CADOL II

This article "CADO Systems Technical Information" is from Wikipedia. The list of its authors can be seen in its historical. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.