SDOS_Applications_Programmers_Guide SDOS Applications Programmers Guide

SDOS_Applications_Programmers_Guide SDOS_Applications_Programmers_Guide

User Manual: SDOS_Applications_Programmers_Guide

Open the PDF directly: View PDF .
Page Count: 172

Download
Open PDF In Browser	View PDF

S DOS
APPLICATION PROGRAMMERS' GUIDE

TABLE OF CONTENTS

INTRODUCTION

1.2

SECTION I: DEVICE-DEPENDENT I/O
DEVICE-INDEPENDENT I/O .

1
1

SECTION II: DEVICE DRIVERS
DEVICE DRIVER CHARACTERISTICS
DISK FILE DRIVER . • • .
DISK DEVICE DRIVER . • .
VIRTUAL TERMINAL DRIVER
OPEN & CREATE .
CLOSE • • . . .
RENAME & DELETE
READA & WRITEA
READB . . .
VTCONTROL . . . .
CC: POSITION . .
CC:DUMPBUFFERS
CC:ECHO .
CC:NOECHO
CC:W'U\P •
CC:NOWRAP
CC:IDLES
CC:TABS .
CC:SETACTBLOCK
CC:CLRINPUT . •
CC:CLROUTPUT
CC:SETREADTIMEOUT
CC:SETPROFILE . •
CC:ALTERPROFILE .
CC:WRITEEDITLINE
CC:SETFIELDSIZE
CC:SETPARAMS
CC:ACTIVATIONCK
CC:SETBAUDRATE
CC:COLORING .
CC:BACKGROUND
CC:KILLPROOF
CC:KILLENABLE
CC:SETEXCEPTIONS
CC:SETOUTPUTTIMEOUT
VTSTATUS • .
SC:GETPOS
SC:GETCOL
SC:GETEOF
SC:GETTYPE
SC:GETPARAMS
SC:GETPROFILE
SC:GETPROFILENAME
SC:GETPROFILEALTERATION

5
5
6

14
15
15
15
16
16
16
18
18
18
18
18
18
18
19
19
19
19
20
20
21
22
23
23
24
24
25
26
26
26
26
26
27
27
27
27
27
27
27
27
28

Software Dynamics

SC:GETFREECOUNT . .
SC:GETDA'rACOUNT . .
SC:GETOUTPUTTIMEOUT
SC:GETBAUDRATE
SC:GETTABS
SC: GETIDLES . •
SC:GETWRAP
SC:GETCOLORING
SC:GETBACKGROUND
SC:GETACTCOL
SC:ATTENTIONCK
SC: STATUSCK . .
CONTROL CHARACTERS
SWITCHES . . • . .
SDOS/MT SUPPORT
MULTI-USER CONTROL FUNCTIONS
MULTI-USER STATUS FUNCTIONS
THE CLOCK: DEVICE DRIVER

28
28
28
28
28
28
28
28
28
29
29
29

SECTION III: SYSCALLS
CONCEPTS
SYSCALL FORMAT

39
39
40

SECTION IV: ERROR HANDLING

SECTION V: SYSCALLS - IMPLEMENTATION
IMPLEMENTATION
SYSCALL:OPEN .
SYSCALL:CREATE
SYSCALL:CLOSE
SYSCALL:RENAME
SYSCALL:DELETE
SYSCALL:LOAD .
SYSCALL:CHAIN
SYSCALL:CREATELOG
SYSCALL:CLOSELOG .
SYSCALL:DISKDEFAULT
SYSCALL:READA
SYSCALL:READB
SYSCALL:WRITEA
SYSCALL:WRITEB
SYSCALL:CONTROL
CC:POSITION .
CC:DUMPBUFFERS
SYSCALL:STATUS .
SYSCALL:WAITDONE .
SYSCALL:EXIT . . .
SYSCALL:ERROREXIT
SYSCALL:SETERROR .
SYSCALL:GETERROR .
SYSCALL:DISPERROR
SYSCALL:KILLPROOF
SYSCALL:KILLENABLE
SYSCALL:DEBUG

46
46

35
36
36
37
38

47
48
49
50
51

52
54
55
57
58
59

61
63
64
65

66
67

68
70
71

72
74
75
76
77

78
79
Software Dynamics

SYSCALL:ATTNCHECK
SYSCALL:ISCONSOLE
SYSCALL:INTERLOCK
SYSCALL:DELAY
SYSCALL:GETSERIALNUMBER
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
WRITING AND DEBUGGING USER ASSEMBLY PROGRAMS
MEMORY MAP
. . . . . . .
SDOS LOADER FORMATS . . .
SDOS LOAD RECORD FORMATS
ENCRYPTED OBJECT FILES
SDOS DISK FILE STRUCTURE
LOGICAL SECTOR NUMBERS (LSN)
CLUSTERS (LCN)
DISK FILE STRUCTURE . .
SDOS FILE STRUCTURE . .
DIRECTORY.SYS STRUCTURE
THE BOOT.SYS FILE
SERIALNUMBER.SYS
SDOS.SYS . . . •
DISKMAP.SYS . . .
ERRORMSGS.SYS FORMAT
BUILDING A TURN-KEY APPLICATION SYSTEM

80
81
82
84
85

90
90
91
93
93
97
98

99
100
102
105
107
113
116
117
118

120
121

Software Dynamics

NOTICE
This manual describes Software Oynamics Operating System (SOOS)
Version 1.1.
Software Oynamics has carefully checked the
information given in this manual, and it is believed to be
entirely reliable. However, no responsibility is assumed for
inaccuracies.
So reserves
notice.

the

right to

change

the

specifications

without

**********************************************************************

** This manual

**
**

describes software which is a proprietary product
SO software is licensed for use on a
single copy per computer basis, and is covered by U.S copyright
laws. Unless a written exception is obtained from SO, the software must be used only on the single computer whose unique,
SDassigned serial number matches that for which the software was
purchased. Copying the software for any purpose other than
archival storage, or use of the software on other than the assigned serial numbered CPU is strictly prohibited.
SD assumes
no liability regarding the use of the software.
Certain software programs and data files are delivered for use
in an encrypted format. The content of such programs and data
are considered to be a trade secret of SD. Attempts or success at breaking the encryption, publication of the results of
such attempts or successes, or copying, storage or use of such a
file in clear text form will be treated as theft of a trade secret, and prosecuted as such.
POSSESSION OR USE OF THIS MANUAL OR THE SOFTWARE IT DESCRIBES
CONSTITUTES AGREEMEN'1' BY THE USER TO THESE TERMS.

** of Software Dynamics (SO).

**
**
**
**
**

**
**

**
**
**

**
**

**
**
**

**
**

**
**
**********************************************************************

This manual and the software it
property of Software Dynamics.

1.1

describes

are

the

copyrighted

SDOS APPLICATION PROGRAMMERS' GUIDE
INTRODUCTION
This manual gives detailed information needed by programmers
building programs to operate under SDOS 1.1. The reader should be
familiar with SDOS concepts; the SDOS User's Guide provides the
appropriate background.
This document presumes some familiarity on the part of the reader
with
assembly language coding for M6800, M6801 and M6809
microprocessors. This knowledge is needed to understand fully the
implications of the SDOS System Call (SYSCALL) interface and the
rules about error propagation. Practical use of SDOS does not
generally require assembly assembly language programming, as most
programming is done in SD BASIC, which provides statements for
performing SDOS System Calls.
This document covers three main areas:
SDOS SYSCALL structure and assembly language interface
Device Independent
descriptions

I/O

Concepts

SDOS File System Structure

1.2

and

device

specific

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION I: DEVICE-INDEPENDENT I/O
DEVICE-INDEPENDENT I/O
SDOS allows user programs to view all disk files and I/O devices
as being fundamentally the same, i.e., if one can perform an
operation on a device of type x (say, LPT:), one can generally
perform that same operation on a different device of type y.
Since disk files and devices are treated essentially identical,
we will use file sometimes to mean device.
In this section, a conceptual model of how files/devices should
act is presented (later sections describe in detail the system
calls used to implement this model). SDOS is designed in such a
way that disk files conform
to this model very closely;
exceptions will be noted later. Real devices such as line
printers, CRT's, Digital-to-Analog converters, etc., are made to
emulate this model as closely as possible via a device driver
routine in the I/O package; the degree of closeness depends
entirely on this driver. In many cases, it is not practical or
appropriate for a device to match the desired model; this means
that there are device-dependent (actually, driver-dependent)
limitations on this device independence.
SDOS implements files for the purpose of storing and retrieving
data. A file is assumed to consist of a sequential set of 8 bit
data bytes, with the first byte being numbered zero, the second
being number 1, the nth being numbered n-l.
Each file has a
size, which is equal to the number of bytes of data stored in the
file. The data in a file can be read or written sequentially in
variable-size blocks. If new data needs to be added to the end of
a file, the file can be automatically extended. Commands exist to
allow a file to be positioned to a specified byte position in
preparation for a later read or write operation, thus providing
random access. Data can be read or written in pure binary, or in
ASCII (text) format.
A device is (usually) a physical piece of hardware capable of
retrieving and storing data, converting data to/from printed
form, etc.
(some devices, such as the CLOCK:, are almost purely
software). In many cases a device is treated as a file by SDOS.
Some devices can actually store many separate data files (such as
a disk device).
User programs communicate with files via mechanisms called "I/O
channels". A channel remembers which file is being manipulated,
and where in the file that the next data transfer should take
place. Each user can have several I/O channels; typical SDOS
systems allow eight I/O channels per user. I/O channels for a
user are given numbers 3 to 255 maximum.
Virtually all operations on a file must be performed
in
conjunction with an I/O channel.
An initial connection is
established between a user-program specified I/O channel and a
particular file by use of a SYSCALL:OPEN (or SYSCALL:CREATE).
COPYRIGHT (C) 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION I: DEVICE-INDEPENDENT I/O
All further operations on that file must specify the operation
desired, and the I/O channel number associated with a file. Note
that a particular file may be open on several I/O channels, thus
causing interactions between what appear to be independent
operations. The association between a channel and a file is
broken with a SYSCALL:CLOSE operation~ a channel on which this
operation is the most recently executed valid operation is said
to be CLOSED. No operations except OPEN or CREATE are valid on a
closed I/O channel.
The I/O channel has associated with it several pieces of
information: whether
that channel is open or closed~ the
particular device driver which is responsible for that file~
information selecting which file on that device is to be used~
data selecting a position within that file; and a column count
(next print position on a real or simulated printing device).
When a file is first opened, the position is reset to zero
(beginning of the file). Each read or write operation on an I/O
channel advances the position for that channel by the amount of
data read/written.
An End Of File condition is said to have
occurred whenever the file position on a particular channel is
equal or larger than the file size (in bytes). Note that two I/O
channels open to the same file are not necessarily positioned to
the same place within that file.
A column count is maintained for the purpose of "tabbing" (a text
concept). This column count is zeroed whenever binary data
(non-text) is read or written to a file, and adjusted to reflect
the position along an imaginary typewriter line whenever textual
data is copied to or from a file.
Operations prformed on files are done via SDOS System Calls
(SYSCALLs).
SYSCALLs specify an operation, a Write Buffer
(containing data going to a file or to SDOS) , a Reply Buffer
(where data or status from SDOS is returned), a channel number
and/or operation subcode, and a reply length (RPLEN).

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION I: DEVICE-INDEPENDENT I/O
Operations defined on files include, but are not limited to:
OPEN,
CREATE,
CLOSE,
DELETE,
RENAME,
READA,
READB,
WRITEB, CONTROL, STATUS, POSITION, GETEOF, GETCOLCNT

WRITEA,

Other operations are device-driver specific.
OPEN is intended to associate an I/O channel with a file (device)
that already
exists,
for the purpose of reading
(or
updating) data in that file. Data-input only devices such as
paper tape readers must be OPENed in order to read data.
All devices can be OPENed so that the device type is easily
read without knowing the kind of device being OPENed.
CREATE is intended to associate a file or device with an I/O
channel which is to be used whenever an entirely new stream
of data is to be written or stored.
In particular, when a
new disk file is needed, or data sent to an output-only
device (such as a line printer) a CREATE should
be
performed.
Some devices, like CRT's, which are both input
and output, can be either OPENed or CREATEd.
CLOSE is used to break the association between a file and an I/O
channel, and to cause the driver for the device on which
that file resides to finish any operations on that file.
DELETE is used to delete (disk)
files from devices that store
multiple named files.
Devices cannot be deleted.
Once a
file is deleted, it cannot be OPENed and its contents are
permanently lost.
RENAME is used to change the name of a disk file, and is illegal
when directed specifically at a device.
READA and WRITEA are used to read and write ASCII (textual) data.
This is used to read data from consoles,
print on line
printers, etc.
If a file has no more room for new data
written,
then the file is automatically expanded. A channel
number must be given to select the desired file.
READB and WRITEB are used to read and write binary data to and
from devices (data stored in a form convenient for the
computer).
An I/O channel number is required to select the
desired file.
Some devices,
like
Digital
to Analog
converters, can only perform Write Binary.
CONTROL operations are used to cause device-specific operations
that do not fit into the above types of operations. Typical
control operations are GETTYP (get device type),
POSITION,
DUMP BUFFERS, etc.
STATUS operations are used to read device or file specific data.
Typical status data is DEVICE TYPE, FILESIZE, EOF flag and
COLCNT.
COPYRIGHT (Cl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION I: DEVICE-INDEPENDENT I/O
POSITION is used to change the place in the file that the next
read or write will start transferring data to or from.
POSITION affects an I/O channel, not the file itself, so
several I/O channels may be positioned to different points
in the same file.
A file can be positioned anywhere past
the last data byte; this is used to expand a file. Although
POSITION operations can be performed independently of read
or write operations, it is generally more efficient to
perform both in the same step; t.o allow this, an "implied
position"
operation
can be added to read and write
operations.
GETEOF is used to determine if the position of a particular file
is at or past the file size (i.e., there is no more data to
read) .
GETCOLCNT is used to read back the simulated print head position
of an ASCII text file (or an actual print head position for
a line printer, etc.). This is useful when a tabular
display is desired. Like the file position, this value is
I/O channel dependent.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
DEVICE DRIVER CHARACTERISTICS
This section describes the actual characteristics of the device
drivers, and how operations on these drivers differ from an
"ideal" device (as described under DEVICE-INDEPENDENT I/O).
These characteristics are observable directly by the assembly
language programmer via "Syscalls". Many features of the device
drivers may be masked by a high level language such as BASIC; to
use these features, an escape to assembly language may be
required.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
DISK File Driver
Disk files under SDOS implement virtually all aspects of general
file handling as described under Device-Independent I/O. This
section details exactly the operations implemented by the SDOS
Disk File Driver.
An SDOS disk file can physically contain as few as zero data
bytes, and as many as the remaining free space after an
SDOSDISKINIT.
SDOS keeps track of disk file sizes accurate to
the byte.
Apparent file size may be much larger than the
actually allocated disk space; such a file is said to be
I'sparse'l.

Disk files may be allocated "dense"ly or "sparse"ly. A dense
file is one in which data clusters are allocated for each data
byte whose position is less than the file size. A sparse file
may have a position (with a smaller value than the file size) for
which no data cluster is allocated (data read from this area of
the file appears as zeroes).
An OPEN is used to open a disk file (that must already exist) for
reading and/or update.
If the file does not exist, an error will
occur. A CREATE will CREATE a new disk file which will supersede
the old version of the file when the new file is closed. The new
file will contain zero data bytes after creation.
A new file
cannot be created if the old file is write protected, or a new
file by that name is being created.

Any OPEN or CREATE that specifies a filename that does not
contain an explicit device identifier will be automatically
assumed to be a disk file on the default disk (DISK:). Also, any
filename that is prefixed by a disk device name, and does not
consist solely of the device name is assumed to be the name of a
disk file on the specified disk.
For the form of disk file names, see the section on DEVICE and
DISK FILE NAMES.
Disk file names may include a parenthesized
integer; this integer is used by CREATE to' allocate enough disk
space at file creation time to contain the number of data bytes
specified by the integer. This has two advantages:
first,
it
decreases the amount of time needed to allocate the space to the
file (it is cheaper to allocate all at once than to allocate
several little pieces when SDOS discovers it needs them) and it
increases the probability the allocation of the file on the disk
is contiguous, which decreases random access time to the file. No
error is given if there is not enough disk space to satisfy the
request. OPEN will parse but ignore the size.
If CREATE is used to make a new disk file, and there is an old
file by the same name, the old file must not be delete or write
protected or an error will occur and the new file will not be
created (nor will the channel be opened).
Also, no file by that
name may be CREATEd simUltaneously (i.e., in psuedo-BASIC,
COPYRIGHT (Cl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CREATE #l,"X"
CREATE #2,~X"
will result in an error). Otherwise, the new file is created,
and the channel is opened. As long as the newly created file is
still open on the channel on which it was created,
that new file
is in the state of "being CREATEd". If an old file with the same
name does exist, an OPEN SYSCALL executed after the CREATE,
looking for the same file, will open the old file.
If the system
crashes before the new file is closed, the old file will be
unaffected in any way.
Even after the new file is closed,
channels still open to the old file will not notice any
difference. When the last channel OPEN to the old file is closed,
the space for the old file is returned to free disk space.
Example:
TIME

OPERATION
OPEN #1, "ABC"
CREATE #2, "ABC"
OPEN #3, "ABC"
CLOSE #2, "ABC"

OPEN #4, "ABC"

CLOSE in, #3

I
2

ACTION
Opens o'ld ABC
CREATEs a replacement
Opens old ABC
Marks old verson of ABC
as deleted
Opens file generated at
time 2
Deletes old ABC

CLOSEing a disk file causes changes to the file size, protection,
and other characteristics to be updated on the disk.
IF THE
SYSTEM CRASHES WHILE THE FILE IS OPEN,
THESE CHANGES ARE LOST
(NOT RECORDED IN THE DIRECTORY). If the disk file is newly
created, and is not replacing another by the same name, closing
will make its name appear in the directory.
If the file is newly
created, and it is a replacement for a file that already exists
(i.e., one by the same name), then the new file will replace the
old in the directory, and the disk space allocated to the old
file will be returned to free space as soon as no other I/O
channels remain open to the ol(~ version of the file.
Disk space
allocated to a file beyond the file size will be returned to the
free disk space pool when a file is closed.
RENAME is used to change the name of a disk file.
RENAMEing a
disk file to its own name is legal, and can speed up later OPENs
of that file since a rename causes the file name to be re-hashed
into the directory.
Refer to hash-lookup description of files.
A disk file cannot be renamed if it is write protected, or a file
by that name already exists, or a new file by that name is being
created.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
DELETE is used to free the space being used by a disk file and
remove the filename from the directory. A file cannot be deleted
if it is delete or write protected, or if a new version of the
file is being created.
READA performs exactly as specified by SYSCALL:READA. READAing
through a large, sparse portion of a file may take an excessive
amount of time due to the automatic suppression of all the zero
bytes found in the sparse area. WRITEA, WRITEB, and READB match
the SYSCALLs exactly. If an error occurs during a read or write,
the file position may not be advanced properly.
CONTROL operations available on disk files are the following:
CC:POSITION
Used to set file position before a read or write operation.
See also SYSCALL:WRITEx and SYSCALL:READx.
CC:DUMPBUFFERS
Forces all data related to the file back to the disk media,
so it is recorded permanently in case of a later crash.
CC:SETFILEDATE
Sets the creation/update date of the file. The date supplied
must be in the same format as returned by a SYSCALL:READB to
the CLOCK: device. Note that the file date is automatically
updated whenever a WRITE or CC:SETFILESIZE operation is
applied to a file.
CC:SETFILEPROT
Sets the file protection byte to the byte supplied. See
DIRECTORY.SYS for structure of file protection byte. If the
BACKUP protection bit is set, it will be cleared if any
RENAME, CC:SETFILESIZE, or WRITE operation occurs. If the
DELETE protection bit is set, the operations RENAME, DELETE,
WRITE and CC:SETFILESIZE will not be allowed.
CC:SETFILESIZE
Sets the file size to the current file position.
This
operation can be used to extend a file (the extension will
be sparse until written) or to truncate a file (data written
beyond the file position given by the file size will become
inaccessible, and data clusters that were allocated beyond
that point will be returned to the pool of free clusters
when the file is closed).
CC:POSITIONTOEND
Sets the file position equal to the file size; has the same
effect as as a CC:POSITION applied to the result of an
SC:GETFILESIZE.
Generally used when extending a file is
desired.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
STATUSes obtainable from a disk file are:
SC:GETPOS
Read position of file.
SC:GETCOL
Get file
column number.
This value is zeroed by a
CC:POSITION or READB/WRITEB and adjusted as data bytes are
read or written in ASCII mode. The disk file driver advances
the column count by
one
for
any visible character
read/written; decrements by one if ASCII:BS is encountered;
zeros the column count if ASCII:CR is encountered; advances
the column count to the next multiple of 8 if ASCII:HT is
found; and leaves the column count alone for all other
codes. The value of the column count at a particular point
in a file thus depends on the last operation of a file; it
is intended only for use with sequential ASCII reads and
writes.
SC:GETEOF
Returns EOF hit flag. EOF is set if positioned at or past
file size. EOF also set when last byte of file is read or
overwritten, or file is extended. EOF is reset when file is
positioned with a positioning value less than the file size.
SC:GETTYFE
Returns device type of DVTYF.FILE.
See SDOSUSERDEFS.ASM.
All devices (drivers) are able to return a device type.
SC:GETFILESIZE
Returns the position of the last data byte written to the
file, plus 1. If file has no data written in it, returns
zero.
SC:GETPARAMS
Returns data about the file, such as
and the cluster size.

sector

size in bytes,

SC:GETFILEDATE
Returns the creation/update date of the file in the standard
system date format (same format as a SYSCALL:READB would
return from the CLOCK:). device.
SC:GETFILEPROT
Returns the protection byte currently associated with the
file. See DIRECTORY.SYS description for format of protection
byte.

Software Dynamics

SDOS APPLICATION PRuGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
No other status is obtainable from a disk file.
SDOS will allocate data clusters to a file automatically whenever
a write request to a non-allocated part of a file occurs (it does
not allocate from the current end of file up to the point of the
write; it simply leaves that part of the file sparse). A cluster
allocated in a formerly sparse part of a file is automatically
zeroed to preserve the "zero" property of the part not modified.
SDOS attempts to allocate data clusters contiguously (with
respect to Logical Cluster Numbers) to minimize scattering of the
file over a disk and to minimize sequential processing time.
If
absolutely contiguous allocation is not possible, SDOS allocates
the closest free LCN that starts a
contiguous
block of
BOOT:MIDALLOC free clusters.
The SDOS disk file driver keeps track of OPENed (CREATEd) files
via File Control Blocks. FCBs are in one-to-one correspondence
with open files (not channels), and contain what amounts to a
DIRECTORY.SYS entry.
In particular, the FCB holds the amount of
disk space allocated to a file and its apparent size.
If a file
is extended on one channel, the extension will be apparent
immediately on a different channel on which that file is also
open because of the shared FCB.
Disk sectors are kept in a pool of sectors to minimize disk reads
of fr~quently accessed data. Data written into a file will be
immediately available through another I/O channel on which that
file is open because the (modified) disk sector in the pool is
shared.
Modified sectors in the pool are written back to the
disk as space is required to bring in another disk sector
according to a Least Recently Used discipline. The oldest sector
on the queue will be written back if its disk is free.
These side effects of the FCBs and the disk sector buffer pool
are subtle but desirable because it is appropriate that different
programs be able to share a file and its contents exactly as it
is in any instant in time.
Many disk operating systems do not
provide this exact sharing capability, and consequently make it
hard to build a set of programs that interact through a common
data base.
SDOS optimizes sequential I/O to disk files via "read-ahead".
Whenever data from a particular sector of a disk file is fetched,
SDOS pre-reads the next sector of that disk file into the sector
pool. The read-ahead happens in parallel with processing of data
from the first sector.
This scheme decreases sequential file
processing time, and lowers the cost of reading records that span
sector boundaries to an acceptable level.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
DISK Device Driver
The SDOS disk device driver allows access to the entire cont~nts
of a disk as though it were a single, large file. This facility
is generally only used by utility programs to initialize, check
out, and repair the file structure on a disk, but it may also be
used to squeeze out the last ounce of available disk space, to
cut down access time to a large file,
or to read/write disks
compatible with the drive but intended for other disk operating
systems.
Disk device drivers may also be used to perform operations on the
device itself, such as to dismount a disk.
A disk device driver is OPENed when SDOS is asked to OPEN a file
whose name consists only of a disk name. (Writes to the device
are illegal until a CC:UNLOCKDISK call is made to enable this;
this protects the file structure against damage from casual
programs since they typically don't issue this call.)
A disk device which has been DISMOUNTed recently will have a Map
Algorithm of :0001.
If the disk device is already mounted (i.e.,
has been used for disk file operations), then the map algorithm
will be that given by the BOOT.SYS file on the disk.
The disk device driver treats CREATE calls exactly like an OPEN.
CLOSEing a disk device simply disassociates
number, and otherwise does nothing.

the

I/O

channel

RENAME and DELETE operations directed to a disk device will cause
an error.
READA and READB act as described under SYSCALLs; the contents of
the disk are treated as a single,
large stream of bytes. WRITEA
and WRITEB act as described (once enabled by CC:UNLOCKDISK),
however,
a disk device cannot be "extended" when more space is
needed, so writing off the "end" of the disk device will cause an
End of File error, and the written data will be lost.
Access to sectors may be obtained by positioning a disk device to
a byte position which is a multiple of the sector size for that
disk.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
Disk device drivers support the following CONTROL operations:
CC:POSITION
To position for later reads/writes.
CC:DUMPBUFFERS
This control operation will cause all modified sectors
belonging to the disk to be written back to it. It will
also cause information changed in FCBs of files open on that
disk to be written back. Information in FCBs for newly
created but not yet closed files is NOT written ba~k to the
disk.
This is not a substitute for a DISMOUNT control
operation. No parameters are needed.
CC,UNLOCKDISK
This enables WRITEA and WRITEB to work properly on a disk
device.
If CC,UNLOCKDISK is not issued after OPENing a
disk, and prior to a write, a "disk is software write
protected"
error
will
occur. Requiring this control
operation to write on the disk device prevents accidental
writing to a
disk device.
CLOSEing the disk device
re-enables the write protection. No parameters are needed.
CC:DISMOUNTDISK
This operation is used to make SDOS let go of a disk
entirely so it may be removed from the drive. An implied
DUMPBUFFERS occurs.
If there are any (new or old) disk
files OPEN on that disk, an error will occur and the
dismount
operation
will
not take place (one should
repeatedly issue dismounts until no errors are detected; a
disk I/O fault
on
a dismount will probably require
SDOSDISKVALIDATE to repair the disk). The disk I/O driver
will be called so that it may physically eject the disk or
perform other needed cleanup. A successful dismount also
turns off the FORMAT mode switch in the disk sector I/O
driver. The map algorithm is set to :0001 if the dismount
succeeds.
CC:SETMAPALGORITHM
This allows the 16 bit Map Algorithm for the disk to be
changed.
An implied CC:DUMPBUFFERS occurs first; if there
are any disk files OPEN on that disk, an error will occur.
If any error occurs, the map algorithm will not be changed.
The map algorithm is passed in the WRBUF of the SYSCALL
block.
CC:FORMAT
CC:FORMAT is used to switch into "blind write" mode,
See
Disk I/O
intended for disk formatting purposes.
drivers. This operation may not be available on all disk
devices.

:OPYRIGHT (Cl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
Any other CONTROL code is simply passed by the SDOS Disk Device
Driver to the Disk Sector I/O driver for its use.
STATUS
information
following:

obtainable

from

disk

device

the

SC:GETPOS
As described under SYSCALLs
SC:GETCOL
As described under SYSCALLs
SC:GETEOF
As described under SYSCALLs
SC:GETPARAMS
Returns NBPS
(number of bytes per sector), NSPT (number of
sectors per track),
NTPC (number of tracks per cylinder),
and NCYL (number of cylinders) each as 2 byte values.
See
SDOSUSERDEFS.ASM for details on format of result.
SC:GETFILESIZE
Returns the size of the
disk
in
bytes;
equal
NBPS*NSPT*NTPC*NCYL (the product of the sector size
bytes, and the number of sectors on the disk).

to
in

SC:GETTYPE
Returns DVTYP.DISK
SC:GETLASTBADLSN
Returns the Logical Sector Number of the disk sector which
last caused a Seek, Read or Write error.
The LSN is
returned as 3 bytes; an LSN of :FFFFFF means "no bad LSN".
Executing
SC:GETLASTBADLSN,
CC:DISMOUNT,
or
CC:SETMAPALGORITHM causes the value to be reset "to no bad
LSN".
This STATUS
is intended primarily for use by
SDOSDISKVALIDATE.
SC:GETERRORSTATS
Returns error statistics collected by the disk driver
selected. Such error statistics record counts and disk
controller status after each failed attempt by the driver to
perform a seek, read or write operation, and the the LSN of
the sector involved when the failed attempt last occurred.
Since the disk drivers retry failed attempts, nonzero error
statistics can occur and yet the system will still function
without error; such errors are known as "soft" errors and
are only an indication that some difficulty may be present.
Executing
SC:GETERRORSTATS,
CC:DISMOUNT
or
CC:SETMAPALGORITHM causes the value to be reset "to no bad
LSN". This STATUS is intended primarily meant for display
by the DISMOUNT command.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
VIRTUAL TERMINAL DRIVER
(CONSOLE:, LPT: and Other ASCII-Oriented Serial Devices)
This section describes SDVTIlC, known as the "Virtual Terminal
Driver".
The Virtual Terminal driver is intended to allow an
applications
program
to
operate
with
the
majority of
display-oriented display
units (terminals), without knowing
physical terminal characteristics.
Inasmuch as printer devices
and terminals have a great deal in common., with respect to
output, the secondary intent of the VT driver is to give the
application the same uniform view of printer devices.
This is accomplished by defining a set of display-oriented
operations for an imaginary (virtual) terminal. The application
controls the terminal with this set of operations, giving no
regard to the type of physical terminal which may be ultimately
used. At time of program execution, the operations commanded by
the application are mapped into equivalent operations which the
physical terminal can perform.
In the
event
that an applications programmer desires to
explicitly reference a feature peculiar to a particular terminal,
he may use installation-dependent CONTROL or STATUS calls, or the
binary operations READB and WRITEB to bypass the general nature
of the VT driver. In so doing, however, that program becomes tied
to a particular terminal and is no longer portable to all
terminals serviced by the VT driver.
The VT driver provides keyboard entry,
line input editing, and
text display functions.
For CRTs, the VT driver also provides a
standard method of dealing with cursor positioning, data entry
via fields, and various screen attributes (denoted as "Coloring"
in this document) thus making display-oriented applications
portable over a wide variety of terminals.
For each virtual terminal device, the VT driver presents an
indefinitely long input or output byte stream to the application.
The path of input,
from typist to application, travels through
several territories, before reaching its destination. Keystrokes
are first collected in a type-ahead buffer. When a request for
data is made (via a READA or READB, for instance), characters are
removed from the type-ahead buffer,
in the order received, and
assembled in the input line buffer.
a1aracters are moved from
the type-ahead buffer to the input line buffer,
up to and
including the character which terminates the buffer filling
process. All subsequent data requests are satisfied from this
line buffer, until it has been exhausted; then, the type-ahead
buffer is again referenced.
If the type-ahead buffer is empty,
then input is taken from the keyboard, a keystroke at a time. The
type of the last data request (READA, READB, etc.) determines how
the type-ahead buffer is filled.
If the binary mode has been
selected (the last request was a READB), then all keystrokes are
faithfully stored in the type-ahead buffer. On the other hand,
if the ASCII mode has been selected (the last request was a READA
:OPYRIGHT (C) 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
or CC:ACTIVATIONCK control call), the parity bit is stripped from
all characters; certain control characters are assigned special
meaning (see Control Characters in this section) and are not
stored in the type-ahead buffer. Editing of the input line is
performed at the time of character transfer from the type-ahead
buffer to the input line buffer: if a READA or a CC:ACTIVATIONCK
control call initiated the transfer, then the input line buffer
is filled in ASCII mode and line editing is performed; otherwise,
the data is transparently copied through the input line buffer to
the RDBUF specified by the request. When ASCII mode keystrokes
are being stored in the type-ahead buffer, switch requests, such
as ~A, ~C, ~S, and ~P (to name a few), are serviced immediately,
and are not retained in the type-ahead buffer.
Associated with each virtual terminal device is a "Device Profile
Block". The DPB customizes the terminal to operate with specific
manufacturers'
devices so that standard SDOS operations are
converted to equivalent device-specific operations. This allows
application programs to position cursors, "color" the screen or
screen regions, or update and erase the screen without kL~wing
the specific device type. A system command, SDOSSET, can be used
to change which device profile is in use; some profiles are
"malleable"; i.e.,
changeable, so even devices with properties
not handled by standard DPBs in a system can be accommodated.
There are also special control calls to allow an application to
select or modify particular profiles.
A

terminal

may

I'CONSOLE:",

"PORTl:",

OPENed

"PORT2: " ,

CREATEd, using the device
etc.;

printer

name

"LPT: " ,

"LINEPRINTER:", etc. Doing an OPEN or CREATE sets the ASCII
activation set to only, sets the tabs to 8, 16, 24 .•.. up
to 132, performs CC:ECHO and CC:KILLENABLE control calls, and
sets the background color to "black" (see CC:BACKGROUND). CREATEs
to non-ready devices are aborted with a "Device Not Ready" or
"Printer Not Ready", depending on whether the device was a
console or printer, respectively; this prevents applications from
outputting data to un-ready devices in a way which is convenient
to test. A terminal/printer may be open on several channels
provided that all channels belong to the same task; output
display by the terminal is exactly what would be seen if the I/O
requests had been all directed to one channel in the same order.
CLOSE
disassociates the I/O channel from the driver. For
printers, if part of a line has been printed, the VT driver will
complete the line by effectively WRITEAing ASCII:CR; if a partial
page has been printed,
it will finish the page by effectively
WRITEAing ASCII:FF, thus assuring that each use of a printer
leaves the paper aligned at top of form for the next use. CLOSE
finally does an implied CC:DUMPBUFFERS, and gives an error if the
device times out.
RENAME and DELETE operations are illegal.

Software Dynamics

SDOS APPLICATION PROGRAMNERS' GUIDE
SECTION II: DEVICE DRIVERS
READA and WRITEA are the normal 1/0 modes used with the terminal,
and match the SYSCALL specification.
A
READA causes the
characters to be taken from an input line buffer maintained by
the driver. When the input line is exhausted, and a READA is
issued, the driver processes characters from the type-ahead
buffer, placing regular keystrokes in the input line buffer,
performing editing as directed by control keys. and performing
echoing for the typist's benefit. A'Z read from the type-ahead
buffer will cause an End of File condition to occur. Parity is
stripped, leaving only 7-bit ASCII codes. C~aracters are not
taken from the input line buffer until activation has been
signaled.
READA terminates when an activation character is
encountered, or RDBUF has no room for the next character.
In
the latter case, an "Activation Not in Buffer" error is returned,
along with as much data as RDBUF can hold. READA must be done in
line mode: a non-line mode request for more than zero bytes will
result in an "Illegal Device Operation" error;' READA non-line
mode for zero bytes is accepted for backwards compatibility
reasons to allow change of mode from Binary reads to Ascii reads.
As a general rule, SDOS uses a single character to represent
as a pair. Line feeds are not an acceptable alternative.
When a READB is issued, keystrokes are accumulated in the input
line buffer (and the type-ahead buffer, as necessary), with
neither echoing nor pre-processing of any kind, The exact key
codes generated by the terminal hardware are passed directly to
the application, including the parity bit. READB is terminated
when the reply buffer is filled. WARNING: an unsatisfied READB to
a VT device cannot be aborted; we do not recommend using this.
If the last operation upon the terminal was READA, then most
control keys, including ASCII:ESC and ASCII,RUBOUT cause various
actions to be taken by the VT driver; these keystrokes are not
passed to the application. If READB was last issued, no special
interpretation of any keystroke is made; all keystrokes are
placed
in
the
type-ahead buffer for processing by
the
application. READA and READB perIni t a 0-byte read request for the
purpose
of changing input modes.
See section on Control
Characters for a complete list of the control characters, and
their actions, upon both input and output.

:OPYRIGHT ecl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
WRITEA causes text to be output to the terminal. All characters
are first stripped of the "parity" bit (bit 7), and then
inspected to determine their interpretation. Printing characters
are sent to the device. Tab characters are expanded according to
the tab table assigned to each terminal.
ASCII:CR characters
cause an ASCII:LF and a variable number of idle characters to be
output after them. ASCII:FF (form) characters cause CRT screens
to be cleared, and cause printers to move to top-of-next-page.
Other control characters are generally printed as C , where c is
the keystroke used with the control key. See Table of Control
Characters for a complete list of the control characters, and
their actions, upon both input and output.
A

WRITEB causes the bytes to be sent to the terminal exactly as
specified in the write buffer, including the "parity" bit. No
linefeeds or idles are inserted. The logical column count is
zeroed, and the VT driver assumes it no longer knows the location
of the cursor (the application must issue a CC:POSITION or
perform an implied positioning call before the VT will know where
the cursor is again).

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
The VT driver supports the following control operations:
CC:POSITION
The positioning information is treated as a cursor position
of the form R*256+C, where R is the desired row (0 is the
top row), and C is the desired column (0 is the leftmost
column). Any value which would cause the cursor to position
off the display, will result in an Illegal Device Operation
error, and the cursor will not be moved. Positioning the
cursor of a hardcopy terminal (display depth is zero) or a
printer is not permitted, and will result in an Illegal
Device
Operation
error.
Note
that
SYSCALL:READA,
SYSCALL:READB, SYSCALL:WRITEA and SYSCALL:WRITEB all allow
implied positions in SCBLK: EXT ENS ION, so that a single call
can both position the cursor and do I/O.
CC:DUMPBUFFERS
This is generally a no-op, since the driver dumps characters
to the device as fast as it can; it does check for a device
timeout. No parameters are needed.
CC:ECHO
This enables echo on READA.

No parameters are needed.

CC:NOECHO
This shuts off echo on READA.
CC:WRAP
This enables line wrapping
width.

No parameters are needed.

when

a line exceeds the display

CC:NOWRAP
This disables line wrapping when a line exceeds the display
width: the line is truncated, and the cursor is left on the
same line, following the last character displayed.
CC:IDLES
This sets the number of idles to be transmitted after a
or . The first byte in WRBUF is the idle count (0 is
legal), the second byte in WRBUF is the character after
which the idles are to follow.
If the second byte is not
present, idle trigger defaults to . A character other
than or will cause an "Illegal Device Operation"
error. This information is not changed by OPENs, CREATEs, or
CLOSEs. Note that the current profile must be either
malleable or hardcopy (an option which must be SYSGENed into
the I/O package); otherwise, a Profile Not Malleable error
will be returned.
Caveat: Some terminals will behave differently
than for .

for

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:TABS
This sets tab stops for tab simulation. The WRBUF must hold
a string of bytes, each byte specifying the next tab stop.
Each successive byte must contain a column number larger
than the previous one. When the terminal is first opened,
tab columns are set at every eighth column, up to 132
columns (0 is the first column). Up to 16 tab stops may be
set; if too many are supplied, an "Illegal Device Operation"
error will result.
If the order of the tab stops is
incorrect (not monotonically increasing), an "Illegal Device
Operation" error will be returned, and the old tab settings
will be undisturbed.
Since CONSOLE: devices tend to stay
open for long periods of time, CONSOLE: tab settings have a
tendency to remain in effect long after needed.
CC:SETACTBLOCK
This specifies a non-standard set of activation characters.
The non-standard set is specified with a vector of 128 bits
(arranged in WRBUF as 16 bytes), corresponding to the ASCII
character set. The least significant bit in the first byte
corresponds to character code 00, and the most significant
bit of the 16th byte corresponds to character code :7F.
When a bit
is
set,
the corresponding character is
interpreted as a non-standard activation character; when the
bit is reset, the standard interpretation applies (see the
chart of Control Characters, below). The activation set is
restored to the standard interpretation (all bits reset) by
OPEN and CREATE. When marked as activation characters,
control characters and ASCII:RUBOUT are never echoed, while
printing characters echo only if echo is enabled. Note that
is always an activation character -- marking it as a
non-standard activation character only changes its echoing
characteristics (as a standard activation character,
it
echoes if echo is enabled; as not-standard,
it does not
echo) .
CC:CLRINPUT
This clears the input line and type-ahead buffers. This is
useful when input,
following an abnormal condition,
is
required.
CC:CLROUTPUT
This clears the output buffer.
It is generally useful only
when the output buffer for a device is very big, or the
device is very slow; otherwise, the buffer will empty
quickly anyway.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:SETREADTIMEOUT
This sets a timeout on a subsequent READA or CC:ACTIVATIONCK
control call.
The timed period begins when the subseql1ent
input operation is issued.
When the timed period has
expired, the input operation is terminated with a "Timed
Input Expired" error, and the data input thus far is
returned in the RDBUF supplied by the input operation. The
length of the period is expressed in 60ths of a second, as a
16-bit value. Note that the period
allowed
is only
approximately what is specified, but is guaranteed to be
longer than the value given. The value is found in WRBUF,
and WRLEN must be 2.
CC:SETPROFILE
This selects a new device profile, which includes a function
mapping VT operations to physical terminal operations.
Selection of a profile sets default device width, depth and
output timeouts; it specifies how the device will position
the cursor, clear the screen, erase to end of line, and go
to new lines; it controls how "coloring" is to be displayed,
etc. Such a profile generally represents a particular model
of CRT/printer. The new profile replaces the old profile,
and is retained until changed or the system is re-booted.
Some profiles are malleable and may be somewhat altered to
accomodate devices for which there is no specific profile
(see below). As the malleable profile is a 'template, any
alterations are retained with the device, rather than with
the profile. Selection of a new profile will cause previous
alterations to be lost. WRBUF contains one number, which is
the profile "name". Specification of a profile not sysgenned
into the I/O package will result in a "No such Profile"
error. Wru,EN must be 1. This call is normally only used by
the SDOSSET program. For a list of profile names,
see the
documentation for SDOSSET or the file IOVTDPBS.ASM.
Note that adding a new profile requires changes to
package.

the

I/O

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:ALTERPROFILE
This alters the currently selected profile (see above), if
it is malleable; if it is not, a "Profile Not Malleable"
error is returned. The alterations are confined to defining
a cursor-positioning sequence, an erase to end of line
(EEOL) sequence, and a home and clear screen (CLEAR)
sequence. An "Illegal Device Operation" will be given if
the parameter supplied are unreasonable. Note that the
cursor positioning sequence contains, in place of the row
and column numbers, the offsets to be added to the row and
column numbers supplied by the application; thus, the cursor
positioning sequence could be used, by itself, to position
to location (0,0).
More extensive alteration must be
accomplished by defining a new profile and incorporating it
into a newly-generated system.
WRBUF must contain the following data:
ALTERPROFILE:CPLEN

significant
length
of
cursor
positioning sequence following;
1
byte in range 3 to 4.
If this
length is < 3, then the VT driver
will output '@@'
instead of
a
cursor position.

ALTERPROFILE:CPSEQ

cursor
position sequence, which
includes
the
row
and
column
offsets; 4 bytes

ALTERPROFILE:CPIDLES

number of idles to follow cursor
positioning sequence; 1 byte

ALTERPROFILE:ROWDISP

displacement
into
cursor
positioning sequence of row number;
1 byte

ALTERPROFILE:COLDISP

displacement
into
positioning
sequence
number; 1 byte

cursor
column

ALTERPROFILE:CLLEN

significant
length
of
CLEAR
sequence following; 1 byte in range
o to 4.
If 0, a CLEAR sequence
will be simulated by generating
enough ASCII:LFs to move to the top
of a page if a printer device (page
depth
can
be
changed
by
CC:SETPARAMS).
This is a useful
device if a system has different
size paper forms,
and no forms
control tape.

ALTERPROFILE:CLSEQ

CLEAR sequence; 4 bytes

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
ALTERPROFILE:CLIDLES

number of idles to
sequence; 1 byte

ALTERPROFILE:EEOLLEN

significant length of EEOL sequence
following; 1 byte in range 0 to 4.
If
0,
the
sequence
will be
simulated.

ALTERPROFILE:EEOLSEQ

EEOL sequence; 4 bytes

ALTERPROFILE:EEOLIDLES number of idles
sequence; 1 byte.

CLEAR

EEOL

CC:WRITEEDITLINE
This appends the contents of WRBUF to the end of the input
line buffer as if the typist had entered that data. A
subsequent READA or CC:ACTIVATIONCK control call will cause
the data to be displayed, in the usual fashion,
and the
typist may edit the data until an activation character is
entered. Note that using the CC:NOECHO control call, prior
to invoking CC:WRITEEDITLINE, will inhibit that data from
being displayed at the time of the READA or CC:ACTIVATIONCK
control call. An activation character may be present in
WRBUF, but will prevent the typist from editing characters
prior to the activation character: activation will occur
immediately. If WRLEN is greater than the space available in
the input line buffer, or data follows an activation
character in WRBUF, an Illegal Device Operation error is
returned and no data is transferred to the input line
buffer.
If present,
the syscall block extension contains a cursor
position at which the cursor should be left, after the data
has been echoed by the input operation; otherwise,
the
cursor will be left at the end of the data supplied in
WRBUF.
When a field has been
explicitly
defined
(see the
CC:SETFIELDSIZE control call, below), the I-byte syscall
extension is the column number at which the cursor is to be
placed, at the time of the READA or CC:ACTIVATIONCK control
call; if that column is in the middle of a tab expansion,
the cursor will be positioned following the expanded tab.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:SETFIELDSIZE
This defines an input field for a subsequent READA or
CC:ACTIVATIONCK control call.
WRBUF contains the field
width. The field width must be at least 1 and no greater
than the width of the display. If the field width is 0, or
exceeds the limits of the display, a "Bad Field Width" error
will be returned, and the field definition will not be made.
Unless any of the cursor control keys for moving left,
right,
up,
and down have been
designated
activation
characters, they may be used to position within the defined
field.
When an attempt is made to position the cursor
beyond the boundary of the field, that character is treated
as an activation character and the operation is terminated;
the terminating cursor control character is appended as the
activation character, and the cursor is not moved.
An
SC:GETACTCOL status call may be issued to determine the
exact column of exit.
If any of the cursor control
characters is designated an activation character, then that
character cannot cause a field exit condition, and will
activate immediately upon use.
The field definition terminates upon field exit, or entry of
an activation character.
If the field, at the time of the
input operation, is not contained completely within the
display width,
that input operation will terminate with an
"Bad Field Width" erx-or and the field input mode will be
cancelled.
'CAC
will cancel
any
outstanding
field
definition.
CC: SETPARfu'lS
Sets the width (1 byte) and the depth
(1 byte) of the
display; this overrides the default from the device profile
chosen. Zero depth means that the terminal is not a paging
device and will print AL when given a form feed character.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:ACTIVATIONCK
This is used to enable keyboard input without causing the
program to suspend operation. CC:ACTIVATIONCK returns an
"Activation Received" error if an activation character is in
either the input line buffer or the type-ahead buffer. If no
activation character is present in either buffer, the input
line buffer is filled from the type-ahead buffer, unless
this has already been
done
by
a previous call of
CC:ACTIVATIONCK. A READA issued following an "Activation
Received" error will always return immediately with the data
requested and/or an error appropriate to a READA (If ~C~C
has been seen while the SDOS/MT and KILLPROOF flags are set,
a "Program Killed" error will be returned; otherwise,
~C~C
will result in the program being killed.) *Once
the
CC:ACTIVATIONCK control call has been issued, subsequent I/O
requests (with the exception of CC:ACTIVATIONCK, status
requests, and SYSCALL:READA) will result in an "I/O In
Progress" error. This state is exited by issuing a READA
upon receipt of an
"Activation
Received"
error.
A
CC:SETREADTIMEOUT control call issued prior to the initial
CC:ACTIVATIONCK can be used to limit the time spent in this
state.
When
the
timed
period
expires, the
next
CC:ACTIVATIONCK will return an "Activation Received" error,
and the subsequent READA will return the expected "Timed
Input Expired" error, along with any data received prior to
the expiration.
* See the section on SDOS/MT
applies to this note.

support

for

caveat

that

CC:SETBAUDRATE
This call is used to change the baud rate of a device.
WRBUF contains a 16 bit unsigned integer representing the
exact baud rate desired (rounded to an integer).
An
"Illegal Device Operation" is returned if the baud rate
cannot be changed, or cann0t be changed to the specified
value.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:COLORING
For the purposes of this control call, a "color" is that
which change~ the appearance of text without changing its
meaning or s~ze.
This call supports the myriad available
features dealing with display appearance: these include, but
are not limited to: color, intensity, underscoring, and
blinking. It explicitly does NOT handle characters whose
size is non-standard (i.e., double-width or double-height)
for the device. l6 bits of data, found in WRBUF, specify the
desired display mode for subsequent output: all display
characteristics must be specified by the same control call
at one time.
The mode change is made immediately, and the mode is saved
for later use by the position control call. All characters
output via WRITEA are "colored" according to the last color
selected by this call.
When a position control call is
made, the "zero" coloring is selected (see CC:BACKGROUND,
below), the positioning is performed, and the coloring
selected by CC:COLORING is re-instated.
CC:COLORING does not cause the
cursor to move (some
terminals violate this, due to their design deficiencies).
Two bytes in WRBUF are used to specify the display modes.
The first byte i.s divided as follows:
2 bits for intensity,
1 bit for blink, 1 bit for underscore,
1 bit for reverse
video,
3 bits for (inverted) color (1 bit each for "not
red", "not green", and "not blue"). The second byte contains
3 bits for selecting alternate Roman character sets; the
remaining bits are undefined and must be zero. The default
color of "zero"
(both bytes zero) selects the standard
Roman character set, standard intensity, no reverse video,
no underscore, no blink, and the color white (i.e., the
display mode obtained for virtually all "dumb" CRTs). The
"zero" color is automatically selected by OPEN.
Although this control call is recognized by all systems, its
actual implementation will vary according to the particular
terminals being supported; in the simplest of cases, it will
be implemented as a NOP.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CC:BACKGROUND
A "background" color is the color displayed in
locations which do not contain a character.

all

screen

CC:BACKGROUND selects the default coloring to be used when
the display is cleared, or when cursor positioning is to be
done (see CC:COLORING, above). The required byte of data is
found in WRBUF and is of the same format as for the first
byte of CC:COLORING, above. A black background (hex :07) is
automatically selected by OPEN.
Although this control call is recognized by all systems, its
actual implementation will vary according to the particular
terminals being supported; in the simplest of cases, it will
be implemented as a NOP.
CC:KILLPROOF
This is used to KILLPROOF a specific VT input device. What
that means is that ·C·C and 'D will be rejected with a beep
when they are entered. ·C while killproof clears the
type-ahead buffer.
CC:KILLENABLE
This is used to cancel the effect of a CC:KILLPROOF control
call directed at the same VT input device. Note that
'WSCALL:KILLPROOF is not overridden by this control call.
CC:SETEXCEPTION
This call is used to specify exceptions to VT driver
processing. At this time, the only exception defined is for
SEDIT; and specifies that
fields
also
activate
on
ASCII,RUBOUT at left end of field, and on ·u or 'L at right
end of field.
CC:SETOUTPUTTIMEOUT
This call is used to specify a new value for output timeout
interval, and overrides the default selected by the Device
Profile Block last chosen. It is especially useful with the
VT:MALLPT profile when the printer has a large buffer of its
own, and goes "BUSY" for long periods while it prints. The
interval is specified as a two byte number in WRBUF in 60ths
of a second.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
STATUS OBTAINABLE FROM THE VT DRIVER
Many of the statuses available from the VT driver are simply
images of data specified by Control calls to the driver. This is
for convenience of the SDOSSET program, and allows it to show the
operator the "current" settings of things before modification.
SC:GETPOS
Reads the cursor position in the same form as CC:POSITION.
SC:GETCOL
If the input line buffer is empty, this returns the output
column number; otherwise, this returns the column number
corresponding to the first byte to satisfy the next read.
The column number is the same as used in CC:POSITION. A
REA DB zeroes the column number. Returning the column number
corresponding to the next input character when there is a
partially-read input line makes it possible to distinguish
between "TERSE" command lines and "VERBOSE" command lines;
if the column count is zero when a program gets control,
there must be nothing in the line buffer and so VERBOSE mode
is desired; otherwise,
something is in the line buffer and
so TERSE mode is desired (see COMMAND INTERPRETER).
SC:GETEOF
This returns a non-zero byte if ~Z was seen while in READA
mode, and the input line buffer is empty; otherwise, this
returns a zero byte. End of File status is never set while
in READB mode to a VT device.
Note that the only way to
reset this status is to CLOSE and reOPEN the channel.
SC:GETTYPE
Returns DVTYP.CONSOLE or DVTYP.PRINTER, as appropriate.
SC:GETPARAMS
Returns the width (1 byte) and the depth (1 byte) of the
display.
Zero depth means that the terminal is a hardcopy
device with continuous paper. Printers return paper width
and depth.
SC:GETPROFILE
Returns the current profile "name"
(a one byte number);
suitable for use by the CC:SETPROFILE control call.
SC:GETPROFILENAME
Returns a one
to
16
character
ASCII
text string
corresponding to the numeric
profile "name"
(1 byte)
specified in WRBUF. This call does NOT change the profile
currently selected on the device. Return a "No Such Profile"
error if the profile name specified in WRBUF is not
sysgenned into the I/O package. This call is used to all
SDOSSET produce a human-readable list of DPBs configured
into a system.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
SC:GETPROFILEALTERATION
Returns the current profile alterations in exactly the
format given to CC:ALTERPROFILE.
Gives a "Profile Not
Malleable" error if the profile currently selected is not
malleable (and therefore has no alterations).
SC:GETFREECOUNT
Returns a 16 bit integer specifying how much room is
currently available in the output buffer for a device
(memory-mapped video displays always return "1").
SC:GETDATACOUNT
Returns a 16 bit integer specifying how much data is
currently available in the input ring buffer for this
device.
Can be used to prevent hanging the system when
doing READB.
SC,GETOUTPUTTIMEOUT
Returns the current value of the Output Timeout for this
device, in a form suitable for use with CC:SETOUTPUTTIMEOUT.
SC:GETBAUDRATE
Returns the current baud rate for this device, in exactly
the form required for CC:SETBAUDRATE. Devices which cannot
change baud rates usually return "0".
SC:GETTABS
Returns the current tab settings for this device, in exactly
the form required for CC:TABS.
SC:GETIDLES
Returns the count of idles to follow a Newline sequence, and
the Idle trigger character, in exactly the form required for
CC:IDLES.
SC:GETWRAP
Returns a non-zero byte if Wrapping (see SC:WRAP)
enabled, else return a zero byte (wrapping is disabled).
SC:GETCOLORING
Returns 2 bytes of Coloring
required by CC:COLORING.

information in exactly the form

SC:GETBACKGROUND
Returns 1 byte of Background Coloring information in exactly
the form required by CC:COLORING.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
SC:GETACTCOL
Returns both the column position and the line buffer
displacement at which the last activation character was
entered (the activation character, itself, is placed at the
end of the input line and is obtained via READA or READB).
Note that if echoing is disabled, the returned column
position value will be meaningless.
SC:ATTENTIONCK
This checks for "Operator Requested Attention" status.
If
found, the status is cleared and an "Operator Requested
Attention" error is returned.
SC;STATUSCK
This returns a "Status has Changed" error if the VT device
has had an interesting change of status, which include
receipt of an activation character, receipt of ACA C, a
"Timed Input Expired" error, a "Device Timed Out" error,
etc.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
CONTROL CHARACTERS
This table describes how control characters are treated if they
are NOT marked as activation characters (see CC:SETACTIVATION).
:00

NUL

input:

ignored

output: discarded
input:

:01

toggles
the CAPS LOCK switch,
immediately at the end of the line

echoes

output: prints AA
input:

:02

requests BASIC breakpoint, does not echo

output: prints AB
:03

input:

input and output buffers,
clears the
OUTPUT and DISCARD
resets the FREEZE
AO ) ,
OUTPUT switches (see AS,
resets the
echoes
PAGE
MODE
switch (see Ap ) ,
line,
immediately at the end of the
aborts
the
program i f two AC'S are
ACAC will be
received in
successioni
rejected with a beep i f KILLPROOF is set.

output: prints AC
:04

input:

invokes the debugger immediately, does not
echo; a beep is echoed if no debugger is
available (CNPG:VTDEBUG=0).
Illegal under
SDOS/M'l'.

output: prints AD
input:

:05

causes all input at, and to the right of,
the cursor to be erased from the display
and deleted from the input buffer.

output: erases the remainder of the display
(erase to EOL)
: 06

input:

line

positions cursor at left side (front) of
current input field. Illegal for hardcopy
terminals.

output: prints Ap

~OPYRIGHT

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
input:

:07

causes BASIC to resume execution from the
current breakpoint, does not echo

output: beeps
input:

:08

implements
not echo

the

backspace function,

does

backspace
function.
output: implements
the
Backspace across edge of screen is not
allowed.
:09

-I

input:

positions the cursor
column, when read

output: positions
column
input:

the

cursor

the

tab

the

tab

rejected with beep; see CC:SETFIELDSIZE

output: discarded
input:

:0B

rejected with beep; see CC:SETFIELDSIZE

output: prints -K
input:

: 0C

implements
not echo

the

forespace

function, does

output: causes a PAGE BREAK if the PAGE MODE
switch is set (see -P), homes the cursor,
selects the background color, and clears
the display if depth is not zero, prints
-L if the the depth is zero; for a printer
device, moves paper to the top of form,
such that the next character will be
printed in the first position of the line.
:0D

-M

input:

echoes , causes program activation

output: prints
:0E

-N

input:

passed to
read

the

application,

echoed

when

output: prints -N
:0F

input:

toggles the DISCARD OUTPUT switch (see -Q,
-C), echoes immediately; not functional
while a READA or CC:ACTIVATIONCK control
call is being satisfied

output: prints -0

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS

:10

input:

toggles the PAGE MODE switch (see "0, "C),
echoes immediately at the end of the line

output: prints .p

:11

input:

resumes output suspended due to a PAGE
BREAK (see "P), resets the DISCARD OUTPUT
switch (see "o), resets the FREEZE OUTPUT
switch (see AS), does not echo

output: prints "0

:12

input:

if CRT,
positions cursor to Right end of
current input field;
for hardcopy devices
echoes "R followed by all data
entered since the last activation

output: prints "R
:13

input:

sets

the

FREEZE OUTPUT switch

(see

"0,

·c), echoes immediately

output: prints "S

:14

input:

toggles the BASIC line trace switch,
not echo

does

output: prints "T
: 15

input:

deletes
the character at the current
cursor location, deletes the corresponding
character from the input buffer, does not
echo

output: prints ·U
:16

input:

toggles the BASIC single step switch, does
not echo

output: prints ·V
: 17

input:

for CRTs, causes the last input line to be
retrieved as though the typist had entered
it explicitly, if no other keys have been
typed since the last input.
Illegal for
hardcopy devices.

output: prints

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
:18

input:

clears the input buffer; for hardcopy,
echoes ·X and positions to the
column at
which
input began;
fOe a
terminal, erases, from the display,
the
data entered since the last activation
character, and positions the cursor at the
location where input began; for a terminal
with fields defined, erases the displayed
field contents, and positions the cursor
at the first location of the field

output: prints ·X
input:

:19

passed to
read

the

application,

echoed

when

output: prints ·Y
:lA

input:

causes END OF FILE status to be set,
causes program activation with an END OF
FILE error, echoes i~ediately at the end
of the line

output: prints ·Z
:lB

ESC

input:

causes cursor to be placed at right end of
current input field,
OPERATOR REQUESTED
ATTENTION status to be set, and returns
"Operator Requested Attention" error.

output: prints .[
: lC

input:

passed
read

to the

application,

echoed

when

the application,

echoed

when

application, echoed

when

output: prints .\

olD

input:

passed
read

output: prints .]

olE

input:

passed
read

the

output: prints

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
:IF

input:

passed
read

output: prints
:7F

RUB

input:

the

application,

echoed when

deletes the
character
preceeding the
current cursor location,
deletes
the
corresponding character from the input
buffer, does not echo

output: discarded

NOTE: No control character is passed
explicitly noted.

the

application unless

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
SOFTWARE SWITCHES AFFECTED BY CONTROL CHARACTERS
CAPS LOCK
When set, READA will interpret the lowercase letters a-z as
uppercase letters. 'A toggles the switch.
If a terminal is
stuck in upper case, and the alpha lock key isn't the
problem, someone probably typed 'A by accident.
FREEZE OUTPUT
When set, further output will be suspended until the switch
is reset. On CRTs, 's will be displayed to remind the typist
that the switch has been set. 's sets the switch, 'Q and 'c
reset the switch.
DISCARD OUTPUT
When set, all output will be discarded until either the
switch is reset or a READA/READB is issued. '0 will be
displayed to remind the typist that the switch has been set.
A READA will reset the switch and overwrite the "'0" with "7
A READB will simply reset the switch. '0 toggles the
switch, 'Q and 'c reset the switch.
PAGE MODE & PAGE BREAK
When set, subsequent WRITEA lines will be counted, and when
lines have been output, a Clear screen
request is output, or cursor positioning is attempted, then
a PAGE BREAK will occur, and no more output will occur until
the typist has acknowledged the page break. This gives the
typist a chance to read what is displayed before more output
occurs. On a CRT, a page break will be signalled by 'p being
displayed in the lower right-hand corner of the screen; on
hardcopy
devices,
output
will
simply
cease.
The
acknowledgement can be 'P (which prevents further page
breaks), 'Q (which allows output until the next page break),
or ·C (which prevents further page breaks). On CRTs, a Clear
screen requests causes a page break BEFORE the screen is
cleared, so the text may be read before it disappears; on
hardcopy terminals, the page break occurs AFTER the FORM
character moves the paper to top-of-page,
so individual
sheets of paper may be conveniently printed. All lines
output while in page mode will be truncated to fit within
the current display width, thus ensuring that line wrapping
does not occur so that all lines between page breaks will be
captured on the display.
NOTE: All reminders are displayed in the lower, right corner of
the display.
Reminders will overwrite any characters
already in those locations.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
SDOS/MT SUPPORT
The following control and status functions are included for
complete documentation only. They are subject to change without
notice.
Caveat Emptor I I
MULTIUSER CONTROL FUNCTIONS
CC:SETTIMESHARE
Sets the SDOS/MT flag, which results in different handling
of the line flags and ACAC abort.
If the flag has already
been set, an "SDOS/MT Already Running" error is returned.
RDBUF is filled with system-dependent linkage information
for use by SDOS/MT.
CC:STOPTIMESHARE
Turns off the SDOS/MT flag. SHOULD NOT BE EXECUTED BY USER
PROGRAMS, OR A SYSTEM CRASH WILL RESULT.
CC,WRITEANOWAIT
This defines, for the VT driver, WRBUF as the source of data
for an asynchronous WRITEA of WRLEN bytes. RDBUF contains 3
bytes, the first of which the VT driver will set to zero
when the request is accepted, and set to non-zero when WRLEN
bytes have been written; the remaining two bytes will
contain either an error code, or zero if the operation had
no errors. Note that WRBUF must not be modified until the
request is complete (the first byte of RDBUF becomes
non-zero) .
CC:WRITEBNOWAIT
This defines, for the VT driver, WRBUF as the source of data
for an asynchronous WRITEB of WRLEN bytes. RDBUF contains 3
bytes, the first of which the VT driver will set to zero
when the request is accepted, and set to non-zero when WRLEN
bytes have been written; the remaining two bytes will
contain either an error code, or zero if the operation had
no errors. Note that WRBUF must not be modified until the
request is complete (the first byte of RDBUF becomes
non-zero) .

(el 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
MULTIUSER STATUS FUNCTIONS
SC:GETLINEFLAGSHINT
Returns zero if no line flags have been collected since
the last call to SC:GETLINEFLAGS, otherwise returns
non-zero value. The value returned is only intended as
a hint; the program must call SC:GETLINEFLAGS to get
the true line flags and acknowledge their receipt.
Don't ask why.
SC:GETLINEFLAGS
Exchanges a zero with the line flags, and returns that
byte. If ACAC has been seen while the SDOS/MT and
KILLPROOF flags are set, a "Program Killed" error will
be returned; otherwise, ACAC will result in the program
being killed.
SC:GETTIMESHARE
If it is, an
This checks to see if SDOS/MT is running.
"SDOS/MT Already Running"
error
will be returned;
otherwise, a normal return will be made.
SC:ALLSTATUS
This checks to see if an SC:STATUSCK status call issued
to any VT device would return a "Status Has Changed"
error as a response; if so, a "Status Has Changed"
error is returned. Note that this status call supplies
only a hint.

(el

1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION II: DEVICE DRIVERS
The CLOCK: Device Driver
The CLOCK: device is used to set and read the current time and
date. Since its function is limited, so is its conformance to
the SDOS file concept.
The CLOCK: device can only be OPENed.
CREATE,
RENAME, DELETE,
WRITEA, and CONTROL operations are illegal. CLOSE does nothing
except to disassociate the I/O channel from the driver.
A READA directed to the CLOCK: device returns
bytes in the following form:

string

HH:MM:SS MO/DD/YY
where HH is hours on a 24 hour clock, MM is minutes,
SS is
seconds, MO is the month, DD is the day number, and YY is the
year modulo 100. An ASCII:CR is appended if the READA has line
mode enabled and buffer space permits.
A READB returns 6 bytes exactly in the following form:
T T T MD Y
where T T T is a 24 bit binary value equal to the number of 1/60
second clock ticks since midnight; D is the day, M is the month,
and Y is the year modulo 100, all in BCD.
A WRITEB must write exactly 6 bytes in the format read by READB,
and is used to set the time of day.
The only status
DVTYF.CLOCK.

syscall

accepted

SC:GETTYP,

which returns

Software Dynamics

SOOS APPLICATION PROGRAMMERS' GUIDE
SECTION III: SYSCALLS
SYSCALLS - CONCEPTS
Programs running under SOOS communicate with it via system calls
(SYSCALLs). A SYSCALL is a subroutine call (from the user program
to SOOS) with a parameter block describing the function to be
performed.
This section describes the general philosophy behind the SYSCALLs
and their general format.
It assumes some knowledge of assembly
language.
The most general form of a SYSCALL contains a function code, some
fixed parameters needed by the function, a (pointer to) Write
buffer and a (pointer to) Reply buffer. Essentially, the SYSCALL
causes the specified function to be performed according to the
parameters, using data from the write buffer, and storing a
result in the reply buffer. Many readers will recognize this as
an implementation of
ROBUF:= F(PARAMS, WRBUF)
The purpose of constraining all SYSCALLs to this form is to
simplify the process of transmitting a request from one computer
to another, to facilitate networking of multiple computers.
Conceptually, SYSCALL execution proceeds as follows:
1) The user program issues a SYSCALL.
2) SOOS transmits the function code, the parameters, and the
contents of the WRITE Buffer from the user's computer CQ some
target computer.
3) The target computer processes the SYSCALL and produces a
reply.
4) The reply, along with any error information, is sent back to
the SDOS which sent out the request.
S) SDOS places the reply in the user program's reply buffer.
In a stand-alone system, the target computer
computer are one and the same.

and

the

user's

The primary advantage of this scheme is that by forcing all
SYSGALLS to have a fixed form for transmitting, performing, and
receiving
replys to function requests, the software logic
processing the request can forward it to another computer without
having a lot of function-specific knowledge.
In particular, it
means that the forwarding logic need not be changed even when new
functions are added t.O the list of legal SYSCALLs.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION III: SYSCALLS
Typical SYSCALL functions are: OPEN file, READ byte stream, LOAD
a program, etc. Not all functions require write data (i.e., a
STATUS Syscall needs only the function, some parameter bytes and
a reply buffer); nor do all functions return a result (WASCII
writes a string of ASCII bytes to a file and returns no result).
Some functions have neither write nor reply buffers (i.e., EXIT
to system). Furthermore, many functions have side effects (like
CLOSE I/O channel).
SYSCALL Format:
The following
(SCBLK) .

definitions

give

the

formats of a SYSCALL block

SYSCALL BLOCK DISPLACEMENTS

*
ORG
'"
SCBLK:OPCODE

RMB

SCBLK:WLEN

RMB

SCBLK:PARAMS

RMB

SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF

RMB
RMB
RMB
RMB

2
2
2
2

SCBLK:RDLEN

RMB

SCBLK:DATA

RMB

SCBLK:END

RMB

o
o

Primary SYSCAL Function (Open,
Read, Etc.)
Wait Flag Bit (0=Wait) and SYSCALL
Block Length (0 .. 127)
Parameter Bytes to Opcode (Secondary
Opcode, Channel #)
Pointer to Write Data Buffer
Number of Bytes in Write Data Buffer
Length of Reply (Result of SYSCALL)
Pointer to Read Data Buffer (Where
Result Goes
Ceiling on Size of Reply (Read Data
Buffer)
Other Parameters for SYSCALL; up
to 127-14=113 Bytes
End of SYSCALL Block;
Assert SCBLK:WLEN[1 •. 7]=
SCBLK:END-SCBLK:OPCODE

SCBLK:OPCODE is the desired function, and occupies a single byte.
Legal functions under SDOS 1.0 are shown in table 1.
(Definitions of all values for SYSCALL opcodes and related
information is given in the SDOSIOPKDEFS.ASM listing in the
back of this manual).

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION III: SYSCALLS
SCBLK:WLEN is a single byte with two parts: a Wait flag (the most
significant bit) and a LENgth (2 to 127. measured in bytes)
(the SYSCALL block length). The wait flag is intended to
allow overlapped READ and WRITE operations to files. but is
not implemented in SDOS 1.0. When this bit = 0.
it means
"wait for operation complete before returning control to
user program".
"1"
means
I'don't wait'l.
To retain
compatibility with future releases of SDOS. the user is
advised to leave this bit reset (0).
The LEN field
specifies precisely how long the SYSCALL block is.
Each
opcode requires that this byte have some minimum value, or
the SYSCALL will be aborted. The LEN field is used to
determine how much data must be sent to another computer.
The LEN field can specify more bytes than actually needed by
the SYSCALL without ill effect. but processing the unused
bytes may increase the execution time of the SYSCALL. All
SYSCALLs have at least the SCBLK:OPCODE and SCBLK:WLEN
bytes.
SCBLK:PARAMS are 2 bytes used for sundry purposes as parameters
to the opcode requested. Three cases are of particular
note: first. one of the two parameter bytes is generally
used to hold an I/O channel number on I/O-oriented SYSCALLS.
Second. a parameter byte may contain an opcode extension
byte. as with the STATUS and CONTROL SYSCALLs; the parameter
byte selects which control function is to be performed or
the particular ~iece of status information to read back.
The third case LS some 16 bit number. such as passing an
error code to SDOS via the SETERROR SYSCALL.
In no case may
these two bytes contain a pointer or any other kind of
reference to other data in the memory of the user's
computer; only data values or relative references to data in
the write buffer or the SYSCALL block itself are legal
(because after the SYSCALL has been
sent to another
computer. how could we follow a pointer?) SCBLK:PARAMs need
not be included in the LEN count for SYSCALLS such as
SYSCALL:CLOSE. SYSCALL:EXIT, etc.
SCBLK:WRBUF and SCBLK:WRLEN define the starting address of the
write data buffer. and its length in bytes. SCBLK:WRBUF
contains the address of the first byte of the buffer;
SCBLK:WRLEN contains the number of bytes in the buffer (0 to
65535). Note that SCBLK:WRLEN is the actual number of bytes
to be processed by the SYSCALL, not the allocated size of
the buffer. These parameters are used in SYSCALLs involving
filenames to specify the (device and)
filename desired. or
as
data buffer definitions f~r SYSCALL:WRITEB
(Write
Binary). etc.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION III: SYSCALLS
SCBLK:RDBUF and SCBLK:RDLEN select a buffer address and size in
which a SYSCALL result/reply is returned. The SCBLK:RDLEN
must contain the expected maximum size of the result (in
bytes). SCBLK:RPLEN is set to the actual length of the reply
given, that is, the actual number of reply bytes placed in
the RDBUF.
Many SYSCALLs do not return a result. If the
SYSCALL block includes space for SCBLK:RPLEN, it will be
zerod if no reply is given. If RDBUF overlaps any part of
the SYSCALL block or the WRBUF, the SYSCALL operation is not
well defined. When an error is returned by a syscall, RPLEN
and
RDBUF
contents
are undefined (unless explicitly
specified by description of the particular syscall). In
particular, there is no guarantee that the RDBUF contents
are preserved (even in the presence of an error).
Bytes in the SYSCALL block beyond SCBLK:RDLEN are interpreted in
a manner specific to the particular SYSCALL opcode (like the
SCBLK:PARAMs bytes). Most SYSCALLs do not need or use these
bytes.
SYSCALL is handled in
the manner described under SDOS Error handling. 1~e calling
sequence for SYSCALLS is thus:

An error occurring during execution of a

LDX
JSR
BCS

#SYSCALLBLOCKADDRESS
SYSCALL$
(Equated TO $FB)
OOPS
(Go Process Error Code In Xl

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION IV: ERROR HANDLING
ERROR HANDLING
Error handling is an important part of any programming system.
It allows application programs to continue or effect recovery in
spite of problems encountered. The error handling strategy
outlined here is used throughout most SD software. Facilities to
handle errors in a similar fashion are provided by the SD BASIC
Compiler, so application programs can also support the same
scheme.
Errors detected by SDOS are passed back to the user program for
inspection or handling. Each error which can occur is assigned a
16 bit error code (0 to 65535). Blocks of codes are assigned to
each possible detector of an error (i.e., errors which SDOS
detects have codes from 1000 to 1999, compiled BASIC programs
detect errors 2 to 99, EDIT errors are 200 to 299, etc.).
Each (assembly or SYSCALL) subroutine has two exits: a success
exit (meaning no unexpected/unrecoverable errors occurred) and an
error exit (meaning some error which the subroutine cannot handle
occurred) .
If the success exit is taken, normal processing can continue. If
the error exit is taken, an error code is passed back to the
caller for his inspection. The caller has three options:
1) Process and recover from the error (example:
for "No Such
File" error on an OPEN, a standard default file name might be
OPENed) .
2) Give up; notify the operator of the error and exit.
3) Decide to pass the error back to his caller with an error
indication.
This option is particularly important when the
caller can fail in many ways not understood by the caller
(such as I/O faults).
Processing the error requires explicit checking for each of the
possible error codes of interest (due to the large number of
unexpected errors, an "if it's not this, it must be that" scheme
is not safe; one should ALWAYS check explicitly). Sometimes, data
associated with the error is needed for the processing routine to
continue; in these cases, the original detector of the error must
have saved that data in a place agreed upon by the detector and
the routine attempting recovery. An example is a "recovery"
routine that prints out the Logical Sector Number of a disk
sector on which a read error occurred -- the recovery routine
must know that a GETLASTBADLSN STATUS syscall will retrieve the
LSN desired.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION IV: ERROR HANDLING
"Giving up" is aided by the SDOS SYSCALL:ERROREXIT. The error
code is stored into the SYSCALL block, and the SYSCALL is
executed. SDOS will print a text message corresponding to the
error code, and pass control
to
the command interpreter
(DEFAULTPROGRAM).
The command interpreter can retrieve this
error code, and a DO file can process it via IFERROR statements
(see command interpreter description).
Passing back the error code to the next level of subroutine is
generally done only if the recovery routine does not find an
error code it is willing to handle. This provides an opportunity
for subroutines at successively higher levels to effect recovery.
The subroutine calling convention
handling philosophy is as follows:

JSR
BCS

*
CLC
RTS
ERROROCCURRED
CPX
BEQ
CPX
BEQ

Subroutine
ERROROCCURRED
SUCCESS EXIT

CLC
RTS

(S)

K HERE

(S)

K HERE

implements this error

FLAG "SUCCESS EXIT"
EQU
*
#ERR:-HANDLE1STERROR
#ERR:--

SEC
RTS
HANDLE1STERROR

that

(S)

HERE

(6809 "CMPX" DESTROYS CARRY BIT)
WITH CARRY SET, INDICATING ERROR
EQU

TO RECOVER FROM 1ST ERROR

(OKRTS IN DEFS)

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION IV: ERROR HANDLING
Carry reset on exit means the subroutine completed successfully.
The carry set on exit from a subroutine means "error occurred"
(only for those subroutines which adhere to this convention!);
the X register contains a 16 bit error code.
Note that the
calling subroutine must provide a BCS after the JSR in order to
detect an error. The ERROROCCURRED routine tests the X register
for errors from which it can recover; if the wrong error happens,
no test will match and another RTS (with carry set) will occur,
providing the next higher level subroutine a chance at processing
the error code. In either case, error or not, the contents of
the stack above the return address is untouched. The stack
register itself has the original value of the stack pointer at
the time of the JSR,
so that all higher level routines can be
returned to exactly as normal. Last, notice that the HANDLE ERROR
and the success paths both exjt by clearing the carry (indicating
"success" exit).
SYSCALLs are implemented as suproutine calls and follow the above
convention with one variation.
If an error occurs, SDOS unwinds
the stack until a return address on top of the stack points to a
BCC or BCS. This means that a SYSCALL must be followed by a
BCC/BCS or SDOS will unwind the stack too far, with unpredictable
results.
The unwinding process consists of repeatedly popping
two bytes, and assuming the top of the stack is a return address,
(with obviously bad consequences if this is not true) until an
appropriate return address is found (This scheme was chosen to
minimize the amount of processing an SDOS routine had to do when
it didn't care about errors, and has the side effect of speeding
things up 5 to 10 percent).

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALLS - Implementation
This section details the SYSCALLs implemented in this version of
SDOS. See SDOSUSERDEFS.ASM listing for opcode values.
Errors listed are only common errors,
i.e., ones for which
application programs attempt recovery. Many other (even hardware
specific errors) are possible, but due to the size and changing
nature of the list, are not recorded here.
Table 1 - Syscalls implemented in SDOS 1.1

*
*

SYSCALL$ OPCODE DEFINITIONS
ORG
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB

SYSCALL:OPEN
SYSCALL:CREATE
SYSCALL:CLOSE
SYSCALL:RENAME
SYSCALL:DELETE
SYSCALL:LOAD
SYSCALL:CHAIN
SYSCALL:CREATELOG
SYSCALL:CLOSELOG
SYSCALL:DISKDEFAULT
SYSCALL:READA
SYSCALL:READB
SYSCALL:WRITEA
SYSCALL:WRITEB
SYSCALL:CONTROL
SYSCALL:STATUS
SYSCALL:WAITDONE
SYSCALL:EXIT
SYSCALL:ERROREXIT
SYSCALL:SETERROR
SYSCALL:GETERROR
SYSCALL:DISPERROR

RMB
RMB
RMB
RMB
RMB
RMB
RMB

1
I
1
I
1
1
1

RMB
SYSCALL:KILLPROOF
SYSCALL:KILLENABLE RMB
RMB
SYSCALL:DEBUG
RMB
SYSCALL:ATTNCHECK
RMB
SYSCALL:ISCONSOLE
RMB
SYSCALL:INTERLOCK
SYSCALL:DELAY
RMB
SYSCALL:NOTUSED
RMB
SYSCALL:GETSERIALNUMBER RMB

1
1
1
1
1
1
1
1
1
1
1
1
I
1
I

1
1
I

1
1
1
1
1

Open File
Create a New File
Close a File
Rename a File
Delete a File
Load an Overlay
Chain to a File
Create the Log File
Close the Log File
Select Default Disk Device
Read ASCII Bytes From a File
Read Binary Bytes From a File
Write ASCII Bytes To a File
Write Binary Bytes To a File
Perform a Control Operation
On a File/Device
Read File/Device Status
Wait for I/O on Channel to Complete
Give Control Back to Operating System
Exit to System With Error Code
Report an Error To The System
Read Back the Last Error Code
Display Error Message Corresponding
To Last Error Code
Prevent User Program Being Killed
Allow User Program to be Killed
Call System Debugger
Operator Attention Request Check
Check Channel 0 Input Device = Console:
Perform Interlock functions on objects
Delay for n 1/60ths of a second
Get processor serial number

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:OPEN
This SYSCALL is used to establish an association between
existing file (to be read and/or updated) and an I/O channel.

OPEN SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF

FCB
FCB
FCB
FDB

SCBLK:WRLEN

FDB

SCBLK:RPLEN
SCBLK:RDBUF

RMB
FDB

SCBLK:RDLEN
SCBLK:END

FDB
EQU

SYSCALL:OPEN
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,IGNORED
FILENAMESTRING
POINTS TO FIRST BYTE
FILENAMELENGTH
IN BYTES
2
EXPECTED RETURNED VALUE OF 2
SCANNEDCOUNT
FILENAME CHARACTERS
PROCESSED
2
SIZE OF RDBUF

*
*

The WAIT flag must be zero.
The first parameter byte is the
channel number desired. The second parameter byte is not used.
The Write Buffer (WRBUF) contains the filename (including device
name, etc.) desired, WRLEN contains the number of bytes in the
filename.
The OPEN SYSCALL checks the channel to ensure that it is not open
already.
If not open, the filename is scanned to determine the
selected device (default to DISK: if no device) and a filename on
that device. The number of bytes scanned is returned as a 2 byte
value in the buffer selected by RDBUF; the rest of the bytes in
WRBUF are ignored. Leading blanks on the filename are ignored,
but are included in the scanned count.
(Note: All SYSCALLs that
deal with file or device names return the number of bytes of the
filenam€ scanned as the result.
The entire filename is scanned
even if an error occurs.) The device is searched for the file if
it is a directoried device, and an error issued if not found. If
the device is not a directoried device, the device is simply
opened. The file is positioned so that a subsequent read will
read the zeroth (first) byte of the file.
(Some) possible errors are:
Bad File Name
No Such File
Can't Open, Must Create
No Such Device
Channel Busy

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:C'REATE
This SYSCALL is used to CREATE a new file and establish an
association between an I/O channel number and the new file. It is
also used when a program will do output only to a device (such as
a line printer; the philosophy is that such output is a new
file) .
CREATE SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK,WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB
FDB
FDB
EQU

SYSCALL:CREATE
SCBLK:END-SCBLK:OPCODE
CHANNELNO,IGNORED
FILENAMESTRING
FILENAMELENGTH
2
EXPECTED RETURNED VALUE OF 2
SCANNEDCOUNT
2
SIZE OF SCANNED COUNT

The WAIT flag must be zero. The first parameter byte is the
desired channel number; the second parameter byte is ignored.
WRBUF points to the filename (device name) of the new file.
Like SYSCALL:OPEN,
RDBUF points to a 2 byte area in which the
number of bytes of the filename scanned by SDOS is placed on
completion of the SYSCALL.
If a disk file is specified and there is an old file, the old
file must not write protected or an error will occur and the new
file will not be created (nor will the channel be opened).
Otherwise, the new file is created, and the channel is opened.
If an old file does exist, an OPEN SYSCALL executed after the
CREATE, looking for the same file, will find the old file.
If
the system crashes before the new file is closed, the old file
will be unaffected in any way. Even after the new file is closed,
channels still open to the old file will not notice any
difference. When the last channel to the old file is closed, it
is deleted and the space for the old file is returned to free
disk space. Effectively, a CREATE includes an "implied" delete
of the older version of the file.
The file is positioned so
in byte #0 of the file.

that a write will write its first byte

Possible errors are:
File is Delete Protected
File is Write Protected
No Such Device
Channel is Busy
Bad Filename
File is Being Created

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:CLOSE
The CLOSE SYSCALL is used to break the association between an I/O
channel number and a file.
CLOSE SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK,PARAMS
SCBLK:END

FCB
FCB
FCB
EQU

SYSCALL:CLOSE
SCBLK:END-SCBLK:OPCODE
CHANNELNO,IGNORED

This SYSCALL frees the I/O channel to be opened to another file,
and causes the CLOSE entry point of a device driver to be called.
Action of the driver is driver-dependent.
If the channel was open to a disk file, then changes to the file
size, protection, and other characteristics are updated on the
disk (not before). If the disk file is newly created, and is not
replacing another by the same name, closing will make its name
appear in the directory.
If the file is newly created, and it is
a replacement for a file that already exists (i.e., one by the
same name),
then the new file will replace the old in the
directory, and the disk space allocated to the old file will be
returned to free space as soon as no other I/O channels remain
open to the old version of the file.
possible errors are:
Illegal Channel Number
Channel is Already Closed

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:RENAME
The RENAME Syscall is used to change the name of a file.
The
file must be open on some channel; it must not be a newly created
file, and no file (new or old) having the new name must exist.
RENAME SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB

FDB
FDB
EQU

SYSCALL:RENAME
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,IGNORED
NEWFILENAME
NEWFILENAMELENGTH
2
EXPECTED RETURNED VALUE OF 2
SCANNEDCOUNT
2

The SYSCALL format is identical to that of an
parameters and results are passed the same way.

OPEN

syscall;

This SYSCALL affects nothing except the name of the file.
RENAMEing a disk file to its own name is legal, and can speed up
later OPENs of that file since a rename causes the file name to
be
re-hashed
into
the
directory.
Refer to hash-lookup
description of files.
Possible errors are:
Channel Not Open
Bad File Name
File is Being Created
Can't Rename to a Different Device
File is Delete Protected
File is Write Protected
New File Already Exists

~OPYRIGHT

513

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:DELETE
The DELETE SYSCALL is used to delete a file from a disk device.
DELETE SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRLEN
SCBLK:WRBUF
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB
FDB
FDB
EQU

SYSCALL:DELETE
SCBLK:END-SCBLK:OPCODE
IGNORED, IGNORED
FILENAMEBUFFER
FILENAMESIZE
EXPECTED RETURNED VALUE OF 2
2
REPLYBUFFER
REPLYBUFFERSIZE

The file specified on the specified device is deleted (this
syscall is not legal for devices which do not have directories).
No I/O channel is specified or needed.
If the deletion is
successful, the directory entry is removed so that the file can
no longer be opened.
If the file is open on some I/O channel
when the delete SYSCALL is issued. then the SYSCALL will complete
successfully. but the file will not actually be deleted until the
last channel open to the file is closed (in fact, the file may
actually be allocated more disk space via the other channell).
The reply buffer is loaded with the actual length of the filename
(see SYSCALL:OPEN).
Possible errors are:
No Such File
File is Delete Protected

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:LOAD
The LOAD Syscall is used to load an overlay program segment into
memory, without transferring control.
LOAD SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB
FDB
FDB
EQU

SYSCALL:LOAD
SCBLK:END-SCBLK:OPCODE
IGNORED,IGNORED
FILENAMESTRING
FILENAMELENGTH
2
EXPECTED RETURNED VALUE OF 4
COUNTANDSTART
4
MINIMUM REQUIRED

No channel number need be specified.
The filename specified is opened on a special system channel, and
checked to see if a load format file is given (first byte must be
ASCII US" or Hex :01). If so, the file contents are loaded into
memory as specified by the load records (see LOADER FORMATs).
Scatter loading (loading into non-contiguous parts of memory) is
possible. Upon completion of the loading process, control is
returned to the user, and the file is closed.
The results returned in the reply buffer are 2 bytes of filename
count (the first 2 bytes; see SYSCALL:OPEN) and 2 bytes of start
address (the second 2) as specified by the load records.
Load records which would load on top or above SDOS cause the load
to be aborted.
A load record whose address conflicts with that of the reply
buffer may be damaged; conversely, the reply may be garbled.
Loading into the area used by the stack may cause SDOS to crash.
SDOS does not check for this.
Errors while loading cause the error exit of the
taken.

Syscall

to LOAD a program with a different encryption key

In any case, on completion of the load, the file is closed.
Attempting
illegal.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
possible errors are:
Not a Load File
No Such File
EOF Hit
Checksum Error
Load Record Format Error
Bad Filename
Bad Filename Size

(cl

1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:CHAIN
The CHAIN Syscall is used to load and transfer control to
overlay or program segment.

CHAIN SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB
FDB
FDB
EQU

SYSCALL:CHAIN
SYSCALL:END-SYSCALL:OPCODE
IGNORED,IGNORED
FILENAMESTRING
FILENAMELENGTH
2
EXPECTED RETURNED VALUE OF 4
COUNTANDSTART
MINIMUM REQUIRED
4

CHAIN first closes all I/O channels except channel 0. It then
causes all modified disk sectors in the LRU queue to get written
back to the disk to ensure validity of disk contents, and then
performs exactly the same function as SYSCALL:LOAD.
If an error
occurs, control will return to the caller only if no data has
been loaded into the user space.
The most common causes of this
are the following errors:
Bad File Name
Bad File Name Size
File Not Found
Not a Load File
No Start Address
All other errors will cause an implied SYSCALL:ERROREXIT to be
executed (because of the possibility of the program issuing the
CHAIN being overlayed).
On successful completion of the load, control will be transferred
to the start address of the file.
The stack pointer is set to
the contents of $FC,$FD, minus 1 (see SDOS Memory Map).
Chaining to a program with a different encryption key will
the user space to be zeroed before control is transferred.

cause

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:CREATELOG
There are occasions on which a record of a terminal session would
be very convenient, such as when a purported bug arises, or when
an example is required. This copy can be laboriously constructed
by hand, or it can be made automatically via a CREATELOG syscall.
CREATELOG SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
RMB
FDB
FOB
EQU

SYSCALL:CREATELOG
SCBLK:END-SCBLK:OPCODE
CHANNELNO,IGNORED
FILENAMESTRING
FILENAMELENGTH
2
EXPECTED RETURNED VALUE OF 2
SCANNEDCOUNT
2
SIZE OF SCANNED COUNT

CREATELOG creates a new file (just like the CREATE syscall), but
no channel number is given (SDOS reserves a special, unnumbered,
I/O channel specifically for this purpose).
It returns file name
size information in the same manner as OPEN.
There is no way for a user program to explicitly read or write
data to the log channel; all I/O through the log channel is done
invisibly by SDOS. Essentially, any data written via a Write
ASCII to channel 0 (the control channel) is also copied to the
log file.
Data read via a Read ASCII O~ channel 0 is also
written to the log file.
In this way, a complete copy of console
sessions (carried on through the control channel) is recorded in
the log file for later retrieval. The writes to the log file are
done only when the log file is open (has been created).
STATUS and CONTROL syscalls are re-directed from channel 0 to the
log channel when it is open, so that status information read from
channel 0 may not actually be that of channel 0. All other
channel-oriented syscalls (in particular, Read Binary and Write
Binary) are not affected by the log channel. If the log channel
is not open, it has no effect whatsoever on channel 0 operations.
The log file will not be found in the directory until it is
closed (via CLOSELOG). Like any CREATEd disk file, PROGRAM KILL
('C'C) automatically closes the log file.
This Syscall is used
mainly by SDOSCOMMANDS to implement the LOG and DO commands.
A program can set up a DO file by:
1) Verifying that the DO file exists
channel.
2) CLOSEing channel 0
3) OPENing channel 0 to the DO file
4) CREATELOG on the "CONSOLE:" device

OPENing

some

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
Further input will come from the DO file.
If an error occurs
during step 2 or 3. the program must reOPEN channel 0 to the
CONSOLE: or no further console I/O can occur.
Possible errors are:
Channel Already Open
Illegal File Name
No Disk Space

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:CLOSELOG
This Syscall is used to close the special log
SYSCALL:CREATELOG).

I/O

channel

(see

CLOSELOG SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:CLOSELOG
SCBLK:END-SCBLK:OPCODE

This Syscall performs the same operation as a CLOSE Syscall on
the Log channel.
No channel number or other parameters are
needed.
Possible errors are:
Channel Not Open

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:DISKDEFAULT
This SYSCALL is used to select which disk is default-selected
when a file name with no explicit disk device indentification is
given.

DISKDEFAULT SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF

FCB
FCB
FCB
FDB

SCBLK:WRLEN

FDB

SCBLK:RPLEN
SCBLK:RDBUF

RMB
FDB

SCBLK:RDLEN
SCBLK:END

FOB
EQU

SYSCALL:DISKDEFAULT
SCBLK:END-SCBLK:OPCODE
IGNORED,IGNORED
FILENAMESTRING
POINTS TO FIRST BYTE
FILENAMELENGTH
IN BYTES
EXPECTED RETURNED VALUE OF 2
2
SCANNEDCOUNT
# FILENAME CHARS PROCESSED
SIZE OF RDBUF
2

DISKDEFAULT parses the device name, and ensures that the device
name is a valid disk device name (filenames passed with the
devic0 name are not examined). The specified disk will then be
used whenever a filename with no device
specification is
encountered by a filename SYSCALL.
No channel number is needed.
Data is returned in the same form as an OPEN syscall.
After a successful return, the device name DISK:
default disk.

refers

the

Possible errors are:
Device is Not a Disk

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:READA
This SYSCALL is used to read (ASCII) textual data
The file must be open on some I/O channel.

from

file.

READA SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN

FCB
FCB
FCB

SCBLK:RPLEN

SCBLK:RDBUF

FDB

SCBLK:RDLEN

FDB

SCBLK:END

EQU

FDB

SYSCALL:READA
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,LMFLAG
2
0
(MINIMIZES PROCESSING TIME)
2
ACTUAL NUMBER BYTES READ
READBUFFER
WHERE TO PUT DATA
READBUFSIZE
MAXIMUM NUMBER BYTES TO READ

READA will read the specified number of bytes into the read
buffer from the file open on the specified channel, anu advance
the file position past the number of bytes examined, subject to
the following conditions: the file has enough bytes,
and no
errors occur during the read. Nulls (:00), line feeds (:0A), and
rubouts (:7F) are deleted from the stream of characters read from
the file/device.
Bit 7 of all characters read via SYSCALL:READA is zeroed. Other
characters may be removed from the input stream by the particular
device driver in use.
The column count for this channel is updated for each byte placed
in the read-back buffer, according to the following rule: a
printing character (:20-:7E) causes the column count to be
incremented. CR (:0D) causes the column count to be zeroed. All
other codes leave the count alone. The column count can be read
by a SYSCALL:STATUS call.
If LMFLAG is non-zero, the read proceeds in single line mode. If
a CR (:0D) character is encountered, it will be placed in the
read buffer, and the read will be terminated. LMFLAG=0 prevents
CRs from terminating the read, so the buffer will be filled.
SCBLK:RPLEN is set to the actual number of bytes read, even if an
error (such as End of File) occurs.
The WRBUF is ignored if supplied.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
All data read from channel 0 via a READA is copied (via WRITEA)
to the log file if the log channel has been opened. A READA with
LMFLAG=l directed at channel 0 will be completed from the
CONSOLE: device if a complete line cannot be read because of an
EOF error (this finishes a partial line from a DO file).
The overhead for doing a single-byte SYSCALL:READA is fairly
high; larger buffers will cause this overhead to be divided
between all the bytes transferred. Large buffers can achieve a
40 to 1 speedup over single byte transfers. Such speed ups are
also
typical
for
SYSCALL:WRITEA,
SYSCALL:WRITEB,
and
SYSCALL:READB.
If the SYSCALL block length is 18 bytes or more, then the first
four bytes of the extension hold a file position, and an implied
positioning operation is performed BEFORE the actual read takes
place.
Compared to a CC:POSITION
call
followed
by
a
SYSCALL:READA, a combined position/read operation is considerably
more efficient in a network environment, so it is encouraged.
Similar
efficiencies
accrue
for
combined
position/write
operations.
An EOF hit error will occur:
(1) if not in line mode and the
buffer cannot be filled; (2) if in line mode and no CR character
is encountered before EOF.
end-of-file condition (which
can
be
sensed
via
a
SYSCALL:STATUS) is set whenever a read of the last data byte of
the file occurs.
An

Possible errors are:
Channel Not Open
EOF Hit

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:READB
This SYSCALL is uoed to read binary
must be open on some I/O channel.

data from a file.

The file

READB Syscall Block format
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN

FCB
FCB
FCB
RMB
FDB

SYSCALL:READB
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,IGNORED

SCBLK:RPLEN

RMB

SCBLK:RDBUF

FDB

SCBLK:RDLEN

FDB

SCBLK:END

EQU

2
0

(MINIMIZES PROCESSING TIME)
ACTUAL NUMBER BYTES READ
READBUFFER
WHERE TO PUT DATA
READBUFSIZE
MAXIMUM NUMBER BYTES TO READ

READB will read the specified number of bytes into the read
buffer from the file opened on the specified I/O channel, and
advance the file position by the number of bytes actually read.
In order for the specified buffer to be completely filled,
the
distance between the current file position and the end of the
file must be greater or equal to the buffer size, and no errors
may occur during the read. The data bytes read from the file are
not changed in any way.
SCBLK:RPLEN is set to the actual
(usually equal to the buffer size).
Using a READB SYSCALL
channel to be zeroed.

causes

number

data

bytes read

the column count for the specified

SCBLK:WRBUF is ignored if supplied; however, its length should be
specified as zero to minimize SYSCALL processing time.
EOF error will occur if the read request is not completely
satisfied (i.e., the buffer was not filled).

The overhead for doing single-byte reads is high; long buffers
will distribute this overhead so that the average time per byte
is some 40 times faster than single byte reads.
If the SYSCALL block length is 18 bytes or more, then the first
four bytes of the extension hold a file position, and an implied
positioning operation is performed BEFORE the actual read takes
place.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
Possible errors are:
Channel Not Open
EOF Hit
Disk Read Error
Device Not Ready
Device Timed Out

~OPYRIGHT

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:WRITEA
WRITEA is used to Write ASCII data to a file.
The primary
difference between this and WRITEB is that the column count gets
updated, and certain output editing is done.
WRITEA SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
EQU

SYSCALL:WRITEA
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,IGNORED
WRITEDATABUFFER
NUMBEROFBYTESTOWRITE

The data bytes in the WRITEDATABUFFER are copied to the file open
on the specified I/O channel.
The file position is advanced by
NUMBEROFBYTESTOWRITE. Disk files are extended automatically, if
necessary, to make more room and the file size is changed. The
column count for this I/O channel is changed according tc the
same rules as specified by SYSCALL:READA. The output stream may
be modified by the device driver; a CRT driver will typically add
LF (:0A) and nulls (idle characters) after a CR (:0D) character.
SDOS conventions dictate that LF characters are superflous in the
presence of CR characters. To write a line of text to a file (or
device), terminating it with a CR is sufficient.
An EOF condition will happen if the last data byte of the file is
overwritten, and/or the file was extended in order to accomodate
the write request. An EOF condition on a WRITE to a disk does
not cause an error.
Data written via WRITEAs to channel 0 is also sent (via
to the log channel if the log channel is open.

WRITEAs)

Multi-byte writes are more efficient than single-byte writes.
No read-back buffer is required.
If the SYSCALL block length is 18 bytes or more, then the first
four bytes of the extension hold a file position, and an implied
positioning operation is performed BEFORE the actual read takes
place.
Possible errors are:
Channel Not Open
Disk Space Exhausted (for disk files)
Disk Write Error
Device Timed Out
Device Not Ready

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:WRITEB
The WRITEB SYSCALL is used to write binary data to a file. The
stream of data bytes is copied directly to the file or device
without any change to its content.
WRITEB SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:END

FCB
FCB
FCB
FDB
FDB
EQU

SYSCALL:WRITEB
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER,IGNORED
WRITEDATABUFFER
NUMBEROFBYTESTOWRITE

The data bytes in the specified buffer are copied without change
to the file that is open on the specified I/O channel. The file
position is advanced by NUMBEROFBYTESTOWRITE. If necessary,
a
disk file is extended automatically to make more room, and the
file size is adjusted accordingly. The column count for this
channel is zeroed.
Multi-byte writes are more efficient than single-byte writes.
An EOF condition will happen if the last data byte of the file is
overwritten, and/or the file was extended in order to accomodate
the write request.

No read-back buffer is required.
If the SYSCALL block length is 18 bytes or more, then the first
four bytes of the extension hold a file position, and an implied
positioning operation is performed BEFORE the actual read takes
place.
Possible errors are:
Channel Not Open
Disk Space Exhausted
Illegal Device Operation
(for line-printer-like devices)
Disk Write Error
Device Not Ready

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:CONTROL
This SYSCALL is used to control or modify the operation of a
device/file. The first parameter byte selects the I/O channel
number; the second parameter byte determines the actual operation
performed (rewind, eject, dismount,
etc.)
so this
SYSCALL
actually represents an entire class of operations. A control
operation may be issued only to an I/O channel that is already
OPEN.
If logging
channel 0,
channel.

is active,
and a CONTROL operation is issued for
the control operation is actually applied to the log

CONTROL SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:END

FCB
FCB
FCB
FCB
FDB
FDB
EQU

SYSCALL:CONTROL
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER
CC:controlcode
CONTROLPARAMETERS
NUMBEROFCONTROLBYTES

SDOS divides device control operations into two classes: common,
and device specific.
Common control operations are those
operations for which all devices generally have a capability.
Currently only the following operations fit in the category of
common:
CC:POSITION and CC:DUMPBUFFERS
All other control operations are
documented
with
the
specific
device-specific operations include:
and dismount disk.

device
specific and are
device
driver.
Typical
select echo mode, set tabs,

The format of the CONTROL SYSCALLs varies because different
device operations require different parameters.
In particular,
most CONTROL SYSCALLs do not require a write buffer.
For
specific formats, refer to the device driver descriptions.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
CC:POSITION
CC:POSITION is used to select the next byte of a file to be
read/written. A 4 byte, 2's complement integer is used to select
the byte index into a (disk) file (it can also be used as a
record number, a port number, a screen position, or whatever is
appropriate for the device). The number must be positive (i.e.,
the sign bit must be zero) or an error will result. Following a
CC:POSITION command, further read/writes start from the specified
file position and advance sequentially. A "rewind" is obtained
by specifying a zero for the value of the 4 byte integer.
Setting a file position which is equal or greater than the size
of the (disk) file will cause an EOF condition to occur and cause
an error.
No reply is given for this syscall.
Alphanumeric CRTs are an interesting special case.
It is
standard for SDOS CRT drivers to interpret the positioning
parameter as cursor positioning data.
The
parameter
is
interpreted as 2 bytes of zero,
1 byte to specify the screen row
number (zero being the top screen row) and 1 byte of column
number (zero being the leftmost column). Given R for row and C
for column, the value of the positioning parameter is then
Row*256+Column.
In this way, cursor positioning on screens is
generalized to work for a broad variety of CRT displays.
CC:POSITION SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN

FCB
FCB
FCB
FDB
FDB

SYSCALL:CONTROL
SCBLK: RPLEN-SCBLK: OPCODE
CHANNELNUMBER,CC:POSITION
POSITIONDATA

POSITIONDATA

RMB

NEED FILE POSITION

For CRTs, POSI'l'IONDATA has the following form:
POSITIONDATA
SCREENROW
SCREENCOL

FCB
RMB
RMB

0,0
1
1

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
CC:DUMPBUFFERS
CC:DUMPBUFFERS is used to force an I/O device to dump any buffers
it may still have filled. CC:DUMPBUFFERS is particularly useful
in transaction oriented programs which need to force all disk
file changes back to the disk. No parameters are required;
operation is device specific.
CC:DUMPBUFFERS Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS

,COPYRIGHT (Cl 1978

FCB
FCB
FCB

SYSCALL:CONTROL
SCBLK:WRBUF-SCBLK:OPCODE
CHANNELNUMBER,CC:DUMPBUFFERS

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:STATUS
The STATUS Syscall is used to read file or device-dependent
descriptive data about that file or device (as opposed to reading
data from the file or device itself). This syscall is really an
entire group of operations; a parameter byte
selects the
device-specific data to read. A STATUS Syscall must reference an
open I/O channel. Like READA and READB, the data is read back
into the reply buffer.
If a STATUS syscall is issued for channel 0, and logging is
active, the status read back will be that of the log channel, not
channel 0.
STATUS SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN

FCB
FCB
FCB
FDB
FDB
FDB
FDB
FDB

SYSCALL:STATUS
SYSCALL:END-SYSCALL:OPCODE
CHANNELNO,SC:statuscode
IGNORED
IGNORED
CHANGED
STATUSBUFFER
STATUSCODEDEPENDENTLENGTH

There are two classes of STATUS requests: those standard across
all devices, and those specific to the particular device type.
The following status information is obtainable from most devices:
SC:GETPOS
SC:GETCOL
SC:GETEOF
SC:GETFILESIZE
SC:GETTYP
SC:GETPARAMS
All other status-reading operations are device specific and are
detailed under the specific device drivers.
SC:GETPOS is used to read the current position in a file, i.e.,
if one executes a CC:POSITION command, an SC:GETPOS will
read back the same value as the positioning value given for
the CC:POSITION.
SC:GETPOS always reads back four data
bytes (the interpretation of these bytes is up to the device
driver) •
SC:GETCOL reads back the print position of a simulated print head
on a particular I/O channel (see READA, WRITEA syscalls). 0
means

"no characters printed on this line.

Only

one

data

byte is returned.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SC:GETEOF returns a single-byte flag indicating whether the I/O
channel has positioned, read or written past the last data
byte in the file.
A non-zero returned byte indicates past
or at end of file; zero means more data can be read from the
file before the end of file is encountered.
SC:GETFILESIZE returns the size of the file (in bytes). The size
is returned as a four byte integer, appropriate for use in a
positioning command (this is convenient for appending data
to the end of a file).
This is normally only implemented on
disk files.
SC:GETTYP returns a single-byte device type code, which places a
device into one of the following classes: FILE, DISK, TAPE,
DIRECTORIED TAPE, CONSOLE, LINEPRINTER, SERIALOUT, SERIALIN,
PARALELLOUT,
PARALELLIN, DUMMY. Other device types may be
added as needed.
SC:GETPARAMS reads device class-specific parameters. To know
what kind of data to expect for a reply, the program must
first determine the
device
type
(using
SC:GETTYP).
Currently defined device-specific parameters are:
Disk FILE:
DVDAT:NSPC
DVDAT:NBPS

Number of Sectors Per Cluster
Sector Size in Bytes

The maximum file size may be computed as:
(NBPS*NSPC/2-1)*NBPS*NSPC
DISK Device:
DVDAT:NBPS
DVDAT:NSPT
DVDAT:NTPC
DVDAT:NCYL

Number
Number
Number
Number

of
of
of
of

Bytes Per Sector
Sectors Per Track
Tracks Per Cylinder
Cylinders

CONSOLE:
DVDAT:WIDTH
DVDAT:DEPTH

In Characters
Screen or Page Depth in Lines, or
o If Continuous Form Paper

PRINTER:
DVDAT:WIDTH
DVDAT:DEPTH

In Characters
Page Depth in Lines

Software Dynamics

SDOS APPLICATION PROGRfu~MERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:WAITDONE
This system call is used to wait for an operation initiated
I/O channel to complete.

This SYSCALL and the
parallel initiation feature ARE NOT
IMPLEMENTED IN FINAL FORM.
It currently is a no-operation, and
is provided to allow programs to be coded as though parallel
SYSCALLS were implemented.
WAITDONE SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:END

FCB
FCB
FCB
EQU

SYSCALL:WAITDONE
SCBLK:END-SCBLK:OPCODE
CHANNELNUMBER

If any parallel SYSCALL (a syscall with the WAIT flag = "don't
wait") was issued on the specified I/O channel, WAITDONE delays
the execution of the user program until that operation is
complete.
Error status returned is that of the parallel SYSCALL
returned as though the parallel SYSCALL had the WAIT flag reset
when executed.
A second WAITDONE issued on an I/O channel, without any other
intervening SYSCALLS, returns immediately with no error possible,
so multiple WAITDONEs on a channel may be performed without
conflicts arising.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:EXIT
This syscall is used by a user program to pass control to the
DEFAULTPROGR&~.
It is an indication that the user program
completed execution successfully.
EXIT SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:EXIT
SCBLK:END-SCBLK:OPCODE

There are no parameters, and control does
program.

not return to the user

All I/O channels except channel 0 are CLOSEd.
SDOS does a quiCk checksum on itself after an EXIT is completed,
and reports an error if it thinks memory is starting to fail;
otherwise, no errors are possible.
This syscall is functionally identical to SYSCALL:ERROREXIT with
an error code of 0.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:ERROREXIT
This syscall is used by a user program to cease execution
abnormally, and notify the operator the reason for stopping.
ERROREXIT SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:END

FCB
FCB
FOO
EQU

SYSCALL:ERROREXIT
SCBLK:END-SCBLK:OPCODE
ERRORCODE

The error code is displayed on the console as either
Error
or

depending on whether
SDOS
can
successfully
extract the
corresponding text message from the ERRORMSGS.SYS file on drive 0
(see SYSCALL:DISPERROR).
If the error code is 0, a message is
not displayed. Control is then passed to the DEFAULTPROGRAM
(usually the SDOS command interpreter, which can interrogate and
conditionally branch on the error code if a DO file is being
processed). No error is possible.
This syscall is intended to be used as very simple error handling
in user programs.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
Example:

LDX
JSR
BCS

#PARAMETERLISTADDRESS
SYSCALL$
OOPS
B/ ERROR

OOPS

CPX
BEQ
CPX
BEQ

#ERR:, ..
ICANHANDLEITI
#ERR: ...
ICANHANDLEIT2

IGIVEUP

STX
LDX
JSR
BCS
JMP

ERROREXIT+SCBLK:PARAMS
#ERROREXIT
SYSCALL$
CAN'T GET HERE I
*

ERROREXIT

FCB
FCB
FDB

SYSCALL:ERROREXIT
4
SCBLK:WLEN
0
SCBLK:PARAMS

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:SETERROR
This syscall, coupled with SYSCALL:DISPERROR,
program to display the reason a SYSCALL failed.

used by

SETERROR SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:END

FCB
FCB
FOO
EQU

SYSCALL:SETERROR
SCBLK:END-SCBLK:OPCODE
ERRORCODE

The user program first stores an error code into the syscall
block, and then issues the syscall. The error code has now been
stored in SDOS for use by the DISPERROR and GETERROR syscalls.
Normally, a SETERROR is followed by a DISPERROR, so that a text
display of the error cause occurs. Since control returns to the
user program, this is an effective procedure for displaying the
cause of an error without EXITing to the DEFAULTPROGRAM.
A GETERROR syscall can be used to later retrieve the error code.
A subsequent EXIT or ERROREXIT syscall will change the code set
by SETERROR.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:GETERROR
This syscall is used to retrieve an error
EXIT, ERROREXIT, or SETERROR syscalls.

code given to SDOS by

GETERROR SYSCALL Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF

FCB
FCB
FDB
FDB
FDB
FDB
FDB

SCBLK:RDLEN

FDB

SCBLK:END

EQU

SYSCALL:GETERROR
SYSCALL:END-SCBLK:OPCODE
IGNORED
IGNORED
IGNORED
EXPECTED RETURNED VALUE
2
ERRORCODEBUF
WHERE TO PUT ERROR CODE
LENGTH OF 16 BIT ERROR
2
CODE

The 2 byte error code last given to SDOS is returned in the reply
buffer. No parameters other than the reply buffer discriptor are
necessary.
possible errors are:
Syscall Length Too Short
Read-Back Buffer Too Short

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:DISPERROR
The DISPERROR is used to display a text message
the most recent error code given to SDOS
SYSCALL:ERROREXIT, or SYSCALL:SETERROR.

corresponding to
by SYSCALL:EXIT,

DISPERROR SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:DISPERROR
SCBLK:END-SCBLK:OPCODE

No parameters are needed.
Either
ERROR nnnnn
or

is displayed on channel 0.
If the error code is 0, and error
message IS displayed (see SYSCALL:ERROREXIT for contrast). If
channel 0 is not open, SDOS automatically opens it to the
CONSOLE: device.
SDOS gets the
text
message
from
the
ERRORMSGS.SYS file based on the error code.
If SDOS cannot
retrieve the error message from the ERRORMSGS.SYS file,
it
displays
the simpler form, with nnnnn being the
decimal
equivalent of the error code. No carriage return is output,
so
that the user program may precede or append text to the error
message (such as ... AT LINE 100 for BASIC).
If an error occurs during the process of displaying the message,
SDOS will hang. The operator must re-boot. This can only occur
if SDOS cannot output to the CONSOLE:.

;OPYRIGHT (cl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:KILLPROOF
This SYSCALL is used by an application which needs to perform a
long computation or large amounts of I/O without being killed by
the operator for correct operation.
This situation occurs when
several files need to be updated in order to maintain data base
consistency.
KILLPROOF SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:KILLPROOF
SCBLK:END-SCBLK:OPCODE

Normally, when the operator types ACA C, SDOS kills the currently
running program and causes a forced ERROREXIT. This in turn
displays an appropriate message and causes the DEFAULTPROGRAM to
be loaded.
A double AC is deferred if a SYSCALL:KILLPROOF has been executed
more recently than a KILLENABLE.
Operation of the program
continues undisturbed until it executes SYSCALL:KILLENABLE, at
which point the program is stopped.
The user program can still
sense operator attention requests via the ATTNCHECK syscall.
On EXIT, SDOS switches user programs back to KILLENABLEd mode
dutomatically,
(actually, the DEFAULTPROGRAM is loaded as a
KILLENABLEd user program) so a set of programs invoked by a DO
file is killable. SYSCALL:CHAIN does not affect the KILLENABLE
status of a program, so a large program consisting of several
serially executed segments can operate entirely KILLPROOFed if
needed.
Possible errors are:
Syscall Block Too Short

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:KILLENABLE
This syscall allows a program to be killed by the operator. It is
normally only used after a critical portion of a program, running
KILLDISABLEd, is finished executing.
KILLENABLE SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:KILLENABLE
SCBLK:END-SCBLK:OPCODE

Executing this syscall will allow a program to be killed when the
operator
types
~C~C
(when
the
I/O
package
calls
SDOS:KILLPROGRAM).
If a ~C~C (call to SDOS:KILLPROGRAM) has
occurred while the user program was KILLPROOF,
execution of the
SYSCALL:KILLENABLE will cause the program to quit execution
immediately (i.e., control does not return to the user program in
this case).
SDOSCOMMANDS (the command interpreter) runs KILLENABLEd and loads
user programs initially KILLENABLEd.
The user program must
execute a SYSCALL:KILLDISABLE syscall before performing any
critical operations (see SYSCALL:KILLDISABLE). CHAIN syscalls do
not affect the KILLENABLE status of the user program.
Possible errors are:
Program Killed
Syscall Block Too Short

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:DEBUG
The DEBUG syscall is used to transfer control from a user program
to the local system debugger.
DEBUG SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:DEBUG
SCBLK:END-SCBLK:OPCODE

No parameters are needed.
Control is passed to the system
debugger's entry point. The actual method of passing control is
I/O package dependent.
If there is no debugger, an ERROREXIT is
forced.
For systems with IDB (an SD assembly language debugging tool),
control is passed to the debugger in such a way that a
non-maskable interrupt appears to have occurred. EXIT from IDB
should be made via a "G" command. Using nnnnG to exit lIB and
return to the user program will also work. If a "G" command is
executed, control returns to the user program just beyond the
call, as with any other SYSCALL.
Possible errors are:
Syscall Too Short
No Debugger

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:ATTNCHECK
This SYSCALL is used to determine if the operator would like to
interact with the user program (the operator normally signals
this by striking the ESCape key on his console; the actual
mechanism is determined by the I/O package).
ATTNCHECK SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:ATTNCHECK
SCBLK:END-SCBLK:OPCODE

The ATTNCHECK syscall will return normally if no attention has
been requested since the last ATTNCHECK syscall.
If the opera~or
has requested attention at least once since the last ATTNCHECK
SYSCALL was issued, then an error exit is taken with error code
ERR:ATTENTION.
There are no parameters and no returned results.
Note that depressing ESCape terminates line input mode from the
CONSOLE:; thus, with suitable program design, ESCape can be used
to get a program out of one interaction mode and into another
mode of interaction.

:OPYRIGHT (Cl 1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:ISCONSOLE
This system call is used to determine if channel zero is open to
the operator's console (this is needed because a STATUS syscall
will read back the status of the log channel if logging is
active).
This SYSCALL is used primarily by the command interpreter (when
an error is encountered) to determine whether or not a DO file
should be aborted.
ISCONSOLE SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:END

FCB
FCB
EQU

SYSCALL:ISCONSOLE
SCBLK:END-SCBLK:OPCODE

There are no parameters and no returned results. A normal exit
indicates that channel zero truly is open to the console device;
otherwise, an error exit occurs. The only possible errors are:
Channel is Not Open at All
Channel 0 is Open; But Not to the Console

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:INTERLOCK
This SYSCALL enables multiple users to synchronize usage of one
or more resources (under single-user SDOS, these calls are null
operations).
Each resource is represented by an INTERLOCK
"object"
(note: future SDOS's will provide for many other
abstract object types), and the means of referencing that object
is called a CAPABILITY.
The functions which the INTERLOCK
syscall will perform,
include creating a capability to an
interlock
object; destroying an existing capability to an
interlock object; reserving an object for exclusive use (also
known as "locking" an object), and,
if the Object has been
already locked, suspending execution of the caller until that
Object has been released; releasing the object, allowing the next
suspended requestor to resume execution; conditionally locking an
object, returning an error if that object is already locked; and
releasing and removing all requests for an object.
Note that
objects and capabilities do not "belong" to users (e.g., user 1
may create an interlock capability to an object named "MYFILE" ,
communicate that capability to user 2, and proceed to lock MYFILE
twice, thereby
blocking himself; user 2 subsequently releases
MYFILE, which causes user 1 to be unblocked).
The function codes are expressed as 16-bit values in the PARAMS
field of the SYSCALL block; the specific functions and their
requirements are:
IC:CREATE
Create
a
capability
to
an
ERR:NOSUCHOBJECT will be returned if
invalid.

interlock
object.
the named object is

WRBUF must contain an object name, and WRLEN must be 16. A
16-byte capability to the Object will be returned in RDBUF.
IC:DESTROY
Destroy the usefulness of all capabilities to the named
interlock Object. Release the object if it has been locked;
release all requests for the object; release all suspended
requestors of the object, with ERR:OBJECTDESTROYED. If the
capability is invalid, ERR:NOSUCHOBJECT will be returned.
WRBUF must contain
WRLEN must be 16.

valid

capability to the object, and

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
IC:LOCK
Lock the named interlock object.
If the object is already
locked, the caller's execution is suspended until the object
has been released. Under SDOS/MT 1.2, no more than 32
different
objects may be locked
at
anyone
time
(implementation restriction); attempted violation of the
restriction will result in ERR:IMPLEMENTATIONLIMITREACHED.
If the capability is invalid,
ERR:NOSUCHOBJECT will be
returned.
WRBUF must contain a
WRLEN must be 16.

valid

capability

the object, and

IC:RELEASE
Release the named interlock object.
If the object has not
been previously locked, ERR:NOTLOCKED is returned.
If the
capability is invalid, ERR:NOSUCHOBJECT will be returned.
WRBUF must contain a valid capability to
WRLEN must be 16.

the

object,

and

IC:TEST
Lock the named interlock object.
If the object is already
locked, no further action is taken and ERR:ALREADYLOCKED is
returned. If the capability is invalid, ERR:NOSUCHOBJECT
will be returned.
WRBUF must contain
WRLEN must be 16.

valid

capability

to the object, and

IC:RESET
Unconditionally release the named interlock object,
if
locked; remove all requests for
the object.
Callers
suspended, awaiting use of the object, will be returned to
execution with ERR: LOCKRESET. If the capability is invalid,
ERR:NOSUCHOBJECT will be returned.
WRBUF must contain a valid capability to the
WRLEN must be 16.

object,

and

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:DELAY
This system call is used by a program to wait for some fixed
period of time before continuing execution. This is useful on
multi-user systems when a periodic check is required, as no
resources are used while a program is waiting for the delay to
complete.
DELAY SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:END

FCB
FCB
FCB
EQU

SYSCALL:DELAY
SCBLK:END-SCBLK:OPCODE
DELAY
in 1/60th second units

The delay is a 16 bit value given in 1/60th second units (i.e.,
60 = 1 seconds, 3600
1 minute, etc.). The actual delay is at
least that requested, and may be longer.
Possible errors:
Syscall Block is Too Short

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
SYSCALL:GETSERIALNUMBER
This system call is used to
number of the computer.

read

the

byte

hardware

serial

GETSERIALNUMBER SYSCALL Block Format:
SCBLK:OPCODE
SCBLK:WLEN
SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN
SCBLK:RDBUF
SCBLK:RDLEN

FCB
FCB
FDB
FDB
FDB
FDB
FDB
FDB

SYSCALL:GETSERIALNUMBER
SCBLK:END-SCBLK:OPCODE
IGNORED
IGNORED
IGNORED
8
EXPECTED RETURNED VALUE
SERIALNUMBERBUFFER
8

Possible errors:
Syscall Block is Too Short

~OPYRIGHT

Ie)

1978

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
ASM/6809 1.4Al: 0000
09/17/84 19:43:57: Page 1: Form 1
*** SDOS SYSCALL Example ***
listfile.asm
5: * This is a sample assembly language program to list
6: * a file to the console: device (i.e., it does exactly
7: * the same thing as a list file command does), and
8: * illustrates use of syscalls and error recovery logic.
9:

0200

0200 8E024C
0203 9DFB

0205 2528

0207 8E0277
020A 9DFB
020C 2521

020E BE027F
0211
0214
0217
0219

BF028D
8E0287
9DFB
2514

10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:

*
*

org
$200
nice place for program
set up the equs we need

channe10 equ
channell equ
linemode equ

o
1
1

user terminal channel
channel for file i/o
input in "line mode"

* Print a "hello" message on user channel
*
listfile ldx
#himessage
jsr
syscall$
* If we get an error when printing the "hi" message
* (i.e., the carry is set), this BCS will take us
* to the error routine which will do an error exit
bcs
error

*
* Now input the name of the file the user wishes

*
*
*
*
*
*
*

*
*
*
*
*

*
*

to list to his/her terminal
ldx
jsr
bcs

l/inputfilename
syscall$
error

Next, open the file ••• to do this we set the length
of the file name in the OPEN syscall block equal
the number of characters read in by the last syscall.
We don't have to move the file name anywhere since
we very cleverly made the place that SDOS will look
at for the file name the same place where SDOS
read in the string from the user
(similar to INPUT a$\OPEN #l,a$ in BASIC)
Get how many chars the user typed in
ldx
inputfilename+reada:actualcount
Set the length of file name to number of chars read
stx
openfile+open:length
ldx
#openfile
address of syscall bloc
jsr
syscall$
make SDOS open the file
bcs
error
take branch if "no such,
file", "bad name", etc.i

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
ASM/6809 1.4Al: 0219
09/17/84 19:43:57; Page 2; Form 1
*** SDOS SYSCALL Example ***
listfile.asm
51: * main program loop
52: *
read line from ...
#readaline
021B 8E029l
53: readloop Idx
syscall$
the input file
021E 9DFB
54:
jsr
55: *
56: * Now check to see if the read got an error.
57: * If it did, see if the error was an end of file.
58: *
checkforeof
0220 2517
59:
bcs
60: *
61: * If we get to here, we know we didn't get an error.
62: * So set the length of the write buffer equal to the
63: * number of characters read in
64: *
readaline+reada:actual~ount
0222 BE0299
65:
Idx
0225 BF02A7
writealine+writea:count
stx
66:
67: *
68: * and then send the line out to the user
69: *
#writealine
0228 8E02Al
70:
Idx
022B 9DFB
syscall$
71:
jsr
72: * If no error on output, go read another line
read loop
022D 24EC
73:
bcc
74: *
75: * Error routine: copy error code in X to a syscall
76: * block which will have SDOS print out the
77: * corresponding error message and exit
78: *
errorexit+errorexit:code
022F BF02AB
79: error
stx
0232 8E02A9
80:
Idx
#errorexit
SDOS shouldn't return,
81:
jsr
syscall$
0235 9DFB
should never get here
0237 25FE
82:
bcs
*
83: ..
84: * Check for EndOfFile: if so, wrap things up and exit.
85: .. ~Otherwise, do an error exit.
86: *
87: checkforeof cpx #err:eofhit EndOfFile error?
0239 8C03E9
88:
bne
error
if not, go complain
023C 26Fl
89:
Idx
#byemessage print "I'm done" message
023E 8E02AD
90:
jsr
syscall$
0241 9DFB
murphy's law strikes again!
91:
bcs
error
0243 25EA
now exit
92:
Idx
#exi t
0245 8E02BD
93:
jsr
syscall$
0248 9DFB
this can't happen
94:
bcs
error
024A 25E3
95, *
96: * end of code

software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
~SM/6809 1.4Al: 024A
09/17/84 19:43:57; Page 3; Form 1
*** SDOS SYSCALL Example .***
listfile. asm
98: * blocks for syscal1s
99: *
024C
100: himessage ; syscall block to output "hello" message
n4C 0C
101:
fcb
syscall:writea
}24D 08
102:
fcb
writea:sclen
}24E 00
103:
fcb
channel0
J24F 00
104:
fcb
ignored
filler
}250 0254
105:
fdb
hitext
pointer to message
J252 0023
106:
fdb
hitextlen
length of message
107:
3254 48692128 108: hitext fcc
'Hi! What file do you want to list?
0023
109: hitextlen equ
*-hitext
length of message

110:

0277
3277 0A
3278 0E
3279 00
327A 01
1J27B 0000
1J27D 0000
1J27F 0000
3281 02BF
3283 0100
3285 0002

I l l : inputfilename

112:
113:
114:
115:

116:
117:
118:
119:

syscall block to accept line from user
syscall:reada
reada:sclen
channe10
from the user
input up to a
linemode
ignored
dummy write buffer stuff
ignored
ignored
filenamebuf
read buffer
filenamebufmax max amount to read
2
amount read (set by SDOS

120:
121:
122:
123: openfile ; syscall block to open a file
124:
fcb
syscal1:open
125:
fcb
open:sclen
126:
fcb
channell
filler
127:
fcb
ignored
where user's input is
128:
fdb
filenamebuf
buffer length (set by pgl
129:
rmb
4

0287
3287 00
3288 0E
3289 01
328A 00
328B 02BF
028D 0004

130:
131 : readaline ; syscall block to read a line from a file

0291
0291 0A
0292 0E
0293 01
0294 01
0295 0000
0297 0000
0299 0000
029B 02BF
029D 0100
029F 0002

fcb
fcb
fcb
fcb
fdb
fdb
fdb
fdb
fdb
rmb

132:

133:
134:
135:
136:
137:
138:
139:

140:
141:

(cl

1978

fcb
fcb
fcb
fcb
fdb
fdb
fdb
fdb
fdb
rmb

syscall:reada
reada:sclen
channell
linemode
ignored
ignored
ignored
readbuffer
readbuffermax

dummy write buffer stuff

how much data read

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION V: SYSCALLS - IMPLEMENTATION
ASM/6809 1.4A1: 029F
09/17/84 19:43:57; Page 4; Form 1
*** SDOS SYSCALL Example ***
listfi1e.asm
02Al
143: writealine ; syscall block to write a line on terminal
02A1 0C
144:
fcb
syscall:writea
02A2 08
145:
fcb
writea:sclen
02A3 00
146:
channe10
fcb
02A4 00
147:
ignored
filler
fcb
02A5 02BF
148:
fdb
writebuffer
149:
02A7 0002
rmb
2
length of line
150:
02A9
151: errorexit ; syscall block to effect error exit
02A9 12
152:
fcb
syscall:errorexit
02AA 04
fcb
errorexit:sclen
153:
02AB 0002
set to error code by pgm
154:
rmb
2
155:
156: byemessage ; syscall block to print "done .•. II
02AD
02AD 0C
157:
fcb
syscal1:writea
fcb
158:
writea:sclen
02AE 08
159:
02AF 00
channe10
fcb
fcb
02B0 00
160:
ignored
02B1 02B5
161:
fdb
byetext
02B3 0008
162:
fdb
byetextlen
163:
"done ... II
02B5 646F6E65 164: byetext fcc
02BC 0D
carriage return
165:
fcb
$0d
0008
166: byetextlen
equ
*-byetext
167:
02BD
168: exit ; syscal1 block to effect normal exit
02BD 11
169:
fcb
sysca11:exit
170:
02BE 02
fcb
exit:sclen
171:
172: * and here's the i/o buffer
02BF
equ
173: filenamebuf
*
02BF
174: readbuffer
equ
*
02BF
equ
175: writebuffer
*
176: filenamebufmax equ
0100
$111'0
0100
177: readbuffermax
equ
$100
02BF 0100
178:
rmb
readbuffermax
space for buffer
179: *
180: * that's all folks!
181: *
182:
end
listfile

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
WRITING and DEBUGGING User Assembly Programs
Writing a User Assembly-Language
requires the following steps:

program

1) Use EDIT (or some other means) to place
source program on a disk.
2)

to run
the

Use ASM to produce a listing (optional) and a
version of the desired program.

under

SDOS

desired assembly
.BIN

(Binary)

a) Execute the program by typing its name
or
3) b) Debug the program by typing
3)

.DEBUG name
This will pass control to the local system debugger (usually
IDB) and debugging may commence.
Note: Breakpoints should not be placed on a BCC/BCS after a
SYSCALL (SDOS will not see the BCx if an error occurs and a
system failure will result). Further, breakpoints should
all be removed before a SYSCALL:EXIT or SYSCALL:ERROREXIT
is executed. Also, SDOS has no "warm start" entry point;
if the program runs away, the operator's only safe choice
is to re-boot.

Software Dynamics

SOOS APPLICATION PROGRAMMERS' GUIOE
SECTION VI: SOOS CONSTRUCTION/FUNCTIONS
MEMORY MAP
The memory of the 6800/6809 computer, when
program under SOOS, has the following layout:
LOCATIONS

executing

user

CONTENTS

$0-$7 (6800 and 6809)
$18-$lF (6801 and 6811)
Scratch temporaries, usable by user program. Note:
These temporaries are also used by SOOS; so any
SYSCALL will destroy their contents.
$20-$EF
User program page zero.
I/O package.

Not used by SOOS or

the

$FO-$FA
System dependent data used by system hardware
(ROM), I/O package or interrupt routines for any
purpose; see specific I/O packages. User programs
must not disturb this data; references to this
data
will
make
the
program
hardware
or
configuration dependent.
$FB,$FC,$FO
SYSCALL entry point. These three bytes contain a
JMP to the SYSCALL entry point in SOOS. All user
programs should define SYSCALL$ as $FB; this will
make them independent of the actual location of
SOOS. These bytes are initialized by SOOS whenever
a CHAIN or LOAO SYSCALL is executed.
Bytes
$FC,$FO form a 16 bit pointer to the first byte of
SOOS (to the first byte above the memory space
available to the user program).
$FE,$FF
Reserved for system dependent data (typically a
pointer to last byte or page of RAM) .
User
program must not disturb or use.
$100-(800S-1)
User program area. Used in any way desired by
user programs.
Last byte of this area has an
address equal to contents of ($FC,$FO) minus 1.
On entry (CHAIN) to a user program, the stack
register
is set
to
this
value
(SOOS-l).
Generally, user programs have a start address of
$100.
SOOS -Beginning of SOOS (and/or I/O
program may not overlay or store
above this boundary.
COPYRIGHT (C) 1978

package).
any byte

User
on or

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
Typical SDOS Address Space

LOW
PAGE ZERO
$:0100
SD SOFTWARE or
CUSTOMER SOFTWARE I
I
I
------------------

:7800
TTY,
LINEPRINTER,
DRIVERS,
(ETC. )

MISCELLANEOUS
DISK READ
DISK WRITE
DISK WAITDONE

\
1
1
1

I/O Package

DISK
SECTOR
BUFFERS

I------------------!
I

VT DRIVER

SDOS
(DISK FILE
MANAGEMENT)

I 48K
63K DEPENDING ON
CONFIGURATION

I//////////////////!
1//////////////////1 NON-EXISTENT MEMORY
I//////////////////!

1------------------1

:F000

IDB

:FC00

----~S~DO~S~B~O~O~T~----I

:FF00
I/O SPACE

ROM VECTORS TO OTHER ROM

HIGH

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
SDOS LOADER FORMATS
SDOS will load files containing one of two types of records:
1) SDOS Load Records
2) Encrypted Load Records
A file to be loaded must contain
encrypted load records.

only

SDOS

load

records,

SDOS LOAD RECORD FORMATS
SDOS Load Records are designed to let SDOS load large blocks of
contiguous memory efficiently, and still retain scatter-load
capability. A file containing SDOS Load Records appears as a
stream of load records.
Each load record has a type and a
format. There are four SDOS load record types; all four contain
binary information for ease of processing by the loader and to
minimize file space occupied.
Each load
record
type is
identified by its first byte. One record immediately follows
another.
SDOS load record type 1 must be the first record (i.e., start on
byte 0) of the file.
It is fOllowed by 2 bytes forming a 16 bit
start address, MSB first. The next two bytes are the 16 bit
one's complement of the start address, MSB first (this record
format makes it extremely improbable that a non-load format file
is actually loaded by accident). The first byte of a A Type 1
load record specifies the CPU type:
$01
$03
$02
$07
$11

6800
6801/6803
6809
6303
6811

SDOS load record type 0 is a skip record.
The two bytes
following the record type byte form a 16 bit count (MSB first) of
the number of bytes following the skip record to ignore. The
loader processes this record by positioning the file to the file
position after the skip record, plus count bytes.
This record
format is used to align following load records on power of two
boundaries which can speed up loading of larger data records.
SDOS load record types 2 and 3 are identical in format.
Both
record types are used to load blocks of data into the memory
address specified by the two bytes following the record type byte
(MSB first). The number of bytes to be loaded is given by the 16
bit count specified by the next two bytes (MSB first). The data
bytes to be loaded immediately follow the count bytes.

Software

Dynamic~

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
A type 2 record specifies that another load record follows (i.e.,
that EOF does not immediately follow the records) and that
further load record processing is needed.
A type 3 record
indicates that the load process is complete once the data bytes
in the type 3 record are loaded (i.e., there are no more load
records in the file). After processing a type 3 record, a
SYSCALL:CHAIN will transfer control to the
start
address
specified by the type 1 record.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
SDOS LOAD RECORD FORMATS
Command

COUNT

____ 1

1 ••••• 1
____ 1
1_~_ __

2-sYTES--- _____~--__
1
1

COUNT BYTES
Meaning: Skip COUNT bytes to find
next command.
Used as a
space filler to pad to the
next physical sector boundary.
lCPU Type

ADDRESS

---------

16 BIT CHECKSUM

~YTES

---~2-BYT==E~S----

ADDRESS

COUNT

Set
start address.
Must be first command
in file.
CHECt·3UM is
:FFFF - address.

DATA BYTES

COUNT BYTES
Causes data bytes to be loaded
sequentially
into
memory
starting with the specified
address.
3

ADDRESS
1

COUNT
1

DATA BYTES
1

- - - - - -----2 BYTES -----2 BYTES --------------Just like 2, but also causes
JUMP to start address specified.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
The load records are used in the
disk reads (example):
Logical byte #'s

following

way

to optimize the

Type 1 record

Must be first in file

Type 0 record

Filler record

Type 2 record

Indicates "Load next
two sectors".

NBPS
2*NBPS
3*NBPS

I=================!

1ST Data Byte

1
1

1=================1

1 Type 3 record
1__________________

1
1
1

4*NBPS

1=================1

Indicates "Load next
two sectors" and
transfer control to
start address when
done.

1
1

I=================!
Encrypted Files

05
I S# COUNT
48 Random Bits
1
1__________~--~----------------,-----1st Serial Number

I,----------~~--~--~---------------2nd Serial Number

I----------~-=--~-=~---------------S# Serial Number

1------------------------------------

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
ENCRYPTED OBJECT FILES
An encrypted file is one whose content is not in a directly
usable
form.
Under SDOS, encrypted object files contain
proprietary programs which are designed to run on only a limited
number of CPUs. Some programs are proprietary to Software
Dynamics; other programs are proprietary to other vendors.
Software Dynamics provides a tool to allow vendors to encrypt
their own object programs or suite of programs.
An
encrypted program is decrypted by SDOS while loading into
memory by use of an Encryption Key. The Encryption Key is a
function of the serial numbers of the CPUs on which the program
is authorized run, and a 48 bit "application suite" number
embedded in the object file.

SDOS zeros the address space when loading an encrypted file whose
Encryption Key is different than the Encryption Key of the last
file
loaded.
This prevents "Trojan Horse" software from
obtaining a snapshot of a previously-executed program. Only
programs with the same encryption key may pass control (and
non-zero data) to one another.
This is a common requirement of
an "application suite".
Encrypted object files have an un-encrypted 1st object record,
followed by the rest of the file ~n an encrypted format. The
encrypted portion of the file, once un-encrypted, is in standard
SDOS load record format, with the exception that no skip records
are allowed (decrypting skip records is simply a waste of time).
The first object record starts with a byte containing :05,
signifying
this
file
is
an encrypted object file.
The
SerialNumberCount (S#) specifies how many serial numbers for
which
this object
file
was
encrypted.
Following
the
SerialNumberCount are 6 bytes
of Application Suite number
(typically a random number chosen at time of encryption). Last
are a series of 8 byte Serial Numbers on which this object file
is authorized to run. These serial numbers are in a clear text
form so they can be easily inspected by a utility program.

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
SDOS DISK FILE STRUCTURE
This section gives detailed information on the structure of the
SDOS disk file system.
Two concepts are critical to the
understanding of the file system: Logical Sector Numbers and
Logical Cluster Numbers. These concepts are detailed xbelow.
Definitions:
NBPS
NSPT
NTPC
NCYL
NLSN
Note:

Number of bytes/sector (2 n,n=1 .. 15). Must be power of
2!! NBPS is limited to 128*32=4096 by directory search
routine. Minimum size is 128 bytes (see BOOT sector).
Number of sectors/track
Number of tracks/cylinder
Number of cylinders/drive
Number of (logical) sectors on a disk (= NSPT*NTPC*NCYL)
A

Number
of
bytes/cluster
implementation.

2 16
A

for

6800/6809

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
LOGICAL SECTOR NUMBERS (LSNs)
LSN's are imaginary sequence numbering applied to physical disk
sectors on a disk cartridge or floppy diskette. The reason for
using them is that Logical Sector Numbers can be mapped onto any
disk removing any structure that the disk drive might arbitrarily
impose from the knowledge and concern of SDOS; i.e., the
distinction between tracks, cylinders, and sectors ceases to be
of concern to the SDOS file system.
The only requirements placed by SDOS on LSN's is that they begin
with 0 and increase sequentially; further,
track 0, sector 0,
cylinder 0 (usually) maps into LSN 0.
This is because most
hardware interfaces can read in this physical disk block as a
means for booting the system, so SDOS reserves LSN 0 for this
block.
A useful method for choosing the LSN number for a disk block on
physical cylinder C, track T, and sector Sis:
LSN(C,T,S)=S+NSPT*(T+NTPC*C)
where NSPT and NTPC are the number of Sectors per Track and the
number of Tracks per Cylinder, respectively; where 0<=S= INT(NLSN/NSPC) where NBPS is the number of bytes
per sector.
This constraint allows SDOS to use a single cluster
to record all the clusters of a file. This constraint can be
violated, but the result is that a single file might not be able
to use the entire disk. SDOS will complain if the Header Cluster
COPYRIGHT (e) 1978

100

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
of a file overflows when allocating space to a file.
The third constraint is that l<=NSPC<=255.
This
implementation restriction and must be followed.

purely an

Assuming a file with 2'31=2.1x10'9 bytes, NBPS=512, NSPC=255, we
have 2.1x10'9/512=4.2x10'6 sectors in file; 4.2x10 6/255=l6449
clusters in file. The header cluster has room for 255*512/2=65280
clusters, which covers such a file easily.
A

To minimize average wasted space in disk files, NSPC should be
chosen to be as small as possible within the constraints
specified. This may leave some disk sectors (with high LSNs)
unused by SDOS if NLSN is not a multiple of NSPC. but the total
wastage here is again only 1/2*NSPC sectors average, and if one
has 100 files on a disk, this is insignificant in comparison with
the total savings. A final note: if the number of sectors per
cylinder is not a multiple of NSPC, some time inefficiency will
occur when reading sequentially through a cluster because some
clusters will
cross
track
or cylinder boundaries.
This
inefficiency will be small if the average file size is much
greater than NSPT*NSPC.
If the average file size is smaller than NSPT*NTPC, some time
savings can be gained by making NSPC a divisor of NTPC - this
will generally prevent part of file (cluster)
from overlapping
cylinder boundaries, and will therefore save seek time.
A sample calculation of NSPC:
Assume we have 77 cylinders (NCYL=77), 1 track/cylinder
(NTPC=l),
16 sectors/track (NSPT=16),
256 bytes/sector
(NBPS=256)
(so
NLSN=NSPT*NTPC*NCYL=16*1*76=1232).
Let
LSN(C,T,S)=S+16*(T+l*C).
Since we have only one track
(track #0), the formula simplifies:
LSN(C,S)=S+16C
For any NSPC>=l then
NLSN/NSPC
65536,
satisfying
constraint 1.
Constraint 2 implies:
NSPC*256/2>=INT(1232/NSPC)
NSPC*128>=INT(1232/NSPC)
which is true for any NSPC>=4
If we choose NSPC=4, constraint 3 is also satisfied.
To minimize average wasted space, we choose NSPC=4. On a disk
with 100 files,
an average of 100*4/2=200 disk sectors are
wasted.
With NSPC=3, with 100 files wastes an average of
100*3/2=150 sectors, and prevents files from containing more than
1152 sectors (i.e., a particular file can only cover 93% of the
disk).

101

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
DISK FILE STRUCTURE
A File under SDOS is a mechanism for storing logically related
information. From the point of view of an application program,
a
disk file is a very large array of 8 bit bytes which can be
read/written
sequentially,
can
be
positioned
for later
read/writes, and can be automatically extended (at the end) to
add more information.
These files can be up to 2~31 bytes (2.1
billion bytes) in size, physical disk size being the real
limitation.
This view of files is implemented by device drivers.
The
operations that a device driver considers legal and the actual
operation performed are dependent on each device driver (see
Device Drivers). There are two kinds of drivers: non-disk file
and disk file.
The disk file driver is a component of SDOS proper.
It handles
files by breaking them dom1 into two layers: clusters and
sectors. Sectors are the physical unit of transfer to/from the
disk drive. Clusters are a logical grouping of sectors used to
minimize the amount of information required to record where all
the sectors of a file are located.
Each file has a special cluster of sectors known as the Header
Cluster. The Header Cluster contains the logical cluster numbers
of all (data) clusters contained in the file. These numbers are
placed in the Header Cluster in such a way as to indicate the
relative (byte) position of the target cluster in the file.
A special cluster number of hex :FFFF means "no
allocated" to this place in the file.
This allows
to be built with very little wasted space.

102

data cluster
sparse files

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS

First Cluster Pointer
Points to Headercluster

1
I

1
V

Header
Cluster

2B
2B
2B

----------1
---------------

Remaining Cluster Pointers
Point to Data Clusters
1
1
1
1

NSPC*NBPS

Data Cluster #0

1-->1

1
1

Data Cluster #1
1----->1

0
1

NSPC-l

Data Cluster #N
1--------->1
1

The first two bytes in the header cluster are reserved to contain
the cluster number of the header cluster itself (this simplifies
the space allocation routines).
Succeeding pairs of bytes
contain the logical cluster numbers of the 0th data clusters. 1st
data cluster, etc.
When a file is first allocated,
all the pointers (except the
first) in the first sector of the header cluster are initialized
as :FFFF (no data cluster allocated).
The other sectors in the
header cluster are left as garbage.
A special 1 byte counter (stored in the directory),
DIR:HrC:IC
(header cluster initialized count) tells SDOS how many of
the
sectors in the header cluster are initialized.
COPYRIGHT (C) 1978

103

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
If a data byte is in logical byte number "LBN"
SDOS can access that byte (in at most two disk
following process (definition):

in a file, then
reads) by the

First, compute:
NBPC := NSPC*NBPS
RDCN := INT(LBN/NBPC)

(COMPUTE # BYTES/CLUSTER)
(COMPUTE THE RELATIVE DATA
CLUSTER NUMBER)
HSLSN := INT[(RDCN+l)*2J/NBPS + HCLCN*NSPC

where HSLSN = header sector logical sector number
and HCLCN = header cluster logical cluster number.
This computes the LSN of desired sector in the Header
Cluster. The "+1" is because the first cluster pointer
is the pointer to the header cluster.
The "*2" is
because each cluster number occupies two bytes.
Note: HCSIC may indicate that this sector (HSLSN) has not
been initialized!!
Next:
read HSLSN into memory in HBBUF (header buffer)
DBLCN := @((((RDCN+l)*2)MOD NBPS)+.HBBUF)
this computes the LCN of the data cluster containing the
byte.
"@" means use the value to the right as a memory address
and fetch 16 bits. ".HBBUF" means the address of the
header buffer. Note: DBLCN may be :FFFF (undefined)!!
Finally:
DBLSN := DBLCN*NSPC+INT((LBN MOD NSPC*NBPS)/NBPS)
Read DBLSN into memory; desired byte is
found
displacement RBN := LBN MOD NBPS

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
SDOS FILE STRUCTURE

DIRECTORY
ENTRY
LCN -----------

1
1
1
1

--------------/
1

1
-1--1
1

Header Cluster - First Cluster of File

1-=--:::::- T
1
1----===--1
1
1

!--===-1
I~

1 ...... 1
1
1
1
1
1
1
1
1

) (Some)
)Sections
)Initialized
)To "No
)Cluster
)Allocated"
)At File
)Creation
)Time

1-------> 2nd Data Cluster
A Cluster Number Of
:FFFF
Means "No Cluster
Allocated"

1---------> 1st Data Cluster

105

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS

Header Cluster

1------------------->
------------>

2nd Data Cluster
Etc.

1st Data Cluster

!----->
1. . . . . I
I

Logical sector number of 1st sector in cluster =
clust~r number * cluster size in sectors.
Succeeding sector numbers are base sector number +
cluster.

106

index

into

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
DIRECTORY.SYS STRUCTURE
The directory stores the name and location of the header cluster
for all files on the disk (SDOS allows no magic disk files which
are not in the directory; even system files are mentioned in the
directory) .
Each Directory
information:

entry

bytes

and contains the following

DIR:FILENAME
The file name can be any left-justified sequence of letters
(uppercase only), digits 0 through 9, $ or ".".
It may not
begin with a "." or a digit.
The name is blank filled to 16
bytes.
Two file names are considered equivalent if they
match byte for byte.
SDOS automatically folds lowercase
characters in disk file names into uppercase.
Bit 7 of all
bytes must be zero.
DIR:HLCN
The Header Logical Cluster Number specifies the location of
the Header Cluster for the file if DIR:HCSIC > 0.
If
DIR:HCSIC = 0, then DIR:HLCN is actually the cluster number
of the 1st data cluster.
DIR:HCSIC
The Header Cluster Sector Initialized Count tells. SDOS how
many sectors of the header cluster have been initialized
properly (see File Structure)
and need not concern any but
the systems programmer. DIR:HCSIC is updated whenever a new
header cluster sector is initialized.
If DIR:HCSIC is zero,
and DIR:NCLUSTERS > 0,
then the file is contiguously
allocated on the disk, with the first data cluster being in
DIR:HLCN, contiguous for DIR:NCLUSTERS.
DIR:NCLUSTERS
This
DIR:NCLUSTERS is the number of clusters allocated.
count is needed as a very sparse file may have an enormous
logical file size, and yet have a very small actual disk
allocation.
SDOS updates DIR:NCLUSTERS only when a file is
closed.
If DIR:NCLUSTERS is zero, this directory entry is
not valid and is available for use by a new file (name).
DIR:FILESIZE
DIR:FILESIZE is the apparent size of the file in bytes, and
is equal to the position of the last data byte written in
the file, +1.
The filesize is completely independent of
sector or cluster size.

107

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
DIR:PROTECTION
DIR:PROTECTION
contains
file
protection
bits.
The
protection bits prevent inadvertant or undesired references
to file. The currently defined bits are:

7
6
5

4
3
2
1

PROTECT:WRITE

PROTECT: BACKUP

PROTECT:WRITE
The PROTECT:WRITE bit prevents DELETE,
RENAME, and
CREA~E commands on a
file with the corresponding name.
This is used by SDOS to prevent accidental erasures of
critical system files, and may be used by the user to
protect his critical files.
PROTECT: BACKUP
This bit prevents SDOSDISKBACKUP from backing up a file
if the CHANGED option is specified.
It is reset
whenever a file is first created, or when a file is
mOdified in any way (SYSCALL:WRITEA, SYSCALL:WRITEB,
CC:SETFILESIZE, etc.).
It is set by SDOSDISKBACKUP
whenever a file has been backed up using the CHANGED
option.
DIR:CREATIONDATE
DIR:CREATIONDATE contains the creation date of the file in
the form DDMMYY. DD is one byte containing the day number in
BCD; MM is one byte of BCD month; and YY is the year number
modulo 100 in one BCD byte.
SDOSDISKINIT generally places the first data cluster of the
directory at INT(NLCN/2) (the middle of the logical disk) in an
attempt to decrease seek-to-directory time. This also causes
SDOS to extend the directory in the middle of the disk if need
be. Note: This LCN must be non-zero! (Otherwise, the directory
and the boot cluster collide.)
SDOS locates the directory initially by reading BOOT:DIRLSN from
the BOOT.SYS file.
BOOT:DIRLSN gives the LSN of the directory
sector containing the DIRECTORY.SYS entry. The directory entry
for DIRECTORY.SYS is located in the first 32 bytes of the sector.
This requirement also forces the sector size to be at least 32
bytes (the first entry must be contained entirely in the first
directory sector), and to be a multiple of 321

108

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
All other filenames in the directory are added to it according to
the following procedure:
The directory is searched by initially hashing the desired
name to choose a directory sector, and then searching
circularly through the directory for the desired name. The
hashing scheme tends to make lookups of existing names very
quick, as long as the directory is 80% or less loaded. The
circular search guarantees that even if the directory size
changes, files will still be found.
The directory is automatically expanded by SDOS if it is
full and a new filename needs to be added.
This automatic
expansion invalidates all the previous hashes, but since new
(or renamed)
files will get hashed to the correct place,
after the system has been used with the expanded directory
awhile,
lookups will speed up again. Renaming a file
rehashes it, so renaming all files will rehash them all.
The directory size is kept in the DIR:FILESIZE entry of the
DIRECTORY.SYS entry, and is always a multiple of the cluster size
(NBPC).
As a convenience to the hashing algorithm,
a limit
directory sectors is imposed on the DIRECTORY.SYS file.

109

of 65536

Software Dynamic.

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
Directory Entry

I================!

1 16

DIR:NAME

1----------------1
1

DIR:HLCN

1
1

Bytes,
Legal Names Contain
A-Z, 0-9, $, "."

1 2B,

Header Cluster Number

!----------------I
DIR:HCSIC

1----------------1

IB Header Cluster Sector
Initialized Count

DIR:NCLUSTERS 1 2B Number of Data
1 Clusters in File

I----------------!

1
!

DIR:FILESIZE
.

!----------------I
1 DIR:PROTECTION !

4B, Number of Bytes in
The File
IB, Protection Bits

1----------------1

IDIR:CREATIONDATEI 3B

1----------------1
1
UNUSED
I================!
1
1
1
!

1
1

110

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
File System Sketch
DIRECTORY.SYS
file body
1<-------1

BOOT:
DIRLSN

*------->

BOOT.SYS
Header

•••

1
1
-----1

LCN 0, LSN "

I
I

DIRECTORY.SYS
Header Cluster

DIRECTORY 1
-1--1--~--~----~----~1
.SYS #-------->1
#
1
1
!
!
1
1
1
-----------1
usually, LCN=@(Directory)-l

1
___________ 1
1
1
1 <-----# BOOT
.SYS
1
1
1___________
1
1

DISKMAP.SYS file body
"Busy Cluster Mar"
(1 cluster)

SDOS.SYS
Header Cluster
--------------SDOS.SYS
! # 1 ••• 1
1<--------#
!

-1- - - -

1--------

I SDOS.SYS
I file body
V

--L"'C~N-;;#"-1--7
LCN #2
LCN #3

1
1

DISKMAP.SYS
Header Cluster

DISKMAP
-I--I---,------,-----~--~
.SYS #--------->1
#
1

LCN #n
Notes: *
#

represents pointer to (logical) sector
represents pointer to (logical) cluster

SDOS hashes to 1st directory
search thereafter.

entry,

III

and

does

linear

circular

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
Physical Placement of Files on Disk

LCN

NLCN/2
,
Logical Sector 0

/---,
/

BO"'OT;;;-;.S""Y"'S"-'/'\

,
V

- - - - - ' \ S \ <--- Logical Cluster #1
\ D \ <--- LCN 2, 3, etc.
!D::-I=SKMA:;-:::-;::-:P::-.-:S~Y:::S:-:\ 0 \

---------------

\
I

/--\
I

I
I

__/

S \
I

TSI

! Y I
I S I

/ . / <--------- LCN -- NLCN/2
\

/ Y /

......E....,.C;-;;;T-O" R

,.l-D~I.,.--;R

------------------/

\_--------------------/

112

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
THE BOOT.SYS FILE
BOOT.SYS is a file which owns LSN 0 (the boot sector).
The BOOT.SYS file contains three things:
1) a disk identification (32 bytes of text blank padded).
2) the appropriate DISKINFO (tuning parameters) for this disk
3) a "simple" program to read SDOS off the disk and into memory
as a means of booting.
Items 1 and 2 are stored in fixed places in LSN 0 and occupy the
first 64 bytes.
This sets a minimum sector size requirement of
64 + 1 --> 128 (sector sizes must be a power of twol). Other
LSN's in the BOOT.SYS file are simply wasted or used to store an
extended bootstrap program if needed.
The form of the boot sector must be as follows:

16 BYTES
15 BYTES
1 BYTE

32 BYTES

REST OF
SECTOR

JUMP ----------- These Bytes Are
Used For Any
Purpose By Boot
DISK
or Boot ROM
INFO
Routine
IDISKINFOCKSUM

1_ _ _ _ _ __

<------

:FF - Sum of
Bytes in
DISKINFO Part

DISK
ID

BOOT
ROUTINE

This ensures that the
locatable, and that it
executing.

<--------1

disk
does

identification string is easily
not prevent the boot routine from

Normally. LSN 0 is read into memory at $100 by a ROM boot
The boot sector
routine, and control is passed to location $100.
reads in the rest of BOOT.SYS if necessary.

113

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
The boot routine then reads the contents of the SDOS file into
memory at the appropriate place, and transfer control to the
starting point.
BOOT:FILESYSTEMVERSION is a single byte containing a file system
version and revision number in the left and right nibbles,
respectively.
This document describes file system version
1.1 (note: SDOS revision numbers do not necessarily match
file system revision numbersl).
BOOT:NSPC is a single byte which specifies the cluster size of
clusters on this disk (0= 1.

minimum
being

number of
extended.

BOOT:MAPALGORITHM is 16 bits which are used in a disk-sector
driver dependent way to tune rotational and seek latency
times to a minimum.
Commonly, the upper 8 bits are used as "spiralling", or the
number of sectors each cylinder should be offset from the
next (cylinaer) to tune seeks for sequential reads; the
lower byte tunes the physical spacing between adjacent
logical sector numbers (also measured in units of sector
times). SDOS can usually only read every other sector, best
case.
When using the "common" mapalgorithm interpretation to map
LSNs into physical CYLINDER, TRACK, and SECTOR (assuming
CYLINDERs and TRACKs increase sequentially from 0, and
physical sector 0 on all TRACKs are aligned) the following
formulas apply:

114

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
REM PSUEDO-BASIC TO COMPUTE PHYSICAL CYLINDER, TRACK, SECTOR
CYLINDER= INT(LSN/(NSPT*NTPC))
TRACK= INT((LSN-CYLINDER*NSPT*NTPC)/NSPT)
SECTOR= ((CYLINDER*SPIRAL)+MAP[LSN MOD NSPT]) MOD NSPT
where

MAP[i]= (i*SPACING) MOD NSPT if SPACING is relatively
prime to NSPT, and is generally computed as:
MAP[0]:= 0 \ I RULE I
K= SPACING
FOR i= 1 TO NSPT-l
100 FOR J= 0 TO i-l
IF K= MAP[J] THEN K=(K+l) MOD NSPT\ GOTO 100
NEXT J
MAP[i]= K
K= (K+SPACING) MOD NSPT
NEXT i

On hardware systems where formatting a disk is used to effect
this tuning, the Mapalgorithm is by convention always set to "1".
BOOT:CREATIONDATE is the date that this disk was SDOSDISKINITed,
and consists of 3 BCD bytes: day,
month,
and year MOD 100,
respectively.
BOOT:DIRLSN is the Logical Sector Number of the DIRECTORY.SYS
sector that contains the DIRECTORY.SYS directory entry in
the first 32 bytes.
BOOT:CHECKSUM contains :FF-[sum of the 15 bytes between (and
including) BOOT:FILESYSTEMVERSION] modulo 256,
and is used
to check the validity of the disk.
BOOT:DISKID contains 32 ASCII characters blank filled,
used
solely as a disk identification.
This ID is displayed by
the FILES command.
It can be used (read) by an application
for the purpose of verifying the disk before the application
uses it.
The boot routine is used to read the contents of SDOS.SYS into
memory. Ususally, the boot routine does not fit entirely into the
remainder of the BOOT sector; the rest of the boot routine is
stored in memory image format in the remaining sectors of LCN 0.
Listings of sample boot routines can be obtained from the
distributor of SDOS or from Software Dynamics.

115

Software Dynamics

SOOS APPLICATION PROGRAMMERS' GUIOE
SECTION VI: SOOS CONSTRUCTION/FUNCTIONS
SERIALNUMBER.SYS
SERIALNUMBER.SYS is a file required to be on an SOOS boot disk in
order that SOOS may successfully boot. The file is encrypted,
and contains several things:
A first-time-only conversation with the purchaser of SOOS;
The serial number of the computer for which the particular
version of SOOS was sold; and
The name of the end-user, or organization.
SOOS, after initializing operation of the system, goes and hunts
for SERIALNUMBER.SYS.
If this file
does not exist,
SOOS
displays, and hangs up with a "No SERIALNUMBER.SYS file" error.
If the file does exist, it is CHAINed to, causing implicit
decryption.
The SOOS decrypting loader will refuse to load
SERIALNUMBER.SYS if the serial number encoded into it does not
match that of the ROM included in the system hardware;
this
causes a "Wrong Serial Number" message to be printed, and
operation of SOOS is aborted.
If SERIALNUMBER.SYS is not
encrypted, an error message will likewise be generated and SOOS
will not run. Otherwise, the module is loaded and executed.
If
this is not the first time SERIALNUMBER.SYS has been loaded, then
SERIALNUMBER.SYS first prints the ROM serial number, and the name
of the end-user; further operation of SDOS is normal.
The name of the end-user is supplied by the end-user when the
copy is first run by him; i.e.,
if the end-user name is blank.
SERIALNUMBER.SYS asks the name and then waits for the operator to
enter a corresponding code number that he must obtain from
Software Dynamics.
This code number is generated by Software
Dynamics from the serial number of the computer and the string
entered by the user (this may be obtained from Software Dynamics
well in advance of system installation, in order to minimize
delays). An invalid response is so indicated, and the end-user
name is NOT updated. A correct response causes SERIALNUMBER.SYS
to change the end-user name to the supplied string. Once set,
the SERIALNUMBER.SYS file can never be changed again. A response
of is taken as a signal that the user does not wish to set
the name yet (this may be a demo copy, or the user may not have
yet
obtained the corresponding code number from
Software
Oynamics);
in this case, after a 30 minute delay,
SOOS will
operate normally.

l16

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
SDOS.SYS
SDOS.SYS is an SDOS load record format file containing the memory
resident part of the operating system.
It is used by the boot
procedure to load a copy of the system from the disk into memory.
To simplify the boot process, certain restrictions are made on
the file structure of SDOS.SYS.
The data LCNs of SDOS must be numbered 1, 2, 3, ... etc., i.e., a
contiguously allocated
file.
This guarantees sequentially
increasing LSNs which makes the boot routine's job (of computing
LSNs) extremely simple. The header LCN of SDOS (if it has one)
may be anywhere on the disk; the boot routine need not look at it
(many boot routines never bother
reading the SDOS header
clusters).
Normally,
the SDOSDISKINIT program assigns a very
high LCN to the header cluster of SDOS.SYS.
The start address of SDOS.SYS is defined to be SYSCALL$ (:FB).
When debugging a (newly SYSGENed) I/O package, a convenient trick
is to modify (using BMP, the Binary Maintenance Program)
the
first load record (actually the start record) in the SDOS.SYS
file so the SDOS start address is the entry point to the ROM
debugger instead of :FB. With this change made, "booting" will
cause SDOS to get loaded, and the debugger will then gain
control. Patches may be made and breakpoints established, and
then SDOS can be started by causing a jump to :FB.
When
debugging is completed, the first load record should be restored
to its initial state.

117

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
DISKMAP. SYS
The DISKMAP.SYS file is used to keep track of clusters allocated
to disk files for that disk. Each disk cartridge or floppy
diskette has its own DISKMAP.SYS.
The file has one bit per cluster on the disk on which the file
resides.
An "on" bit indicates the cluster is allocated (or
contains a bad sector). An "off" bit indicates a free cluster,
available for allocation to a file. SDOS assumes that the entire
disk map can be contained in a single cluster, so if constraint 2
of LCNs is violated (see section on CLUSTERS), one needs to make
sure that NBPS*8*NSPC>=INT(NLSN/NSPC)
(otherwise the diskmap
doesn't fit into a single cluster). If constraint 2 is satisfied,
so is this condition (the 8 is the number of bits per byte).
Each byte of DISKMAP.SYS represents 8 clusters,
such that bit
number n (starting with 0, counting from the right) represents an
LCN such that (LCN mod 8)
n.
Bytes at logically higher byte
addresses within DISKMAP.SYS represent groups of LCNs with higher
values, so that if LBN (logical byte number), BITN (bit number)
represent a particular bit in the DISKMAP.SYS,
then that bit
corresponds to LCN=LBN*8+BITN (logical cluster number).
Cluster space allocation is done by taking the previously
allocated cluster number (to a file) as the starting point of a
search for a free cluster. Searches toward logical cluster number
o and NLCN-l are both made in an attempt to minimize the distance
between the cluster number (allocated to the preceding cluster in
the file)
and the new. Furthermore, an old cluster number of
:FFFF causes allocation starting at a random place within the
map.
The allocator prefers a forward search, and will not bother with
a backwards search if it can get a distance of 1 between the old
cluster number and the new.

118

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
DISK CLUSTER ALLOCATION MAP
MSB represents Logical Cluster #7

I
I
I
BYTE #0
#l

LSB corresponds to Logical Cluster #0

V
V
~ ---------------- -r<--Logical Clusters #0-7

1
1
1
1

1<--#8-15
1<--#16-23
1<--#24-31

1
1
1
1
1

1
1
1
1

1
1
1

One Cluster

I
I
v

/-------------- Bit # (NLCN-l) mod 8
V
1
(max legal cluster number)
1777"/'-;/"/'/'7/T/"I- -r
1

1/////////1
1
I
1//////////777/////////1
1//////////////////////1
I//////////////////////l

NOTE: Sector
Containing Bit
For NLCN-l is
Null Filled With
l's to Make it
Appear that the
Illegal LCNs
are allocated.

1//////////////////////1
1//////////////////////1
!///////ILLEGAL////////l
I///////CLUSTER////////I
I///////NUMBERS////////I

1//////////////////////1
1//////////////////////1
1////////////////////1/1
11//1/////1/1//1//1111/1
1----------------------1

A "I" bit --> cluster is busy
A "0" bit --> cluster is free (available).

119

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
ERRORMSGS.SYS (ERROR MESSAGE FILE) FORMAT:
The ERRORMSGS.SYS file is used by SDOS to convert 16 bit error
codes into English text messages for the operator.
The file must exist on the default disk, and the default disk
must be mounted, in order for SDOS to use the file (otherwise
SDOS merely prints "Error nnnnn").
The file is organized into two parts, and is sparse.
The first part of the file converts 16 bit error codes
string pointers into the file. The second part of the
contains the raw error message text.

into
file

The 16 bit error code is multiplied by 3, and used as a byte
index on the file to fetch a 3 byte relative index into the file.
The 3 byte index points to an ASCII error message string, ending
with a CR (:0D) character. The SDOS error routines do not print
the CR explicitly but use it only to decide where the end of the
error message is (see SYSCALL:DISPERROR). A 3 byte index value
of zero means "no message defined".
first 65536*3=196608 bytes of the file are reserved for this
lookup; since the number of error messages actually defined out
of the 65536 possible is very small, this region of the file is
sparsely allocated. The first text message starts in byte number
65536*3 of the file. This section of the file is dense.
1~e

New messages are added to the file by merely appending them to
the end, and adjusting the 3 byte pointer corresponding to the
error code to point to the old end of file.
The program SDOSERRORMAINT is used to maintain the contents
this file.
The file ERRORMSGBUILD.DO is a DO file used
initially construct this file.

of
to

ERROR MESSAGE NUMBER ASSIGNMENTS:
No Error
1
Operator Requested Attention
2-99
BASIC Compiler Runtime Errors
100-199
Errors Related to System Processors, Etc.
200-299
EDITor Errors
300-999
Application System Dependent Errors
1000-1999
SDOS / I/O Errors
2000-65535
Reserved

120

Software Dynamics

SDOS APPLICATION PROGRAMMERS' GUIDE
SECTION VI: SDOS CONSTRUCTION/FUNCTIONS
BUILDING A TURN-KEY APPLICATION SYSTEM
In many circumstances, the full generality of an SDOS development
system is not needed; a simple menu-driven application program
selector plus the applications is sufficient. This is useful in
an office environment because it reduces the training required of
the office personnel.
Only two things
system:

need

done

build a turn-key application

1) The boot process needs to be made automatic. This procedure
is hardware dependent and is not described further here.
2) The DEFAULTPROGRAM on an otherwise bootable SDOS disk needs to
be replaced by the menu-display program.
This program may
contain the entire application, or it may CHAIN to other
segments at the appropriate time. The other segments, on
completion,
will EXIT, which causes DEFAULTPROGRAM (the
menu-display program) to be reloaded, and the cycle repeats.
Note that the application program must set the time and date
itself by doing a WRITEB to the CLOCK$ device.
System development can still continue on a turn-key system if the
menu program has a way of chaining to SDOSCOMMANDS, or if a
regular development disk is inserted (just the boot part is
automatic).
If DEFAULTPROGRAM is replaced by a compiled BASIC 1.4 program,
the 1.4 program must be combined with a runtime package.

121

Software Dynamics

ASM/6800 1.3H2: 0000
10/22/84 14:06:58; Page 2; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
SDOS 1.1 DEFINITIONS FILE (AS OF 8/16/82)
2: *
3: *
4: SDOSVERSION
EQU
1.1 IN HEX
$11
0011
6:
IFUND
LISTDEFS
7:
0000
FIN
9:
10:
LISTDEFS
IF
0001
11:
ELSE
12:
0001
FIN
14:
15:
16: *
17:

0001
0000
0001
0000
00FB

The Definitions are broken into 3 parts:
18: *
A) THOSE NEEDED TO ASSEMBLE SDOS PROPER OR SYSTEM PROGRAMS
19: *
B) THOSE NEEDED TO BUILD AN I/O PACKAGE (A SUSSET OF "A")
20: *
C) THOSE NEEDED SY EVERYDAY USER PROGRAMS (A SUSSET OF "S")
21: *
22: *
23:
IFUND
SYSTEMDEFS
24:
DON'T WANT SYSTEM DEFINITIONS
25: SYSTEMDEFS
EQU
0
26:
FIN
27:
IFUND
IOPKDEFS
28:
29: IOPKDEFS
EQU
0
DON'T WANT I/O PACKAGE DEFINITIONS
30:
FIN
31:
EQU
$FS
JMP TO SDOS; RESERVED SYSCALL ENTRY POINT
32: SYSCALL$
33: *
CONTENTS OF ($FC.$FD) POINTS TO END OF USER RAM
34: *
CONTENTS OF ($FE.$FF) ARE SACRED; THEY SELONG TO THE ROM

ASM/6800 1.3H2: 0000
10/22/84 14:06:58; Page 3; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
SYSCALL$ OPCODE DEFINITIONS
36: *
37: *
ORG
0000
38:
o
0000 0001
39: SYSCALL:OPEN
RMB
1
OPEN FILE
0001 0001
40: SYSCALL:CREATE RMB
1
CREATE A NEW FILE
0002 0001
41: SYSCALL:CLOSE
CLOSE A FILE
RMB
1
0003 0001
42: SYSCALL:RENAME RMB
1
RENAME A FILE
0004 0001
43: SYSCALL:DELETE RMB
1
DELETE A FILE
0005 0001
44: SYSCALL:LOAD
1
RMB
LOAD AN OVERLAY
1
45: SYSCALL:CHAIN
CHAIN TO A FILE
0006 0001
RMB
0007 0001
46: SYSCALL:CREATELOG
RMB
1
CREATE THE LOG FILE
0008 0001
47: SYSCALL:CLOSELOG
RMB
1
CLOSE THE LOG FILE
0009 0001
48: SYSCALL:DISKDEFAULT
1
SELECT DEFAULT DISK DEVICE
RNB
000A 0001
RMB
1
READ ASCII BYTES FROM A FILE
49: SYSCALL:READA
000B 0001
50: SYSCALL:READB
RMB
READ BINARY BYTES FROM A FILE
1
000C 0001
51: SYSCALL:WRITEA RMB
WRITE ASCII BYTES TO A FILE
1
000D 0001
52: SYSCALL:WRITEB RMB
WRITE BINARY BYTES TO A FILE
1
000E 0001
PERFORM A CONTROL OPERATION ON A FILE/DEVICE
53: SYSCALL:CONTROL RMB
1
000F 0001
54: SYSCALL:STATUS RMB
READ FILE/DEVICE STATUS
1
0010 0001
55: SYSCALL:WAITDONE
1
WAIT FOR I/O ON CHANNEL TO COMPLETE
RMB
56: SYSCALL:EXIT
0011 0001
RMB
GIVE CONTROL BACK TO THE OPERATING SYSTEM
1
57: SYSCALL:ERROREXIT
0012 0001
EXIT TO SYSTEM WITH ERROR CODE
RMB
1
0013 0001
58: SYSCALL:SETERROR
1
REPORT AN ERROR TO THE SYSTEM
RMB
0014 0001
59: SYSCALL:GETERROR
READ BACK THE LAST ERROR CODE
RMB
1
DISPLAY ERROR MESSAGE CORRESPONDING TO LAS'
0015 0001
60: SYSCALL:DISPERROR
RMB
1
PREVENT USER PROGRAM FROM BEING KILLED
'0016 0001
61 : SYSCALL:KILLPROOF
RMB
1
ALLOW USER PROGRAM TO BE KILLED
RMB
0017 0001
62: SYSCALL:KILLENABLE
1
0018 0001
63: SYSCALL:DEBUG
RMB
CALL SYSTEM DEBUGGER
1
0019 01001
64: SYSCALL:ATTNCHECK
1
OPERATOR ATTENTION REQUEST CHECK
RMB
65: SYSCALL:ISCONSOLE
001A 000l
1
CHECK FOR CHANNEL 0 INPUT DEVICE = CONSOLE
RMB
1
PERFORM INTERLOCK FUNCTIONS ON OBJECTS
001B 0001
66: SYSCALL:INTERLOCK
RMB
001C 0001
67: SYSCALL:DELAY
RMB
1
DELAY FOR n 1/60ths OF A SECOND
001D 10001
68: SYSCALL:READLUN RMB
CONVERT LOGICAL UNIT NUMBER TO DEVICE NAME
1
001E 0001
69: SYSCALL:GETSERIALNUMBER RMB
1
GET PROCESSOR SERIAL NUMBER
70: SYSCALL:JOBCONTROL
RMB
1
CREATE/TEST/DESTROY OTHER JOBS
001F 0001

ASM/6800 1.3H2: 001F
10/22/84 14:06:58: Page 4: Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS . ASM
72: *
SYSCALL BLOCK DISPLACEMENTS
73: *
74: *
0000
75:
ORG
o
76: SCBLK:OPCODE
RMB
0000 0001
1
PRIMARY SYSCALL FUNCTION (OPEN, READ, ETC.)
1
0001 0001
77: SCBLK:WLEN
RMB
WAIT FLAG BIT (0=WAIT) AND SYSCALL BLOCK LENGTH (0 •.
78: SCBLK:PARAMS
RMB
PARAMETER BYTES TO OPCODE (SECONDARY OPCODE, CHANNEL
2
0002 0002
79: SCBLK:WRBUF
2
POINTER TO WRITE DATA BUFFER
RMB
0004 0002
2
80: SCBLK:WRLEN
RMB
NUMBER OF BYTES IN WRITE DATA BUFFER
0006 0002
2
81: SCBLK:RPLEN
RMB
LENGTH OF REPLY (RESULT OF SYSCALL)
0008 0002
POINTER TO READ DATA BUFFER (WHERE RESULT GOES)
2
82: SCBLK:RDBUF
RMB
000A 0002
CEILING ON SIZE OF REPLY (READ DATA BUFFER)
2
000C 0002
83: SCBLK:RDLEN
RMB
OTHER PARAMETERS FOR SYSCALL: UP TO 127-12 BYTES
000E 0000
84: SCBLK:DATA
o
RMB
END OF SYSCALL BLOCK: ASSERT SCBLK:WLEN[l .• 7]=SCBLK:
o
85: SCBLK:END
RMB
000E 0000
86: *
SYSCALL PARAMETER LIST DEFINITIONS
87: *
88: *
EQU
SCBLK:PARAMS
CHANNEL NUMBER
0002
89: OPEN:CHANNEL
SCBLK:WRLEN
FILE NAME LENGTH
EQU
0006
90: OPEN:LENGTH
POINTER TO FILE NAME
91: OPEN:NAMEP
EQU
SCBLK:WRBUF
0004
OPEN SYSCALL BLOCK LENGTH
92: OPEN:SCLEN
EQU
SCBLK:DATA
000E
93: *
SCBLK:PARAMS
CHANNEL NUMBER
94: CREATE:CHANNEL EQU
0002
SCBLK:WRLEN
FILE NAME LENGTH
95: CREATE: LENGTH
EQU
0006
EQU
SCBLK:WRBUF
POINTER TO FILE NAME
96: CREATE:NAMEP
0004
EQU
SCBLK:DATA
CREATE SYSCALL BLOCK LENGTH
97: CREATE:SCLEN
000E
98: CREATE:FILESIZE EQU
SCBLK:DATA
4 BYTE FILE SIZE INITIAL ALLOCATION
000E
99: CREATE:FILESIZESCLEN
EQU
CREATE:FILESIZE+4
END OF CREATE BLOCK WITH FIL
0012
100: *
0002
101: CLOSE: CHANNEL
EQU
CHANNEL NUMBER
SCBLK:PARAMS
102: CLOSE:SCLEN
EQU
0003
SCBLK:PARAMS+l CLOSE SYSCALL BLOCK LENGTH
103: *
104: RENAME: CHANNEL EQU
SCBLK:PARAMS
CHANNEL NUMBER
0002
EQU
NEW FILE NAME LENGTH
0006
105: RENAME: LENGTH
SCBLK:WRLEN
EQU
POINTER TO NEW FILE NAME
106: RENAME: NAMEP
SCBLK:WRBUF
0004
107: RENAME:SCLEN
EQU
SCBLK:DATA
RENAME SYSCALL BLOCK LENGTH
000E
108: *
EQU
SCBLK:WRLEN
FILE NAME LENGTH
109: DELETE: LENGTH
0006
EQU
SCBLK;WRBUF
POINTER TO NAME
0004
110: DELETE:NAMEP
111: DELETE:SCLEN
EQU
SCBLK:DATA
DELETE SYSCALL BLOCK LENGTH
000E

ASM/6800 1.3H2: 000E
10/22/84 14:06:58; Page 5; Form 1
SDOSUSERDEFS.ASM
0006
0004
000E
0006
0004
000E
0006
0004
000E
0002
0006
0004
000E
0002
0003
000A
000C
0008
000E
OOOE
0012

112: *
113: LOAD: LENGTH
114: LOAD:NAMEP
115: LOAD:SCLEN
116: *

EQU
EQU
EQU

SCBLK:WRLEN
SCBLK:WRBUF
SCBLK: DA'l'A

LENGTH OF FILE NAME
POINTER TO FILE NAME
LOAD SYSCALL BLOCK LENGTH

117: CHAIN: LENGTH
EQU
EQU
118: CHAIN:NAMEP
119: CHAIN: SCLEN
EQU
120: *
121: CREATELOG:LENGTH
122: CREATELOG:NAMEP EQU
123: CREATELOG:SCLEN EQU
124: *
125: CLOSELOG:SCLEN EQU
126: *
127: DISKDEFAULT:LENGTH
128: DISKDEFAULT:NAMEP
129: DISKDEFAULT:SCLEN

SCBLK:WRLEN
SCBLK:WRBUF
SCBLK:DATA

LENGTH OF FILE NAME
POINTER TO FILE NAME
CHAIN SYSCALL BLOCK LENGTH

130: *
131: READA:CHANNEL

EQU
READA:LMFLAG
EQU
READA:BUFFERP
EQU
READA:MAXCOUNT EQU
READA:ACTUALCOUNT
READA:SCLEN
EQU
RW:POSITION
EQU
138: RWPOSITION:SCLEN
132:
133:
134:
135:
136:
137:
139:

0002
000A
000C
0008
000E
0002
0004
0006
0008
0002

*** SDOS 1.1 DEFINITIONS ***

140:
141:
142:
143:
144:
145:
146:
147:
148:
149:
150:
151:

READB:CHANNEL
EQU
READB:BUFFERP
EQU
READB:MAXCOUNT EQU
READB:ACTUALCOUNT
READB:SCLEN
EQU

WRITEA: CHANNEL
WRITEA:BUFFERP
WRITEA:COUNT
WRITEA:SCLEN

WRITEB:CHANNEL

EQU
SCBLK:WRLEN
LENGTH OF FILE NAME
SCBLK:WRBUF
POINTER TO FILE NAME
SCBLK:DATA
CREATELOG SYSCALL BLOCK LENGTH
SCBLK:PARAMS
EQU
EQU
EQU

CLOSELOG SYSCALL BLOCK LENGTH

SCBLK:WRLEN
SCBLK:WRBUF
SCBLK:DATA

FILE NAME LENGTH
FOINTER TO FILE NAME
DISKDEFAULT SYSCALL BLOCK LENGTH

CHANNEL NUMBER
SCBLK:PARAMS
SCBLK:PARAMS+l LINE MODE FLAG BYTE
SCBLK:RDBUF
BUFFER POINTER
SCBLK:RDLEN
BYTE COUNT
EQU
SCBLK:RPLEN
ACTUAL NUMBER OF BYTES TRANSFERRE
READA SYSCALL BLOCK LENGTH
SCBLK:DATA
SCBLK:DATA
READ/WRITE IMPLICIT FILE POSITION
EQU
RW:POSITION+4
END OF R/W SYSCALL WITH IMPLICIT
CHANNEL NUMBER
SCBLK:PARAMS
BUFFER POINTER
SCBLK:RDBUF
BYTE COUNT
SCBLK:RDLEN
EQU
SCBLK:RPLEN
ACTUAL NUMBER OF BYTES TRANSFERRE
SCBLK:DATA
READB SYSCALL BLOCK LENGTH

EQU
EQU
EQU
EQU

SCBLK:PARAMS
SCBLK:WRBUF
SCBLK:WRLEN
SCBLK:RPLEN

CHANNEL NUMBER
BUFFER POINTER
BYTE COUNT
WRITEA SYSCALL BLOCK LENGTH

EQU

SCBLK:PARAMS

CHANNEL NUMBER

ASM/6800 1.3H2: 000E
*** SDOS 1.1 DEFINITIONS ***
10/22/84 14:06:58; Page 6; Form 1
SDOSUSERDEFS.ASM
SCBLK:WRBUF
BUFFER POINTER
0004
152: WRITEB:BUFFERP EQU
EQU
0006
153: WRITEB:COUNT
SCBLK:WRLEN
BYTE COUNTER
EQU
SCBLK:RPLEN
WRITEB SYSCALL BLOCK LENGTH
0008
154: WRITEB:SCLEN
155: *
SCBLK:PARAMS
CHANNEL NUMBER
156: CONTROL:CHANNEL EQU
0002
EQU
SCBLK:PARAMS+l CONTROL CODE
157: CONTROL: CODE
0003
SCBLK:WRBUF
CONTROL SYSCALL BLOCK MINIMUM LENGTH
EQU
158: CONTROL:SCLEN
0004
EQU
o
DISPLACEMENT INTO WRITE BUFFER FOR CONTROL DATA
159: CONTROL: DATA
0000
160: *
161: STATUS,CHANNEL EQU
SCBLK:PARAMS
CHANNEL NUMBER
0002
EQU
SCBLK:PARAMS+l STATUS SELECTOR CODE
0003
162: STATUS:CODE
SCBLK:RDBUF
POINTER TO STATUS TARGET BUFFER
163: STATUS:BUFFERP EQU
000A
SCBLK:RDLEN
SIZE OF STATUS READ-BACK BUFFER
000C
164: STATUS:MAXCOUNT EQU
EQU
SCBLK:RPLEN
ACTUAL # STATUS BYTES READ
165: STATUS:ACTUALCOUNT
0008
EQU
SCBLK:DATA
STATUS SYSCALL BLOCK MINIMUM LENGTH
000E
166: STATUS:SCLEN
167: STATUS: DATA
EQU
o
DISPLACEMENT INTO READ BUFFER FOR READ-BACK STATUS
0000
168: *
EQU
SCBLK:PARAMS
CHANNEL NUMBER
169: WAITDONE:CHANNEL
0002
170: WAITDONE:SCLEN EQU
SCBLK:PARAMS+l WAITDONE SYSCALL BLOCK LENGTH
0003
171: *
EXIT SYSCALL BLOCK LENGTH
EQU
SCBLK:PARAMS
172: EXIT:SCLEN
0002
173: *
174: ERROREXIT:CODE EQU
ERROR CODE NUMBER
SCBLK:PARAMS
0002
175: ERROREXIT:SCLEN EQU
SCBLK:WRBUF
ERROREXIT SYSCALL BLOCK LENGTH
0004
176: *
177: SETERROR:CODE
EQU
SCBLK:PARAMS
ERROR CODE NmlBER
0002
SETERROR SYSCALL BLOCK LENGTH
178: SETERROR:SCLEN EQU
SCBLK:WRBUF
0004
179: *
180: GETERROR:BUFFERP
EQU
SCBLK:RDBUF
POINTER TO ERROR READ-BACK AREA
000A
181: GETERROR:MAXCOUNT
EQU
SCBLK:RDLEN
SHOULD BE 2
000C
0008
182: GETERROR:ACTUALCOUNT
EQU
SCBLK:RPLEN
SHOULD BE RETURNED AS 2
183: GETERROR:SCLEN EQU
SCBLK:DATA
GETERROR SYSCALL BLOCK LENGTH
000E
184: *
SCBLK:PARAMS
185: DISPERROR:SCLEN EQU
0002
DISPERROR SYSCALL BLOCK LENGTH
186: *
187: KILLPROOF:SCLEN EQU
SCBLK:PARAMS
KILLPROOF SYSCALL BLOCK LENGTH
0002
188: *
189: KILLENABLE:SCLEN
0002
EQU
SCBLK:PARAMS
KILLENABLE SYSCALL BLOCK LENGTH
190: *
EQU
191 : DEBUG:SCLEN
SCBLK,PARAMS
DEBUG SYSCALL BLOCK LENGTH
0002

ASM/6800 1.3H2: 000E
10/22/84 14:06:58; Page 7; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
192: *
0002
193: ATTNCHECK:SCLEN EQU
ATTNCHECK SYSCALL BLOCK LENGTH
SCBLK:PARAMS
194: *
0002
ISCONSOLE SYSCALL BLOCK LENGTH
195: ISCONSOLE:SCLEN EQU
SCBLK:PARAMS
196: *
0002
197: INTERLOCK:FUNCTION
EQU
SCBLK:PARAMS
INTERLOCK FUNCTION
0004
198: INTERLOCK:BUFFERP
EQU
SCBLK:WRBUF
POINTER TO OBJECT
0006
199: INTERLOCK:COUNT EQU
SCBLK:WRLEN
LENGTH OF OBJECT
0008
200: INTERLOCK:SCLEN EQU
SCBLK:RPLEN
INTERLOCK SYSCALL BLOCK LENGTH
201: *
0002
202: DELAY:PERIOD
EQU
SCBLK:PARAMS
DELAY PERIOD
0004
203: DELAY:SCLEN
DELAY SYSCALL BLOCK LENGTH
EQU
SCBLK:WRBUF
204: *
205: *READLUNNAME:LUN
EQU
SCBLK:PARAMS
LOGICAL UNIT NUMBER
206: *READLUNNAME:BUFFERP
EQU
WHERE TO READ NAME BACK
SCBLK:RDBUF
SCBLK:RDLEN
NAXIMUM LENGTH OF REPLY
207: *READLUNNAME:MAXCOUNT
EQU
208: *READLUNNAME:ACTUALCOUNT
EQU
SCBLK:RPLEN
ACTUAL NAME LENGTH
000E
209: READLUNNAME:SCLEN
EQU
SCBLK:DATA
READLUN SYSCALL BLOCK LENGTH
210: *
000A
211: GETSERIALNUMBER:BUFFERP EQU
SCBLK:RDBUF
POINTER TO SERIAL NUMBER REPLY BUI
SIZE OF BUFFER
000C
212: GETSERIALNUMBER:MAXCOUNT
EQU
SCBLK:RDLEN
SIZE OF REPLY
0008
213: GETSERIALNUMBER:ACTUALCOUNT
EQU
SCBLK:RPLEN
SCBLK:DATA
000E
214: GETSERIALNUMBER:SCLEN
EQU
MINIMUM SIZE OF BLOCK
215: *
JOB CONTROL FUNCTION
0002
216: JOBCONTROL:FUNCTION
EQU
SCBLK:PARAMS
POINTER TO JOB CAPABILITY
EQU
217: JOBCONTROL:BUFFERP
SCBLK:WRBUF
0004
SIZE OF CAPABILITY
SCBLK: WRLEN
EQU
218: JOBCONTROL:COUNT
0006
MAXIMUM LENGTH OF REPLY
SCBLK:RDLEN
EQU
000C
219: JOBCONTROL:MAXCOUNT
ACTUAL SIZE OF CAPABILITY
220: JOBCONTROL:ACTUALCOUNT EQU
SCBLK:RPLEN
0008
SCBLK:WRLEN+2
JOBCONTROL SYSCALL MINIMUM BLOCK
0008
221: JOBCONTROL:SCLEN
EQU

ASM/6800 1.3H2: 000E
10/22/84 14:06:58; Page 8; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
EQU
0003
223: LSN:SIZE
# BYTES OCCUPIED BY AN LSN
3
0002
224: LCN:SIZE
EQU
2
# BYTES OCCUPIED BY AN LCN
225: *
226: *
STANDARD STATUS SYSCALL SUB-CODES
227: *
228:
ORG
0
0000
0000 0001
229: SC:GETPOS
RMB
1
GET BYTE POSITION
0001 0001
RMB
230: SC:GETCOL
1
GET COLUHN COUNT
RMB
0002 0001
231: SC:GETEOF
1
GET EOF FLAG
0003 0001
GET FILE SIZE
232: SC:GETFILESIZE RMB
1
RMB
0004 0001
233: SC:GETTYPE
1
GET DEVICE TYPE AND CHARACTERISTICS
0005 0001
RMB
234: SC:GETPARAMS
1
GET DEVICE SPECIFIC PARAMETERS
235:
0010
236: SC:DEVICESPECIFICOP
EQU
BASE FOR DEVICE SPECIFIC STATUS CODES
$10
237: *
238: *
STANDARD CONTROL SYSCALL SUB-CODES
239: *
ORG
0
0000
240:
POSITION TO THIS PLACE IN THE FILE
0000 0001
241: CC:POSITION
RMB
1
DUMP BUFFERS TO THE DEVICE (MAINLY FOR DISK)
242: CC:DUMPBUFFERS RMB
1
0001 0001
243:
244, CC:DEVICESPECIFICOP
EQU
0010
$10
BASE FOR DEVICE-SPECIFIC CONTROL CODES
245: *
246: *
STANDARD INTERLOCK SYSCALL SUB-CODES
247: *
0000
248:
ORG
o
0000 0001
249: IC:CREATE
RMB
CREATE AN OBJECT IDENTIFIER
1
0001 0001
250: IC:DESTROY
RMB
DESTROY AN OBJECT IDENTIFIER
1
0002 0001
251 : IC:RESET
RMB
RESET OBJECT REFERENCE LIST
1
0003 0001
252: IC:LOCK RMB
LOCK AN OBJECT OR BLOCK UNTIL AVAILABLE
1
0004 0001
253: IC:RELEASE
RMB
RELEASE A LOCKED OBJECT
1
LOCK AN OBJECT OR ERROR IF UNAVAILABLE
254: IC:TEST RMB
0005 0001
1

ASM/68QJQJ 1.3H2: QJQJ05
1QJ/22/84 14:QJ6:58; Page 9; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
256: *
VIRTUAL TERMINAL SPECIFIC STATUS REQUESTS
257: *
258: *
QJQJIQJ
259:
ORG
SC:DEVICESPECIFICOP
QJQJIQJ QJQJ01
26QJ: SC:GETPROFILE
RMB
1
GET CURRENT DEVICE PROFILE NAME
QJQJ11 QJQJQJl
261: SC:GETACTCOL
RMB
1
GET ACTIVATION COLUMN
262:
QJQJ2C
263:
ORG
SC:DEVICESPECIFICOP+$lC (DON'T ASKIII)
QJQJ2C QJQJQJl
1
GET LINE FLAGS
264: SC:GETLINEFLAGS RMB
265: *
266: *
DISK FILE SPECIFIC STATUS REQUESTS
267: *
QJQJIQJ
268:
ORG
SC:DEVICESPECIFICOP
QJQJIQJ QJQJQJ1
1
READ BACK CREATION DATE OF FILE IN CLOCK FORMAT
269: SC:GETFILEDATE RMB
QJQJ11 QJQJQJl
27QJ: SC:GETFILEPROT RMB
1
READ BACK FILE PROTECTION BYTE
271: *
272: *
DISK DEVICE STATUS REQUESTS
273: *
QJQJ1QJ
274:
ORG
SC:DEVICESPECIFICOP
QJ01QJ 01'101
275: SC:GETLASTBADLSN
RMB
1
READ BACK LSN THAT CAUSED DRIVER A PROBLEM
GET DEVICE ERROR (HISTORY) STATISTICS
QJ011 0001
RMB
1
276: SC:GETERRORSTATS
277: *
278: *
VIRTUAL TERMINAL SPECIFIC CONTROL OPERATIONS
279: *
0QJ10
28QJ:
ORG
CC:DEVICESPECIFICOP
001QJ QJQJ01
281: CC:ECHO RMB
1
TURN ECHO ON
RMB
1
TURN ECHO OFF
0011 0001
282: CC:NOECHO
QJQJ12 1'101'11
RMB
1
SET TTY IDLES
283: CC:IDLES
QJ013 QJ0QJl
1
SET TTY TABS
284: CC:TABS RMB
QJ014 0QJQJ1
1
DECLARE ACTIVATION SET
285: CC:SETACTBLOCK RMB
QJ015 QJQJQJl
RMB
1
CLEAR INPUT BUFFER
286: CC:CLRINPUT
0016 QJ0QJl
287: CC:CLROUTPUT
RMB
1
CLEAR OUTPUT BUFFER
QJ017 0QJQJ1
RMB
1
.
SET TIMEOUT PERIOD FOR READA
288: CC:SETREADTIMEOUT
0QJ18 QJ0QJ1
RMB
1
DECLARE DEVICE PROFILE
289: CC:SETPROFILE
01'119 QJQJQJ1
29QJ: CC:ALTERPROFILE RMB
1
ALTER MALLEABLE DEVICE PROFILE
QJ01A QJ0QJl
RMB
1
PUT LINE IN TYPE-AHEAD BUFFER
291: CC:WRITEEDITLINE
00113 QJ0QJ1
292: CC:SETFIELDSIZE RMB
1
DECLARE WIDTH OF INPUT FIELD
RMB
1
DECLARE DEVICE WIDTH AND DEPTH
QJ01C 0QJ01
293: CC:SETPARAMS
001D QJQJQJl
294: CC:ACTIVATIONCK RM13
1
CHECK FOR READA DATA READY
295: CC:WRAP RMB
001E 0QJl2ll
1
ALLOW FORE- AND BACK-WRAP

ASM/6800 1.3H2: 001F
10/22/84 14:06:58; Page 10; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
296: CC NOWRAP
001F 0001
RMB
1
DISALLOW FORE- AND BACK-WRAP
297: CC COLORING
0020 0001
RMB
DECLARE AND SET FOREGROUND COLORING
1
0021 0001
RMB
DECLARE AND SET BACKGROUND COLORING
298: CC BACKGROUND
1
299: CC KILLPROOF
RMB
KILLPROOF VT DEVICE
0022 0001
1
300: CC:KILLENABLE
KILLENABLE VT DEVICE
0023 0001
RMB
1
301: *
302: *
DISK FILE SPECIFIC CONTROL OPERATIONS
303: *
ORG
CC:DEVICESPECIFICOP
0010
304:
0010 0001
305: CC:SETFILEDATE RMB
1
SET CREATION DATE OF FILE (USE CLOCK FORMAT)
0011 0001
306: CC:SETFILEPROT RMB
1
SET FILE PROTECTION BYTE
307: CC:SETFILESIZE RMB
0012 0001
1
SET SIZE OF FILE
308: CC:POSITIONTOEND
0013 0001
RMB
1
POSITION TO END OF FILE
309: *
310: *
DISK DEVICE SPECIFIC CONTROL OPS
311: *
0010
312:
ORG
CC:DEVICESPECIFICOP
0010 0001
RMB
1
U~LOCK THE DISK DEVICE FOR WRITING
313: CC:UNLOCKDISK
1
DISMOUNT THE DISK
314: CC:DISMOUNTDISK RMB
0011 0001
RMB
1
SET MAP ALGORITHM NUMBER FOR DRIVE
0012 0001
315: CC:SETMAPALGORITHM
316: CC:MULTISECTORREAD
RMB
1
READ MULTIPLE SECTORS
0013 0001
RMB
1
WRITE MULTIPLE, ACCORDING TO SYSCALL EXTENSI
317: CC:MULTISECTORWRITE
0014 "001
0015 0001
318: CC:FORMAT
RMB
1
FORMAT DISK
0016 0001
RMB
1
WAIT FOR CONTROLLER OPERATION COMPLETE
319: CC:WAITDONE

ASM/6800 1.3H2: 0016
10/22/84 14:06:58; Page 11; Form;
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
RETU> ',";D STATUS DISPLACEMENTS
321: *
322: *
0000
323:
eRG
0
0000 0004
324: STATUS:DIST
RMB
4
PO.3ITION IN DISK FILE
325:

0000
0000 0001
0000
0000 0001
0f.H.l0
0000 0001

0000
0000 0002
eU0::: 00100
0002 0002
0004 0002
0006 0002
0000
0000 0004
0000
0000 0'003

0000
0000 0003
0003 0001
0004 0001
0005 0001

0000
0000 0001

326:
327:
328:
329:
330:
331:
332:
333:
334:
335:
336:
337:
338:
339:
340:
341:
342:
343:
344:
345:
346:
347:
348:
349:
350:
351:
352:
353:
354:
355:
356:
357:
358:
359:

ORG
STATUS:COLUMN

ORG
STATUS:EOFFLAG

0
RMB

COLUMN NUMBER

0
RMD

END OF FILE FLAG

0
RMB

DEVICE TYPE DATA FOR DIRECTORIED DISK

0
RMB
RMB
RMB
RMB
RMB

0
2
2
2

NU~BER

ORG
0
STATUS:FILESIZE RMB

SIZE OF DISK FILE IN BYTES

RMB

ORG
STATUS:DEVTYPE

ORG
STATUS:NBPS
STA'rus: NSPC
STATUS:NSPT
STATUS:NTPC
STATUS: NCYL

NUr1BER OF
OF
NUMBER OF
NUMBER OF
NUMBER OF

BYTES PER SECTOR
SECTORS PER CLUSTER FOR DISK FILE
SECTORS PER TRACK
TRACKS PER CYLINDER
CYLINDERS

ORG
0
STATUS:LASTBADLSN

*
*
*

SC:GETFILEDATE REPLY BUFFER

ORG
0
STATUS:DATETICKS
STATUS:DATEDAY RMB
STATUS:DATEMONTH
STATUS:DATEYEAR RMB

*
*
*

LSN OF LAST BAD SECTOR ON DISK

RMB
1
RMB
1

24 BITS OF TICKS SINCE MIDNITE
3
BCD VALUE OF DAY (1. .31)
BCD VALUE OF MONTH (1. .12)
1
BCD VALUE OF YEAR MOD 100 (00.99)

SC:GETFILEPROT REPLY BUFFER

ORG
STATUS: PROT

0
RMB

PROTECTION BYTE FROM FILE

ASM/6800 1.3H2: 0000
10/22/84 14:06:58; Page 12; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
SC:GETERRORSTATS REPLY BUFFER
361: *
362: *
0000
363:
ORG
0
364: STATUS SEEKERRCNT
RMB
2
# SEEK ERRORS SINCE MOUNT
0000 0002
365: STATUS SEEKERRSTS
16 BITS OF LAST "SEEK" STATUS IN ERROR
RMB
2
0002 0002
# WRITE ERRORS SINCE MOUNT
366: STATUS WRITEERRCNT
0004 0002
2
RMB
367: STATUS:WRITEERRSTS
RMB
2
16 BITS OF LAST "WRITE" STATUS IN ERROR
0006 0002
368 STATUS:READERRCNT
RMB
2
# READ ERRORS SINCE MOUNT
0008 0002
369 STATUS:READERRSTS
RMB
16 BITS OF LAST "READ" STATUS IN ERROR
2
000A 0002
3
24 BITS OF # DRIVER OPERATIONS SINCE MOUNT
370 STATUS:OPSCOUNT RMB
000C 0003
371 STATUS:ERRLSN
RMB
LSN:SIZE
LSN CAUSING ANY SOFT OR HARD ERROR
000F 0003

ASM/6800 1.3H2: 000F
10/22/84 14:06:58; Page 13; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
373: *
CC:POSITION WRITE BUFFER
374: *
0000
375:
ORG
o
0000 0004
376: CONTROL:DIST
RMB
4
VALUE OF POSITIONING COMMANDS
377: *
378: *
CC:SETFILEDATE WRITE BUFFER
379: *
0000
380:
ORG
0
0000 0003
381: CONTROL:DATETICKS
24 BITS OF TICKS SINCE MIDNITE
RMB
3
0003 0001
382: CONTROL:DATEDAY RMB
1
BCD VALUE OF DAY (1 .• 31)
0004 0001
383: CONTROL:DATEMONTH
BCD VALUE OF MONTH (1 .. 12)
RMB
1
13005 0001
384: CONTROL:DATEYEAR
RMB
1
BCD VALUE OF YEAR MOD 100 (00 .. 99)
385: *
386: *
CC:SETFILEPROT WRITE BUFFER
387: *
0000
388:
ORG
o
0000 0001
389: CONTROL: PROT
PROTECTION BYTE FOR FILE
RMB
1
390: *
391: *
CC:SETMAPALGORITHM WRITE BUFFER
392: *
0000
393:
ORG
0
0000 01302
394: CONTROL:MAPALGORITHM
PARAMETER BLOCK FOR SET MAP ALGORITHM CALL
RMB
2
395: *
396: *
JOB CONTROL SUB-CODES
397: *
398:
0000
ORG
o
399: JC:CREATE
CREATE A NEW JOB
0000 0001
RMB
1
TEST TO SEE IF A JOB IS DONE
0001 0001
400: JC:TESTDONE
RMB
1
RMB
DESTROY A JOB
0002 0001
401: JC:DESTROY
1

ASM/6800 1.3H2. 0002
10/22/84 14.06:58; Page 14; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
403: *
404: *
SYSTEM-DEFINED ERROR CODES
405: *
00100
406:
ORG
0
0000 0001
407: ERR:NONE
RHB
1
CODE 0 --> NO ERROR
0001 0001
408: ERR:ATTENTION
RIm
1
OPERATOR REQUESTED ATTENTION
409:
0064
410:
ORG
le0
0061 0001
411: ERR:FATALCONPILE
RMB
1
COMPILATION OR ASSEMBLY HAD FATAL ERRORS
412: ERR:WARNINGCOMPILE
0065 0001
1
COMPILATION OR ASSEMBLY HAD NON-FATAL ERRORS
RMB
413: ERR:BADCMDFORMAT
1
BAD COMMAND FORMAT (SYNTAX ERROR!)
0066 0001
RMB
0067 0001
414: ERR:CANTGOTO
RMB
CAN'T DO GO TO FROM CONSOLE:
1
0068 0001
415: ERR:ABNORMALSTOP
RMB
1
PROGRAM TERMINATED ABNORMALLY
416: ERR:NOTENUFMEM RMB
NOT ENOUGH MEMORY TO EXECUTE COMMAND
0069 0001
1
417: *
418: *
SDOS ERROR CODES
419: *
420: *
ERROR CODES FOR SDOS ARE RESERVED BETWEEN 1000-1999
421: *
422: *
03E8
423:
ORG
1000
424: ERR: BOOTCKSUMFAIL
03E8 0001
RMB
1
BOOT SECTOR DISKINFO CHECK SUM FAILED
END OF FILE HIT
425: ERR: EOFHIT
RMB
1
03E9 0001
03EA 0001
426: ERR:FILEISOPEN RMB
A FILE IS OPEN DURING DISMOUNT REQUEST
1
427: ERR:NODEBUGGER RMB
03EB 0001
NO DEBUGGER TO CALL!
1
03EC 0001
1
BAD POSITIONING REQUEST
428: ERR:BADPOSITION RMB
03ED 0001
429: ERR:NBPCTOOBIG RMB
NUMBER OF BYTES PER CLUSTER >= 65536
1
NO DISK MAP, CAN'T ALLOC OR FREE
03EE 0001
430: ERR: NODISKMAP
RMB
1
431: ERR: NOMATCHFCB RMB
03EF 0001
NO MATCHING FILE CONTROL BLOCK FOUND
1
03F0 0001
R11B
NO "DEFAULTPROGRAM" ON THIS DISK
1
432: ERR: NODEFAULTPROGRAM
03F1 0001
RMB
1
433:
**** UNUSED ****
03F2 0001
434: ERR:FILEWRTPROT RMB
1
FILE IS WRITE PROTECTED
435: ERR:FILENOTFOUND
RMB
1
FILE NOT FOUND
03F3 0001
03F4 0001
436: ERR:ILLEGALLCN RMB
LCN OUT OF RANGE
1
03F5 0001
437: ERR:BADFNAMESIZE
RMB
1
LENGTH OF FILE NAME > 16 CHARACTERS
438: ERR:NEWFILEEXISTS
1
NEW FILE ALREADY EXISTS!
RMB
03F6 0001
439: ERR:NODISKSPACE RMB
1
DISK SPACE EXHAUSTED
03F7 0001
03F8 0001
440: ERR: LCNWASNTALLOCATED
1
LCN ENCOUNTERED BY FREECLUSTERS WASN'T ALLOC
RMB
RAN OUT OF FCBS (*SYSTEM*)
03F9 0001
441: ERR: NOFREEFCBS RMB
1
442: ERR:WRONGFILESY3TEM
03FA 0001
RMB
1
FILE SYSTEM INCOMPATIBLE WITH THIS VERSION 0

ASM/6800 1.3H2: 03FB
10/22/84 14;06:58; Page 15; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
03FB 0001
443: ERR:FILEINCREATE
RMB
FILE IS BEING CREATED
1
03FC 0001
444: ERR:DISKMOUNTED RMB
1
DISK IS MOUNTED, CAN'T CHANGE MAPALGORITHM
03FD 0001
445: ERR:CANTOPENMUSTCREATE RMB
1
MUST CREATE TO OPEN OUTPUT ONLY DEVICE
446: ERR:NOERRORMSGS RMB
03FE 0001
1
NO $ERRORMESSAGES FILE ON DRIVE 0
03FF 0001
447: ERR:BADFILENAME RMB
1
FILENAME DOESN'T START WITH A-Z OR $
0400 0001
448: ERR:ILLFILESIZE RMB
1
ILLEGAL FILE SIZE SPECIFICATION (SYNTAX OR OVFLOW)
449: ERR: HCSICTOOSMALL
0401 0001
RMB
1
HEADER CLUSTER NOT INITZED FOR RDCN FETCH
1
NOT ENOUGH DISKBUFFER POOL (*SYSTEM*)
0402 0001
450: ERR: NOTENOUGHPOOL
RMB
0403 0001
451: ERR:PWRFAILDISKF
1
DISK FILE HANDLERS DON'T IMPLEMENT POWER F.
RMB
0404 0001
1
CAN'T LOAD THAT - WRONG FORMAT
452: ERR:NOTALOADFILE
RMB
0405 1"001
RMB
1
FILE VERSION NUMBER HAS NO DIGITS OR IS >2
453: ERR:BADpILEVERSION
0406 0001
454: ERR:CHTOOBIG
RMB
1
CHANNEL # IS TOO BIG
0407 0001
455: ERR:CHBUSY
RMB
1
CHANNEL IS ALREADY OPEN
456: ERR:CLOSED
0408 0001
RMB
1
CHANNEL IS ALREADY CLOSED
457: ERR:ILLEGALSYSCALL
0409 0001
1
ILLEGAL SYSCALL #
RMB
040A 0001
458: ERR:ILLDEVICEOP RMB
1
ILLEGAL DEVICE OPERATION
040B 0001
1
CAN'T RENAME TO DIFFERENT DEVICE
RMB
459: ERR:RENAMEDEVICE
040C 0001
460: ERR:BADLOADRECORD
RNB
LOAD RECORD FORMAT ERROR
1
040D 0001
461: ERR: NOTENOUGHROOM
1
PROGRAM TOO BIG TO LOAD
RMB
462: ERR:ILLLSN
RMB
1
ILLEGAL LSN PASSED TO PHYSICAL DISK DRIVERS
040E 0001
1
DIRECTORY.SYS DIRECTORY ENTRY IS DAMAGED
040F 0001
463: ERR:DIRECTORYDAMAGED
RMB
1
INPUT BUFFER OVERFLOW IN THE DRIVERS
0410 0001
464: ERR:IBUFOVERFLOW
RMB
0411 0001
465: ERR:PROGRANKILLED
RMB
1
PROGRAM KILLED BY OPERATOR
0412 C001
466: ERR:DEVICETIMEDOUT
1
DEVICE TIMED OUT
RMB
SECTORSIZE IS NOT A POWER OF 21
0413 0001
1
467: ERR:SECTORSIZE2 RMB
1
... WHILE DOING AN EXIT OR CHAIN (*SYSTEM*)
0414 0001
RMB
468: ERR:SYSTEMCROAKED
0415 0001
469: ERR:DISKREAD
DISK READ ERROR
RMB
1
0416 0001
DISK WRITE ERROR
470: ERR:DISKWRITE
RMB
1
0417 0001
471: ERR:DISKSEEK
RMB
1
DISK SEEK ERROR
0418 0001
472: ERR: DSKWRTPROT RMB
1
DISK IS WRITE PROTECTED
1
DISK DEVICE IS SOFTWARE WRITE LOCKED
473: ERR:DISKWRITELOCKED
0419 0001
RMB
474: ERR:SDOSCKSUM
RMB
1
SDOS GOT A KNIFE IN THE RIBSI
041A 0001
041B 0001
NLSN >= 2~24, ILLEGAL
475: ERR:NLSNGE224
RMB
1
R~1B
1
CLUSTER SIZE IS TOO SMALL TO SUPPC
041C 0001
476: ERR:CLUSTERSIZELIMITSFILE
1
SYSCALL BLOCK IS TOO SMALL FOR SPECIFIED ~
477: ERR:SYSCALLTOOSHORT
041D 0001
RMB
1
READ BUFFER SPECIFIED BY SYSCALL IS TOO Sf
041E 0001
RMB
478: ERR:RDBUFTOOSMALL
479: ERR:WRBUFTOOSMALL
1
WRITE BUFFER SPECIFIED BY SYSCALL IS TOO ~
041F 0001
RMB
1
NO SUCH DEVICE IN THIS CONFIGURATIJN
480: ERR: NOSUCHDEVICE
RMB
0420 21001
1
DEVICi; HARDWARE DID NOT RESPOND RE"'SONABL~
481: ERR:DEVICEERRORED
RMB
0421 0001
482: ERR:MUSTBEDISK RMB
1
MUST SELECT DeSK DEVICE
0422 0001

ASM/6800 1.3H2: 0423
10/22/84 14:e6:58; Page 16; Form 1
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
483, ERR: NOTOPENTOCONSOLE
0423 0001
RMB
1
CHANNEL 0 IS NOT OPEN TO CONSOLE DEVICE
484: ERR:DEVICENOTREADY
0424 0001
RMB
1
DEVICE IS NOT READY
0425 0001
485: ERR:TIMENOTSET RMB
1
TIME NOT SET TO NON-ZERO DAY/MONTH!
NO SUCH LOGICAL UNIT NUMBER
0426 0001
486: ERR: NOSUCHLUN
RMB
1
487: ERR:ZEROSTARTADDRESS
0427 0001
RMB
1
OBJECT FILE HAS NO (ZERO) START ADDRESS
0428 0001
488: ERR: NOSUCHPROGRAM
RMB
1
NO SUCH PROGRAM EXISTS (ERROR ISSUED BY LOAD
RMB
0429 0001
489: ERR,OLDFILEEXISTS
1
OLD FILE BY SAME NAME ALREADY EXISTS
RMB
1
*** UNUSED ***
042A 0001
490:
042B 0001
491: ERR:ALLOC0CLUSTERS
RMB
"ALLOC" CALL WITH REQUEST FOR 0 CLUSTERS I
1
042C 0001
FILE WAS DELETED BUT NOT CLOSED BEFORE RENAM
492: ERR:FILEALREADYDELETED RMB
1
493: ERR:PRINTERNOTREADY
RMB
1
PRINTER IS NOT READY
042D 0001
494: ERR:INPUTTIMEOUT
042E 0001
RMB
INPUT TIMED OUT, ABORTED
1
495: ERR:ENDCFMEDIUM RMB
042F 0001
1
END OF MEDIUM ON DEVICE
0430 0001
PROGRAM SELF-TEST CHECKSml FAILED
496: ERR,SELFTESTCKSUM
RMB
1
ZERO TIME OUT BLOCKS IN I/O PKG NOT LEGAL
0431 0001
497: ERR: NOTIMEOUTBLKS
RMB
1
THIS CPU HAS WRONG SERIAL NUMBER TO RUN PROG
RMB
1
0432 0001
498: ERR:SERIALNOWRONG
SUCH
KEY
EXISTS IN INDEX
499: ERR:NOSUCHKEY
RMB
1
NO
0433 0001
500, ERR: DUPLICATEKEY
KEY ALREADY EXISTS IN INDEX
RMB
1
0434 0001
KEY BRANCHING FACTOR IS TOO SMALL
501: ERR:BRANCHFACTORSIZE
RMB
1
0435 0001
THIS COPY OF SDOS NOT REGISTERED WITH SD YET
0436 0001
502: ERR:SDOSNOTREGISTERED
RMB
1
1
LAST FILE LOADED HAS DIFFERENT DECRY
503: ERR:DECRYPTIONKEYSDONTMATCH
0437 0001
RMB
504: *
WRONG DISK TECHNOLOGY (DENSITY, SIDES, ETC.)
EQU
1902
076E
505: ERR,WRONGDISKTYPE
506: *
507: *
VIRTUAL TERMINAL DRIVER ERROR CODES
508: *
509:
0771
ORG
1905
510, ERR: IOINPROGRESS
LAST REQUEST HAS NOT COMPLETED
0771 0001
RMB
1
1
DCB OPEN TO ANOTHER PROCESS
511: ERR: BUSYFORANOTHERPROCESS
RMB
0772 0001
512: ERR: ACTIVATIONNOTINBUFFER
1
RDBUF DOES NOT HOLD ACTIVATION
0773 0001
RMB
513: ERR:BADFIELDWIDTH
0774 0001
RMB
1
CRT SCREEN FEILD SPECIFICATION IS TOO WIDE
514: ERR:ACTIVATIONRECEIVED RMB
ACTIV. REC'D PER CC:ACTIVATIONCK
0775 0001
1
TIMED INPUT PERIOD EXPIRED
1
0776 0001
515 : ERR:TIMEDINpUTEXPIRED
RMB
DEVICE PROFILE NOT FOUND
1
0777 0001
516: ERR:PROFILENOTFOUND
RMB
0778 0001
517: ERR:PROFILENOTMALLEABLE RMB
1
DEVICE PROFILE NOT MALLEABLE
RMB
1
*** RESERVED ***
518:
0779 0001
519: *
04B0
520:
ORG
1200
SDOS/MT ERROR CODES
521, ERR:BADREADBUF RMB
04B0 0001
1
SYSCALL REPLY BUFFER NOT WITHIN USER SPACE
522: ERR:BADWRITEBUF RMB
1
SYSCALL WRITE BUFFER NOT WITHIN USER SPACE
04Bl 0001

~SM/6800

1.3H2: 04B2
10/22/84 14:06:58; Page 17; Form 1
*** SDOS 1.1
SDOSUSERDEFS.ASM
04B2 0001
523 : ERR:RDBUFTOOBIG RMB
1
04B3 0001
524: ERR:WRBUFTOOBIG RMB
1
04B4 0001
525 : ERR: NOTENOUGHCHANNELS
RMB
04B5 0001
526: ERR: NOTUNDERTIMESHARE
RMB
04B6 0001
527 : ERR:MTNOROOM
RMB
1
04B7 0001
528: ERR:MTBADCONFIG RMB
1
04B8 0001
529: ERR:ALREADYLOCKED
RMB
04B9 0001
530: ERR: NOSUCHOBJECT
RMB
04BA 0001
531: ERR: NOTLOCKED
RMB
1
04BB 0001
RMB
532: ERR:OBJECTDESTROYED
04BC 0001
533: ERR: LOCKRESET
RMB
1
04BD 0001
534: ERR:IMPLEMENTATIONLIMITREACHED
535: ERR:ILLEGALINTERLOCKFUNCTION
04BE 0001
536: ERR:MEMORYMGMTFAIL
04BF 0001
RMB
537: ERR: NOMOREJOBS R~IB
04C0 0001
1
04Cl 0001
538: ERR:ILLEGALJOBCONTROL
RMB
04C2 0001
539: ERR:CAPABILITYFAILURE
RMB
04C3 0001
RMB
1
540: ERR:JOBKILLED
541: ERR: JOBCOMPLETED
04C4 0001
RMB

DEFINITIONS ***
SYSCALL REPLY BUFFER > 255 BYTES
SYSCALL WRITE BUFFER > 255 BYTES
1
AVAILABLE I/O CHANNELS EXHAUSTED
1
FUNCTION NOT AVAILABLE UNDER SDOS/MT
NOT ENOUGH ROOM TO RUN SDOS/MT
INCORRECT CONFIGURATION FOR SDOS/MT
1
INTERLOCK OBJECT IS ALREADY LOCKED
1
BAD CAPABILITY GiVEN
INTERLOCK OBJECT IS NOT LOCKED
1
INTERLOCK OBJECT DESTROYED WHILE WAITING I
INTERLOCK OBJECT WAS RESET WHILE WAITING FOR IT
RMB
1
CAN'T HANDLE MORE INTERLOCK OBJEC':
RMB
1
ILLEGAL INTERLOCK FUNCTION REQUES c
1
SDOS/MT INTERNAL MEMORY MANAGEMENT FAILURI
ALL AVAILABLE JOBS ARE BUSY NOW
1
ILLEGAL JOB CONTROL REQUEST
1
CAPABILITY DOES NOT HAVE RIGHTS TO PERFORI
THIS JOB HAS BEEN KILLED BY ANOTHER
1
JOB SUCCESSFULLY COMPLETED

ASM/6800 l.3B2: 04C4
10/22/84 14:06:58; Page 18; Form 2
*** SDOS 1.1 DEFINITIONS
SDOSUSERDEFS.ASM
1: *
DEVICE TYPE DEFINITIONS
0000
0000 0001
0001 0001
0002 0001
0003 0001
0004 0001
0005 0001
0006 0001
0007 0001
0008 0001
00fil9 0001
000A 0001
000B 0001

0000
e00e e001

0e00
00e0 0002
0002 00fil2
0004 0002
000/\ 001212
0000
e0e0 0e01
0e01 00e1
0002
0002 0eel

3:
4:
5:
6:
7:
8:
9:
Ie:
11:
12:
13:
14:
15:
16.
17:
18,
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:

ORG
DVT¥P.FILE
DVTYP.DISK
DVTYP.STAPE
DVTYP.D'rAPE
DVTYP.CONSOLE
DVTYP.PRINTER
DVTYP.SERIALOUT
DVTYP.SERIALIN
DVTYP.PAROUT
DVTYP.PARIN
DV'!'YP.DUMMY
DVTYP.C,(,OCK

*
*
*
*
*
*

o
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB
RMB

1
1

1
1
1

FILE (MANAGED BY SDOS)
DISK DEVICE (MANAGED BY SDOS)
SERIAL TAPE DEVICE
DIRECTORIED TAPE DEVICE
CONSOLE (HUMAN'S INTERFACE)
LINE PRINTER DEVICE
ILL-DEFINED

1
1
1
1
1

PARALLEL OUT
PARALLEL IN
BLACK HOLE FOR DATA BYTES
CLOCK DEVICE

DEVICE TYPE DATA DISPLACEMENTS

ORG
DVTYP : TYPE

*
*
*

***

DEVICE TYPE

DEVICE-TYPE SPECIFIC DATA

ORG
DVDAT:NBPS
DVDAT:NSPT
DVDAT.NTPC
DVDAT,NCYL

'RMB
"
RMB
RMB
RMB

DISK DEVICE SPECIFIC DATA
NUMBER OF BYTES PER SECTOR
2
NUMBER OF SECTORS PER TRACK
2
NUMBER OF TRACKS PER CYLINDER
2
NUMBER OF CYLINDERS
2
CONSOLE/PRINTER DEVICE SPECIFIC DATA
1
LINE WIDTH IN CHARACTERS
1
PAGE DEPTH (DEFAULT DEPTH FOR PRINTERS)
(0=INFINITY)

ORG
DVDAT:WIDTH
DVDAT:DEPTH

RMB
RMB

ORG
DVDAT:NSPC

DVDAT:NBPS+2
RMB
1

*
*

(DISK) FILE DEVICE SPECIFIC DATA
NUMBER OF SECTORS PER CLUSTER

ASM/6800 1.3~2: 0002
10/22/84 14:06:58; Page 19; Form 2
*** SPOS 1.1 DEFINITIONS ***
SDOSU6ERDEFS.ASM
41: **********************************************************************
13010
42: FILESYSTEMVERSION
EQU
$10
VERSION 1.0 OF FILESYSTEM FORMAT
43: ********************************************************************
44: *
USEFUL ERROR-HANDLING OPCODES
45: *
46: *
0C39
47: OKRTS
EQU
"CLC,RTS"
$0C39
0039
48: ERRORRTS
EQU
$0D39
"SEC,RTS"
49: *
FUNNY VALUES TO MAKE DATA STORAGE ALLOCATION USES MORE CLEAR
59: *
51: *
52: IGNORED EQU
SO I CAN MARK PLACES AS IGNORED
o
o
SO I CAN MARK PLACES AS CHANGED
53: CHANGED EOU
54: *
LOCATIONS 0-7 ARE TREATED AS PART OF TASK'S CONTEXT
55: *
AND SAVED DURING A CONTEXT SWITCH
56: *
57: *
DEFINEO TEMPORARIES
58. *
USEO TO PUSH (X) ONTO STACK IN INTERRUPTABLE WAY
59: *
FOR USE BY TASK-LEVEL SUBROUTINES
60: *
€il: *
62:
$0
0000
ORG
63: TEMPX
0000 00"2
RMB
2
ANY SUBROUTINE MAY STEP ON THISIII
64: TEMP
EQU
0000
TEMP X
FOR CONVENIENCE
EQU
0000
€iS: TEMPA
TEMPX
TEMP STORAGE FOR A REGISTER
66: TEMPB
TEMPX+l TEMP STORAGE FOR B REGISTER
0001
EQU
67:

(lJ040
0001

pROTECTION BITS FOR DIR:PROTECTION
68: *
69: *
EQU
PROTECT AGAINST WRITES
70: PROT: :WRITE
$40
EQU
PROTECT AGAINST BACKING UP
71: PROT:: BACKUP
$1

ASM/6800 1.3H2: 0000
10/22/84 14:06:58; Page 20; Form 2
*** SDOS 1.1 DEFINITIONS ***
SDOSUSERDEFS.ASM
ASCII CHARACTER SET
73: *
74: *
A@ NULL
75: ASCII: NULL
EQU
0000
o
AA START OF HEADING
76: ASCII: SOH
EQU
1
0001
AB START OF TEXT
2
0002
77: ASCII: STX
EQU
AC END OF TEXT
0003
78: ASCII: ETX
EQU
3
AD END OF TRANSMISSION
79: ASCII:EOT
EQU
4
0004
AE ENQUIRY (WRU- WHO ARE YOU)
80: ASCII: ENQ
EQU
5
0005
AF ACKNOWLEDGE
6
0006
81: ASCII:ACK
EQU
AG BELL
7
82: ASCII: BEL
EQU
0007
AH BACKSPACE
EQU
8
0008
83: ASCII: BS
AI HORIZONTAL TAB
EQU
9
0009
84 : ASC II : HT
'J LINE FEED
EQU
85: ASCII:LF
$A
000A
AK VERTICAL TAB
EQU
$B
000B
86: ASCII: VT
AL FORM FEED
87: ASCII: FF
$C
EQU
000C
AM CARRIAGE RETURN
88: ASCII:CR
EQU
$D
000D
AN SHIFT OUT
89: ASCII:SO
EQU
$E
000E
AO SHIFT IN
90: ASCII:SI
$F
EQU
000F
Ap DATA LINK ESCAPE
91: ASCII:DLE
$10
EQU
0010
AQ DEVICE CONTROL 1
EQU
$11
92: ASCII: DCl
0011
AR DEVICE CONTROL 2
EQU
$12
0012
93: ASCII: DC2
AS DEVICE CONTROL 3
94: ASCII: DC3
$13
EQU
0013
AT DEVICE CONTROL 4
$14
95: ASCII: DC4
EQU
0014
AU NEGATIVE ACKNOWLEDGE
96: ASCII: NAK
$15
EQU
0015
AV SYNCHRONOUS IDLE
EQU
$16
97: ASCII: SYN
0016
AW END OF TRANSMISSION BLOCK
$17
EQU
98: ASCII: ETB
0017
AX CANCEL
EQU
$18
99: ASCII:CAN
0018
Ay END OF MEDIUM
EQU
$19
100: ASCII:EM
0019
'z SUBSTITUTE
EQU
$lA
101: ASCII: SUB
001A
A[ ESCAPE
EQU
$lB
102: ASCII: ESC
001B
A\ FILE SEPERATOR
EQU
$lC
103: ASCII:FS
001C
'J GROUP SEPERATOR
EQU
$lD
104: ASCII:GS
001D
RECORD SEPERATOR
105: ASCII:RS
EQU
$lE
001E
UNIT SEPERATOR
$lF
EQU
106: ASCII:US
001F
SPACE (WORD SEPERATOR)
$20
EQU
107: ASCII:SPACE
0020
DELETE (RUBOUT)
EQU
$7F
108: ASCII:RUBOUT
007F
TO MASK OFF ALL BUT 7 LEGAL ASCII BITS
EQU
$7F
109: ASCII:MASK
007F

ASM/6800 1.3H2: 00DD
10/22/84 14:06:58; Page 36; Form 1
sdvtllcdefs.asm
319: *
320:
0002
321: ..
322:
0002

0002 0002
0004 0002
0006 0002
0008
0002

0030
0030 0001
0031 0001
0032 0001
0033 0001
0034 0001

0030
0030 0001
0031 0001
0032 0001
0033 0001
0001
0034 0001
0001
0035 0001
0036 0001
00FF

323:
324:
325:
326:
327:
328:
329:
330:
331:
332:
333:
334:
335:
336:
337:
338:
339:
340:
341:
342:
343 :
344:
345:
346:
347:
348:
349:
350:
351:
353:
354:
355:
356:
357:

Virtual Terminal Driver definitions
Extensions to the Configuration Table

set
org

cnfg:timeoutlist+2

cnfg:vtprofiles
cnfg:vtdebug
cnfg:mtprims

rmb
rmb
rmb

2
2
2

cnfg:vtsize

equ
org

VT User calls

Control calls

head of profile chain
interrupt level ep to debugger
-> MT primitives vector

org
rmb
rmb
rmb
rmb
rmb

cc:writeanowait
cc:settimeshare
cc:setexception
cc:writebnowait
cc:stoptimeshare

cc:devicespecificop+$20
I
write ascii, do not block
1
set the timeshare flag
1
set/clear exception flags
1
write binary, do not block
1
disable timesharing

Status calls

sc:attentionck
sc:statusck
sc:gettimeshare
sc:allstatus
ifund
sc:getlineflagshint

org
sc:devicespecificop+$20
rmb
1
check fo£ attention (s/u)
rmb
1
check for change of status (s/u)
rmb
I
check for SDOS/MT running (MT)
rmb
I
check for change of status on any
sc:getlineflagshint ; kluge around SDOSllDEFS
rmb
1
returns line flags w/o clearing

else
fin
sc:getfreecount
sc:getdatacount

rmb
rmb

I
I

returns dcb:tlroom
returns dcb:tldata

sysdependent

equ

$ff

system dependent

ASM/6800 1.382: 0036
10/22/84 14:06,58; Page 37; Form 1
sdvtllcdefs.asm
00FF
358: lineflags

Virtual Terminal Driver definitions
equ

sysdependent

ASM/6830 1.3H2: 0013
Virtual Terminal Driver definitions
10/22/84 14:06:58; Page 39; Form 1
sdvtllcdefs.asm
Errors specific to SDOS/MT
399: *
400:
401: ••
0002
set
*
04CE
402:
1230
org
403:
SDOS/MT is already running
404: err:sdosmta1readyrunning
1
04CE 0001
rmb
O,lCF 0001
1
port status has changed since last
405: err:statushaschanged
rmb
0.Dn 0001
SDOS/MT primitives not defined in
406: err:sdosmtprimsmissing
rmb
1
407:
0002
408:
org
4139:

***

410:
END
;«Supplied By ASM»
End of Source File Encountered.

INDEX

:00
:01
:02
:03
:04
:05
:06
:07
:08
:09
:0A
:0B
:0C

:0D
:0E
:0F
:10
:11

:12
:13
:14
:15
:16
:17
:18
:19
:lA
:lB
:lC
:ID
:lE
:IF
: 7F

:FB
:FFFF

30
30
30
30
30
30
30
31
31
31
31
31
31
31
31
31
32
32
32
32
32
32
32
32
33
33
33
33
33
33
33
34
34
117

100,102,103,104,118
16,59,60,63
18,31,32,33
80
18
?
35
@
104
ALTERPROFILE:CLIDLES
22
21
ALTERPROFILE:CLLEN
21
ALTERPROFILE:CLSEQ
ALTERPROFILE:COLDISP
21
ALTERPROFILE:CPIDLS
21
ALTERPROFILE:CPLEN
21
21
ALTERPROFILE:CPSEQ
22
ALTERPROFILE:EEOLIDLES
ALTERPROFILE:EEOLLEN
22
ALTERPROFILE:EEOLSEQ
22

ALTERPROFILE:ROWDISP
21
ASCII
9,40
15
ASCII Activation Set
ASCII Character Set
19
63
ASCII Data Write
1
ASCII Format
14
ASCII Mode
27
ASCII Text String
15,17,38
ASCII:CR
ASCII: ESC
16
ASCII:FF
15
17,21
ASCII:LF
ASC II : RUB OUT
16,19,26
ASM
90
72
Abnormal Cease Execution
19
Abnormal Condition
52
Abort SDOS
108
Accidental Eraser
Activation Character 14,16,19,22,23,29
30,33
16
Activation Not In Buffer
24
Activation Received
97
Address Space
7
Allocated Disk Space
Alternate Roman Character Set
25
Apparent Size
10
Application Program 14,46,102,115,121
97
Application Suite
5
Assembly Language
Assembly Language Program
90
Assembly Language Programmer
5
2
Associated 1/0 Channel
Asynchronous WRITEA
36
36
Asynchronous WRITEB
109
Automatic Expansion
Available Disk Space
11
5
BASIC
121
BASIC 1. 4
30,31
BASIC Breakpoint
31
BASIC Execution
45,90
BCC
108
BCD
BCS
45,90
117
BMP
117
BOOT
98,115
BOOT Sector
11,108,112,113
BOOT.SYS
BOOT.Sys
113
115
BOOT: CHECKSUM
115
BOOT:CREATIONDATE
108,115
BOOT:DIRLSN

BOOT:DISKID
115
BOOT:FILESYSTEMVERSION
114,115
BOOT:MAPALGORITHM
114
10,114
BOOT:MIDALLOC
BOOT:MINALLOC
114
BOOT: NSPC
114
Background Color
28,31
Backspace
31
Bad Field Width
23
Baud Rate
28
Beep
26,31
Being CREATEd
7
Binary Data
61
Binary Data Read
3
Binary Data Write
3,64
Binary Fomat
1
Binary Maintenance Program
117
Binary Mode
14
Binary Operation
14
Bit Number
118
Bit, Off
118
Bit, On
118
Blind Write Mode
12
Blinking
25
Boot Cluster
108
Boot Disk, SDOS
116
Boot Process
121
Boot ROM Routine
113
Boot Routine
113,114,115,117
Boot Sector
113
Boot, Successful
116
Booting the System
99
Bootstrap Program
113
Breakpoint
90,117
Buffer Address
42
Buffer Size
61
Buffer Space
38
Buffer, Read
59
Buffer, Read-Back
59,63
Buffer, Reply
2,40,68,75
Buffer, Unfilled
61
Buffer, Write
2,40,65
Bug
55
Byte
6
Byte Transfer, Speed Up
60
Byte, Data
6
CAPS LOCK
30,35
CC:ACTIVATIONCK
14,20,22,23,24,31
CC:ACTIVATIONCK Control Call
22
2l,28
CC:ALTERPROFILE
CC:BACKGROUND
15,25,26

CC:CLRINPUT
19
CC:CLROUTPUT
19
CC:COLORING
25,26,28
CC:DISMOUNT
13
CC:DISMOUNTDISK
12
CC:DUMPBUFFERS
8,12,15,18,65,67
CC:ECHO
15,18
CC:FORMAT
12
CC:IDLES
18,28
CC:KILLENABLE
15,26
CC:KILLPROOF
26
CC:NOECHO
18,22
CC:NOWRAP
18
CC:POSITION
8,17,18,27,65,66
CC:POSITIONTOEND
8
19
CC:SETACTBLOCK
CC:SETACTIVATION
310
CC:SETBAUDRATE
28
CC:SETEXCEPTION
26
CC:SETFIELDSIZE
22,23,31
CC:SETFILEDATE
8
CC:SETFILEPROT
8
CC:SETFILESIZE
8,1108
CC:SETMAPALGORITHM
12,13
CC:SETOUTPUTTIMEOUT
26,28
CC:SETPARAMS
23
CC:SETPROFILE
210,27
CC:SETREADTIMEOUT
210
CC:SETTIMESHARE
36
CC:STOPTIMESHARE
36
CC:TABS
19,28
CC:UNLOCKDISK
11,12
CC:WRAP
18
CC:WRITEANOWAIT
36
CC :WRITEBNOWAIT
36
CC:WRITEEDITLINE
22
78,91,116,121
CHAIN
CHANGED Option
1108
21,22
CLEAR Sequence
1
CLOCK
121
CLOCKS
CLOCK:
9
CLOCK: Device Driver
38
CLOSE
3,11,12,15,18,38,41,57,71
CLOSE Channel
27
CLOSE I/O Channel
410
CLOSEing A Disk File
7
310
CNFG: VTDEBUG=IO
COLCNT
3
CONSOLE
69
CONSOLE:
14,610,69,76,810

CONSOLE: Tab
19
3,12,38,41,55
CONTROL
CONTROL Call, Installation-Dependent
14
CONTROL Code
13
8,65
CONTROL Operation
CONTROL SYSCALL
65
CREATE 2,3,6,10,11,15,18,19,38,55,108
CRT
1,3,32,35,66
CRT Driver
63,66
17
CRT Screen
CRT, Dumb
25
82
Capability
Cause Program to Quit
78
Change Text Appearance
25
Change of Mode, Ascii
16
Change of Mode, Binary
16
Changing Input Mode
16
10,47,50,59,68
Channel
Channel 0
60,63,68,76,81
Channel 0 is Open; But Not to the
81
Console
7
Channel Closed
3,48,55
Channel Number
Channel Number, I/O
11,48
10,49
Channel, I/O
55
Channel, Log
Channel, Open
6
Character Default
18
32,34
Character Delete
59
Character, Printing
109,111
Circular Search
Clear Display
31
35
Clear Screen
3,48,52
Close
54
Close I/O Channel
51
Closed
100,101,102,108,112
Cluster
Cluster (LCN)
100
Cluster Allocated
118
Cluster Number
100,103
Cluster Number Allocated
107
119
Cluster Number, Illegal
9,100,107,114
Cluster Size
118
Cluster Space Allocation
Cluster, Free
118
Cluster, Minimum Number
114
100
Cluster, Unallocated
116
Code Number
25,28
Color
66
Column

Column Count
2,59,61,63,64
Column Number
19,21,22
27
Column Number, Output
29
Column Position
Column of Exit
23
Command Interpreter
44,72,78,81
Command, DO
55
55
Command, LOG
Common Data Base
10
Computer Serial Number
116
Configuration Dependent
91
Console
81
56
Console I/O
55
Console Session Copy
Console:
80
Contiguous Memory
93
Contiguous Space
6
3
Control
15,16,17,19,30
Control Character
36
Control Function
Control Function, Multiuser
36
Control Operation
18
Control Operation, Common
65
Control Operation, Device Specific 65
Control Transfer
54,79,94,113
54
Control, Load
Control, Transfer
54
2
Copy
48
Crash, System
Create
3
Creation Date
9
22
Cursor
23
Cursor Control Key
17
Cursor Location
14,15,18,20,21,22,27
Cursor Position
30,32,33,35,66
Cursor Position Sequence
21
99,114
Cylinder
99
Cylinder 0
101
Cylinder Boundary
104
DBLCN
104
DBLSN
90
DEBUG
44,71,72,74,77,121
DEFAULTPROGRAM
3,8,11,15,38,108
DELETE
69
DEPTH
108,110
DIR:CREATIONDATE
107
DIR:FILENAME
107,109,110
DIR:FILESIZE
110
OIR:HCN
103,107,110
DIR:HCSIC

Default Disk
6
Default Set
20
Definition, SYSCALL Opcode
40
Delay
84
Delete
3
Delete, Implied
48
Demonstration Copy
116
Depth
20
Design Deficient Terminal
25
Device
I
Device Baud Rate
24
Device Driver
68,102
Device Driver Characteristic
5
Device Driver Routine
1
Device Name
58
Device Name DISK:
58
Device Profile
23
Device Profile Block
15,26
Device Time Out
15,18,29
Device Type
3,9,69
Device, Input
3
Device, Output
3
Device-Dependent Limitation
1
Device-Independent I/O
1,6
Device-Specific Operation
3,15
Digital to Analog Converter
1,3
Directoried Device
47
Directory
7,8,49,51,107,108,109
Directory Entry
105,110,111
Directory Header Cluster
III
Directory Search Scheme
III
Directory Size
109
Directory Structure
110
Disk Cluster Allocation Map
119
Disk Content
11
Disk Device Driver
11,13
Disk File
1,6,7,8,10,49,63,64,66,69
101,118
6,10,102
Disk File Driver
92
Disk File Management
102
Disk File Structure
Disk File Structure, SDOS
98
113
Disk 1D
113,115
Disk Identification
112
Disk Map
92,96,99
Disk Read
10,13
Disk Sector
Disk Sector Buffer
92
Disk Sector Buffer Pool
10
Disk Sector Drl.ver
114
Disk Sector I/O Driver
13

Disk Size, Physical
102
Disk Space
6,100
Disk Space Allocated
10
Disk Space Free
7
Disk Storage
100
Disk Validity
115
Disk Waitdone
92
Disk Write
92,99
Dismount
11,12,65
Dismount Tab
65
Displacement, Column Number
21
Displacement, Row Number
21
Display
66
23,27,35
Display Depth
Display Inhibiting
22
Display Line
30
Display Mode
25
Display Width
23,27
Display-Oriented Application
14
Display-Oriented Operation
14
Double-Height
25
Double-Width
25
Dump Buffer
3
EDIT
90
EFERROR
44
3,63,64,66,94
EOF
ERR:ALREADYLOCKED
83
80
ERR:ATTENTION
ERR:IMPLEMENTATIONLIMITREACHED
83
ERR: LOCKRESET
83
ERR: NOSUCHOBJECT
82,83
ERR: NOTLOCKED
83
ERR:OBJECTDESTROYED
82
75,77
ERROREXIT
ERROREXIT Syscall
74
ERROREXIT, No Debugger
79
ERRORMSGBUILD.DO
120
ERRORMSGS.SYS
72,76,120
ESC
33
EXIT
41,71,74,75,77,121
79
EXIT from IDB
EXIT to System
4121
16
Echoing
29
Echoing Disabled
16
Editing
65
Eject
Encrypted File
96
Encrypted Load Record
93
Encrypted Object File
97
Encryption
1.1,52,54,116
Encryption Key
97

End of File
2,4,9,10,27,33,69
End of File Condition
16
End of Line
32
End-User Name
116
Erase on Terminal
33
Erase to End of Line
30
Erase to End of Line Sequence
22
Error
6,11,12,47,59,61,63,66,70,71
Error Code
41,43,44,74,75,120
Error Code, ERROREXIT
72
Error Exit
52,54,80,81
Error Handling
43,72
Error Handling Philosophy
44
Error Message Display
76
Error Message File
120
Error Message Number Assignment
120
Error Message Routine
120
Error Message, New Addition
120
Error Message, Raw Text
120
Error Recovery
43
Error Statistic
13
Error, BASIC
43
Error, Bad File Name
47,48,50,53,54
Error, Bad File Name Size
53,54
Error, Can't Open, Must Create
47
Error, Can't Rename to a Different
Device
50
Error, Channel Already Open
56
Error, Channel Busy
47
Error, Channel Not Open 50,57,60,62,63
64
Error, Channel is Already Closed
49
Error, Channel is Busy
48
Error, Channel is Not Open At All
81
Error, Checksum
53
46
Error, Common
Error, Device Not Ready
62,63,64
Error, Device Timed Out
62,63
Error, Device is Not a Disk
58
Error, Disk Read Error
62
63,64
Error, Disk Space Exhausted
63,64
Error, Disk Write Error
Error, Dismount
12
76
Error, Display Processing
Error, EDIT
43
Error, EOF Hit
60,62
Error, End of File
11
Error, End of File (EOF)
60,61
Error, End of File Hit (EOF)
53
Error, File Not Found
54
Error, File is Being Created
48,50

Error, File is Delete Protected
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,
Error,

48,50
51
48,50
46
49
64
56
53
52
50
79
56

File is Write Protected
Hardware Specific
Illegal Channel Number
Illegal Device Operation
Illegal File Name
Load Record Format
Loading
New File Exists Already
No Debugger
No Disk Space
No SERIALNUMBER.SYS File
116
54
No Start Address
47,48
No Such Device
No Such File
47,51,53
53,54
Not a Load File
78
Program Killed
8,13
Read
Read-Back Buffer Too Short
75
43
SDOS
13
Seek
77,78
Syscall Block Too Short
84,85
Error, Syscall Length Too Short
75
Error, Syscall Too Short
79
8,13
Error, Write
Error, Write Protected
12
Error, Wrong Serial Number
116
41
Execution Time
43
Exit, Error
43
Exit, Successful
10
FCB
FCB Side Effect
10
FCBs
12
FILE
69
FILESIZE
3
FORMAT
12
FREEZE OUTPUT
30,32,35
Failure, Syscall
74
Field Boundary
23
Field Content
33
Field Definition
23
23
Field Exit
33
Field Location
23
Field Width Size
1,49,50,51,59,61,64,66,68,69,77
File
93,100,102,103,120
11
File Access Time
File Beginning
2
File Column Number
9

File Control Block
10
File Extended
9
File Model
1
File Name
47,52,58,107,109
File Name Size
55
File Name, Create
7
File Name, Device
6
File Name, Disk
6
File Name, Duplicate
7
File Position
8,61,63,64,66,93
File Position, Current
61
File Protection
7,8
File Protection Bit
108
File Size
1,6,7,8,9,64,101
File Size Computation, Maximum
69
File Size, Apparent
6,107
File Structure Protection
11
File Structure, Check Out
11
File Structure, Initialize
11
File Structure, Repair
11
File Structure, SDOS
105
File System
99
File System Version
114
File, ASCII
4
File, Automatic Expansion
3
File, Cluster Structure
103
File, Current Position
68
File, Delete
6
File, Dense
6
File, Disk
3,48
File, End of
61
File, Extend
8
File, Implied Position
4
File, Load Format
52
File, New
48
File, Open
10
File, Position
4
File, Read
4,6,47
File, Share
10
File, Sparse
6,8
File, Update
6
File. Updated
47
File. Write
4
File, Write Protected
6,48
Forespace
31
Form Character
35
Formatting Disk
115
Forwarding Logic
39
Free Cluster Pool
8
Free Disk Space
49
Free Space
7,8

Function Code
39
79
G Command
3,4
GETCOLCNT
3,4
GETEOF
74
GETERROR
3
GETTYP
104
HBBUF
104
HCSIC
104
HSLSN
28
Hanging the System
Hard Copy
33
27,32,35
Hard Copy Device
18,30
Hard Copy Terminal
91,121
Hardware Dependent
Header Buffer
104
Header Cluster 100,102,103,104,105,107
117
Header Cluster Initialized Count
103
Header Cluster Structure
106
103
Header Cluster, Garbage
Header Clustor Sector Initialized
Count
107
107
Header Logical Cluster
18
I/O
1,4,15,41,47,48,51,54,55
I/O Channel
59,61,63,68,69,70,71
I/O Channel Number
1,3,65
I/O Channel, Log
57
I/O Channel, Two Open
2
I/O Device
1,67
I/O Driver
12
I/O Mode Used
16
I/O Package 1,20,27,77,80,91,92,99,117
I/O Package Dependency
79
I/O Space
92
IC:CREATE
82
IC:DESTROY
82
IC:LOCK
83
IC:RELEASE
83
IC:RESET
83
IC:TEST
83
79,90,92
IDB
INTERLOCK "Object"
82
20
IOVTDPBS.ASM
21
Idle
17
Idle Character
18
Idle Count
28
Idle Trigger Character
16,18,19,21
Illegal Device Operation
22,24
15,38,51,114
Illegal Operation

Imaginary Terminal
14
Implementation Restriction
83
Implementing SYSCALLs
46
Implied Position
18
Implied Position Call
17
30,32,34
Input Buffer
Input Buffer Space Available
22
Input Buffer, Clear
33
Input Byte Stream to Application
14
Input Erased
30
Input Field
30,32
Input Line
19
14,15,16,22,24
Input Line Buffer
Input Line Buffer Empty
27
Input Line Editing
15
Input Line, Last
32
Input Ring Buffer
28
Integer, Parenthesized
6
25
Intensity
Interaction Between Independent
Operations
1
Interlock Object
82
17
Interpretation
Invalid Capability
83
Invalid Object
82
Invalid Response
116
KILLDISABLE
78
KILLENABLE Mode
77
KILLENABLE Status
77
KILLPROOF
30,78
24,37
KILLPROOF Flag
Keyboard Entry
14
Keyboard Input
14,24
LBN
104
LCN
100,105,111,112,118
LCN of SDOS
117
LCN, Legal
100
41
LEN
41
LENgth
69
LINEPRINTER
59
LMFLAG
40,54,91
LOAD
52
LOADER FORMAT
1,14
LPT:
54
LRU Queue
LSB
119
99,104,108,114
LSN
99,113
LSN 0
13
LSN, Soft Error
9
Last Data Byte
Last Operation on Terminal
16

Latency Times
114
Left End of Field
26
Legal Operation
40
Line
59
Line Buffer Displacement
29
16,17
Line Feed
Line Feed
63
Line Flag
37
Line Input Editing
14
Line Input Mode
80
16,38,60
Line Mode
Line Printer
1,3
Line Wrapping
18
Load Data Block
93
96,117
Load Record
93,95,97,117
Load Record Format
Load Record Type 0
93
Load Record Type 1
93
93,94
Load Record Type 2
93,94
Load Record Type 3
Load Record, SDOS
93
Loader Format, SDOS
93
Locking an Object
82
57,63,65,68,81
Log Channel
Log File
55,60
65,68,81
Logging
Logical Byte Number
104,118
112
Logical Cluster
Logical Cluster #0
119
10,98,102,103
Logical Cluster Number
118
Logical Column Count
17
107
Logical File Size
112
Logical Sector
Logical Sector Number 13,98,99,106,114
115
3,7,11
Lost Data
Lowercase Character
107
Lowercase Letter
35
MIDALLOC
10
MSB
93
11,12,114,115
Map Algorithm
Memory Address
93.104
Memory Content
91
Memory Failure
71
91
Memory Map
91
Memory Space, User Program
Memory, Non-Contiguous
52
Memory, Non-Existent
92
Month
108,115
64
Multi-Byte Write

Hul ti-User System
84
Multiple WAITDONEs
70
NBPC
104.109
NBPS
13.69.98.100
NCYL
13.69.98.99
NLCN
112.119
NLSN
98.101
NOP
25.26
NSPC
69.100.101
NSPC Sample Calculation
101
NSPT
13.69.98.99
NTPC
13.69.98.99
NUL
30
NUMBEROFBYTESTOWRITE
63.64
Networking
39
New Line Sequence
28
No Data Cluster Allocated
102
No Such Cluster
100
No Such Profile
20.27
No-Operation
70
Non-Maskable Interrupt
79
Non-Ready Device
15
Non-Zero Data
97
Null
59
Null Operation
82
Number of Idles
22
Number of Open Channels
15
Number of Sectors Per Cluster
100
Numeric Profile Name
27
OPEN
2.3.6.7.10.11.12.15.18.19.25.26
38.40.48.50.55.65
OPEN Channel
27
OPEN SYSCALL
7
OPEN Speed Up
50
ORG
40
Opcode Value
46
Open
3.52.63.64.68
Operating System
117
Operation Subcode
2
Operator Abort
77
Operator Edit
22
Operator Program Kill
78
Operator Requested Attention
29.33
Operator/User Program Interaction
80
Output Buffer
19.30
Output Buffer Available Space
28
Output Byte Stream to Application
14
Output Discarded
35
Output Display
15
Output Suspended
32,35
Output Timeout
20.28

Overlay Program Segment
52
Overlay Segment
54
PAGE BREAK
31,32,35
313,31,32,35
PAGE MODE
PARALE,LLIN
69
PARALELLOUT
69
PARAMS Field of SYSCALL Block
82
POSITION
3,4
69
PRINTER:
PROTECT: BACKUP
1138
1138
PROTECT:WRITE
27
Paper, Depth
21
Paper Form Size
27
Paper Width
Parallel Initiation
713
21,39
Parameter
39
Parameter Block
Parity Bit
14,16,17
Parity Stripped
16
Pass Control
71
Passed to Application
31
Patch
117
121
Personnel Training
14
Physical Terminal Characteristic
Port Number
66
3
Position
25
Position Control Call
2
Position Zero
Position, Implied
613,61,63,64
16
Pre-Processing
68
Print Position
17,18,27
Printer
14,21,31
Printer Device
Printer,
Large Buffer
26
17
Printing Character
Printing Character Echo
19
28
Profile Alteration
15,213,21
Profile Malleable
27
Profile Name
18,21,28
Profile Not Malleable
55
Program Kill
Program Killed
24,37
Program Portability
14
54
Program Segment
97
Proprietary Program
1138
Protection Bit Table
Protection Byte
9
RAM
91
RDBUF
15,16,20,36,47,48,82
RDBUG
36
RDCN
1134

READ
40
READ/WRITE Overlap
41
READA
3,8,11,14,16,18,20,22,23,24,29
31,35,38,68
READA Mode
27
READB 3,8,9,11,14,16,27,28,29,35,38,68
READB Mode
27
RENAME
3,7,8,11,15,38,108
ROM
91
ROM Serial Number
116
ROM Vector
92
RPLEN
2
RUB
34
Random Access
1
Random Access Time
6
Re-Boot
76,90
Read
3
Read ASCII
55
Read ASCII Data
59
Read Buffer
59
Read Operation
2
Read from Console
3
Read, Single-Byte
61
Read-Ahead
10
Recovery Routine
44
Rejected with Beep
31
Releasing the Object
82
Reminder Display
35
Rename
3
Reply Buffer
39
Reply Byte
42
Reply Length
2
Request for Data
14
Reset Switch
35
Return Addres'l
45
Returning an Error
82
Revision Number
114
Rewind
65,66
Right End of Field
26
Row
66
Rubout
59
Runtime Package
121
SC:ALLSTATUS
37
SC:ATTENTIONCK
29
SC: GETACTCOL
23,29
SC:GETBACKGROUND
28
SC:GETBAUDRATE
28
SC:GETCOL
9,13,27,68
SC:GETCOLORING
28
SC:GETDATACOUNT
28
SC:GETEOF
9,13,27,68,69

SC:GETERRORSTATS
13
SC:GETFILEDATE
9
9
SC:GETFILEPROT
SC:GETFILESIZE
8,9,13,68,69
SC:GETFREECOUNT
28
SC:GETIDLES
28
SC:GETLASTBADLSN
13
SC:GETLINEFLAGS
37
SC:GETLINEFLAGSHINT
37
SC:GETOUTPUTTIMEOUT
28
SC:GETPARAMS
9,13,27,68,69
SC:GETPOS
9,13,27,68
27
SC:GETPROFILE
SC:GETPROFILEALTERATION
28
27
SC:GETPROFILENAME
28
SC:GETTABS
37
SC:GETTIMESHARE
38,68,69
SC:GETTYP
9,13,27
SC:GETTYPE
28
SC:GETWRAP
SC:STATUSCK
29,37
28
SC:WRAP
SCBLK
40
SCBLK:DATA
40
SCBLK:END
40
18
SCBLK:EXTENSION
SCBLK:OPCODE
40,41
40,41
SCBLK:PARAMS
SCBLK:RDBUF
40,42
42
SCBLK:RDLEN
SCBLK:RELEN
40
SCBLK:RPLEN
40,42,59,61
SCBLK:WLEN
40,41
40,61
SCBLK:WRBUF
SCBLK:WRLEN
40,41
SDBLK:WRBUF
41
SDOS
77
SDOS Address Space
92
SDOS Boot
92
SDOS Checksum
71
76
SDOS Hung-Up
SDOS Location
91
SDOS Operation Aborted
116
SDOS, Beginning
91
SDOS.SYS
111,115,117
SDOS.SYS File Structure Restriction
117
SDOS/MT
24,30,37
36,37
SDOS/MT Already Running
SDOS/MT Flag
36
SDOS/MT Running
37

SDOS/MT Support
36
SDOS:KILLPROGRAM
78
SDOSCOMMANDS
55.78.121
SDOSDISKBACKUP
108
SDOSDISKINIT
6.108.115.117
SDOSDISKVALIDATE
12.13
SDOSERRORMAINT
120
SDOSSET
15.20.27
SDOSSET Program
27
SDOSUSERDEFS.ASM
9.13
SDVT11C
14
SEDIT
26
SERIAL IN
69
SERIALNUMBER.SYS
116
SERIALOUT
69
SETBAUDRATE
24
SETERROR
41.75
STATUS
9.13.40.41.55.81
STATUS Call. Installation-Dependent
14
SYSCALL
2.8.11.91
SYSCALL Block
12
SYSCALL Entry Point
91
SYSCALL Specification
16
SYSCALL$ (:FB)
117
SYSCALL:ATTNCHECK
77.80
SYSCALL:CHAIN
54.77.94
SYSCALL:CLOSE
49
SYSCALL:CLOSELOG
55.57
SYSCALL:CONTROL
65
SYSCALL:CREATE
1.48.55
SYSCALL:CREATELOG
55.57
79
SYSCALL:DEBUG
SYSCALL:DELAY
84
SYSCALL:DELETE
51
SYSCALL:DISABLE
78
SYSCALL:DISKDEFAULT
58
SYSCALL:DISPERROR
72.74.76.120
SYSCALL:ERROREXIT
44.54.71.72.76.90
SYSCALL:EXIT
71.76.90
SYSCALL:GETERROR
75
SYSCALL:GETSERIALNUMBER
85
SYSCALL:INTERLOCK
82
SYSCALL:ISCONSOLE
81
SYSCALL:KILLENABLE
77.78
SYSCALL:KILLPROOF
26.77
SYSCALL:LOAD
52
SYSCALL:OPEN
1.47.48.52
SYSCALL:READA
8.18.59.60
SYSCALL:READB
9,18,60,61
SYSCALL:RENAME
50

SYSCALL:SETERROR
74,76
SYSCALL:STATUS
59,60,68
70
SYSCALL:WAITDONE
18,60,63,108
SYSCALL:WRITEA
18,60,64,108
SYSCALL:WRITEB
45
SYSCALLS
SYSCALLS, List Of
46
SYSCLL:CLOSE
2
117
SYSGEN
36
SYSTEM CRASH
Scatter Load Capability
93
Scatter Loading
52
91
Scratch
66
Screen
66
Screen Position
Search, Backwards
118
118
Search, Forward
99,102,114
Sector
99
Sector 0
11
Sector Access
10
Sector Pool
9,11,107
Sector Size
13
Sector Size in Bytes
Sector Size, Minimum
113
Sector, Contiguous
100
10
Sector, Modified
Sectors Per Cylinder
101
99
Sectors Per Track
Seek Time
100,101
65
Select Echo Mode
Sequential ASCII Read
9
9
Sequential ASCII Write
Sequential File Processing Time
10
10
Sequential I/O
10
Sequential Processing Time
Serial Device, ASCII-Oriented
14
Serial Number
97,116
Set Tab
65
4
Simulated Print Head
Single-Byte Write
64
93,97
Skip Record
Software, Customer
92
92
Software, SD
Source of Data
36
10
Sparse
8,102,107,120
Sparse File
114
Spiralling
Stack Register
91
Stand-Alone System
39
Start Address
93,94
Start Address, SDOS.SYS
117

Status
3,27
Status Function
36
Status Has Changed
29,37
Status Operation
3
Subroutine Call
39
Suspended Requestor of Object
82
15
Switch Request
Synchronize Usage
82
Syscall
5
74
Syscall Block
40
Syscall Block Displacement
Syscall Block Extension
22
39
Syscall Concept
Syscall Execution
39
22
Syscall Extension
Syscall, Channel-Oriented
55
27
Sysgen
2,39
System Call
7
System Crash
79,90
System Debugger
91
System Dependent Data
36
System Dependent Linkage
108
System File, Critical
107
System Programmer
TAPE
69
27
TERSE Command Line
15
Tab
17
Tab Character
31
Tab Column
Tab Default
19
22
Tab Expansion
28
Tab Setting
19
Tab Simulation
17
Tab Table
2
Tabbing
4
Tabular Display
39
Target Computer
15
Terminal Device Name
54,55
Terminal Session Record
74
Text Display
14
Text Display Function
38,121
Time
100,101
Time Saving
38
Time of Day, Set
20,29
Timed Input Expired
26
Timeput Interval
Toggle BASIC Line Trace Switch
32
Toggle BASIC Single Step Switch
32
31
Top of Form
21
Top of Page
99,114
Track

Track 0
99
Track Boundary
101
Tracks Per Cylinder
99
Transmitted Idle
18
37
True Line Flag
8
Truncate File
18,35
Truncated Line
Tune
114
Tuning Parameters
113
121
Turn-Key Application
Turn-Key Application, Building
121
121
Turn-Key System
14,16,19,24,26
Type-Ahead Buffer
Type-Ahead Buffer Empty
14
Underscoring
25
Update Date
9
Uppercase Character
107
35
Uppercase Letter
User Assembly Program, Debugging
90
User Assembly Program, Writing
90
1,36,91
User Program
User Program Area
91
User Program Boundary
91
User Program Page Zero
91
User's Computer
39
97
Utility Program
27
VERBOSE Command Line
27
VT Driver
VT Driver Processing Exception
26
VT Input Device
26
VT:MALLPT
26
82,83
Valid Capability
9
Value, Zero
1
Variable-Size Block
28
Video Display, Memory-Mapped
Virtual Terminal Driver
14
47,48
WAIT
70
WAIT Flag
16,36,54
WARNING
WIDTH
69
WRBUF 12,18,19,20,21,22,23,24,25,26,27
36,47,48,82,83
WRBUF Contents
22
WRBUG
59
WRITE
8
WRITEA 3,8,11,12,15,16,17,25,35,38,68
WRITEB
3,8,9,11,12,14,17,38,41,121
WRITEDATABUFFER
63
WRLEN
20,22,36,47,82,83
Wait Flag
41
Wait for Operation
70

Waster Space
Width
Wrapping
Write ASCII
Write Binary
Write Buffer
Write Operation
Write Protect
Write. Illegal
Writing Data
Year
Zero-Byte Read Request
AA

AB
AC
ACAC
AD
AE
AF
AG
AH
AI
A

AK
AL
AM

AN
AO
Ap
AQ

AR
·S
AT
AU
A

W
AX
A

'y
A

A[
A\
A]

101
20
28.35
55
41
17.39
2
7.8
11
108
108.115
16
30.35
30
30.31.32.35
23.24.26.29.30.36.37.55.77.78
26.30
30
30
31
31
31
31
31
26.31
31
31
31.35
30.31. 32. 35
31.32.35
32
32.35
32
26.32
32
32
33
33
27.33
33
33
33
33
34

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2010:12:28 15:50:48-08:00
Modify Date                     : 2010:12:28 16:02:37-07:00
Metadata Date                   : 2010:12:28 16:02:37-07:00
Producer                        : Adobe Acrobat 9.4 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:63c4c7db-64d1-4901-8c1f-72bda1e2392e
Instance ID                     : uuid:e8fdd76b-7e6b-48bb-a77f-04ee20c74731
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 172

EXIF Metadata provided by EXIF.tools

SDOS_Applications_Programmers_Guide SDOS Applications Programmers Guide

SDOS_Applications_Programmers_Guide SDOS_Applications_Programmers_Guide

Navigation menu

Versions of this User Manual:

Views

Navigation