-
Notifications
You must be signed in to change notification settings - Fork 35
The NitrOS‐9 User Guide
A modern computer system relies on its operating system to interface with hardware and provide a consistent application interface. The OS handles input/output operations, memory management, and process scheduling.
NitrOS-9, an OS for 6809-based computers, organizes multiple devices, manages memory, and routes application service requests. Although inspired by UNIX, NitrOS-9 has its own unique design principles.
NitrOS-9 includes key features like:
- Multi-user and multi-tasking.
- Extensive support for structured, modular programming.
- Device-independent interrupt-driven input/output system.
- Fast, random access, multi-level directory file system.
- Expandable and adaptable design.
As you explore NitrOS-9, you'll learn how these features enhance your 6809-based computer, making it easier to use for various applications.
To master NitrOS-9, study this manual section by section, trying out each command or function. This guide is extensively cross-referenced to help you understand new topics quickly.
NitrOS-9 supports various platforms. Choose a guide below to get started:
The keys of interest on the keyboard are the SHIFT key which works like a typewriter shift key; the ENTER key which you use after typing a command or response to NitrOS-9; and the ← key which you use to erase typing mistakes.
Your first floppy disk drive is known to NitrOS-9 as /d0 and is
often called drive zero. If you have a second disk drive (drive
one), NitrOS-9 recognizes it as /d1. All input and output devices
have names like files, and names that start with "/" are considered
device names.
When NitrOS-9 first starts, it displays a welcome message. Depending on the platform, it may ask you to for the date and time. If it does, respond like this:
yyyy/mm/dd hh:mm:ss
Time ? 2024 01 01 14 20
In the example above, the date entered is January 1, 2024. NitrOS-9 uses 24-hour time, so the date entered is 1420 hours or 2:20 PM.
NitrOS-9 then prints the shell prompt to let you know it's ready for you to type in a command.
Now you're ready to try some commands. A good first command is dir
(for directory). This displays a list of the files on the system
drive:
dir
Press ENTER. All commands require that you press ENTER when you finished entering them on the command line. NitrOS-9 responds with a listing of file names that look something like this:
Directory of .
OS9Boot CMDS SYS DEFS sysgo
startup
The file OS9Boot contains the NitrOS-9 operating system in 6809 machine
language that loads into memory during the boot process.
The file sysgo is only located on NitrOS-9 Level 2 system drives.
It's the first program run on the system, and kick-starts the initial
application (usually, the shell).
The file startup is a procedure file that automatically runs when
the system starts up. It contains the commands that print the welcome
message and ask for the time. You can replace this startup file with
your own customized version. To see the contents of this file, type
list startup
list displays the contents of files that contain text such
as alphabetic and numeric characters. Some files like the OS9Boot file
contain binary data such as machine language programs. These files are
called binary files, and attempts to list them results in a
jumbled, meaningless display.
As you can see, the way you ask NitrOS-9 to run a
program or command (they're the same thing) is to type
the name. Some commands like list require one or more names of files
or options. If so, type them on the same line using spaces to separate
each item.
Where did list and dir come from? There are more files
on the disk than may be obvious. dir displayed the disk's
root directory - so named because the NitrOS-9 file system resembles a
tree. Growing out of the root directory are three branches - files
which are additional directories of file names instead of programs or
data. They, in turn, can have even more branches. If
you draw a map on paper of how this works, it resembles a tree. The
directory files on your system disk are called CMDS, SYS, and
DEFS. The file CMDS is a directory that contains all the system
commands such as dir, list, format, and others. To see the files
in this directory, enter:
dir cmds
dir shows files on the directory file CMDS instead of
the root directory. After you type this, a long list of file names
appears. These are the complete set of command programs that come with
NitrOS-9 and perform a myriad of functions. System command descriptions explains each
one in detail.
dir also has a handy option to display the CMDS directory with less typing:
dir -x
Use this command whenever you want a list of available commands.
dir has options that can give you more detailed information
about each file.
The shell is a program that accepts commands from your
keyboard. It's designed to provide a convenient, flexible, and
easy-to-use interface between you and the powerful functions of the
operating system. The shell automatically starts after NitrOS-9 completes boot.
You can tell when the shell is waiting for input because it
displays the shell prompt. This prompt indicates that the shell is
active and awaiting a command from your keyboard. It makes no difference
whether you use upper-case letters, lower-case letters, or a combination
of both because NitrOS-9 matches letters of either case.
The command line always begins with a name of a program, such as:
- Machine language program on disk.
- Machine language program already in memory.
- Executable program compiled by a high-level language such as Basic09, Pascal, and Cobol.
- Procedure file.
If you're a beginner, you'll almost always use the first case, in which
causes the program automatically loads from the CMDS directory
and runs.
When processing the command line, the shell searches for a program having the name specified in the following sequence:
- Memory. If the program named is already in memory, it executes from there.
- The execution directory, usually
CMDS. If a file of the given name exists, the operating system loads and executes it. - The data directory. If a file of the given name exists, it's processed as a procedure file. A procedure file contains one or more commands that the shell processes in a similar fashion to typing them at the prompt.
Every process has two associated directories: the execution directory and the data directory.
A more detailed explanation of directories appears later. The execution directory (usually CMDS)
includes files that contain executable programs.
Optionally, one or more parameters can follow the name given in the command line. The shell passes these parameters to the program when it launches, or forks it. Forking is the act of creating a new process under NitrOS-9, and you'll see that term going forward.
For example, in the command line:
list file1
The program name is list, and its parameter is file1.
A command line can also have one or more modifiers. These are specifications that the shell uses to alter the program's standard input/output files or memory assignments.
Normally, most commands and programs display output on the video display. If your system supports a printer, you can redirect the output of any command on the shell to the printer device. To do this, include the following modifier to at the end of any command line:
>/p
The \> character tells the shell to redirect output (see Concurrent
execution) to the printer using the printer port, which has
the device name /p (see I/O device names). For example,
to redirect the output of dir to the printer, type:
dir >/p
Use xmode to set the printer port's operating
mode, such as auto line feed. For example, to examine the printer's
current settings, type:
xmode /p
To change any of these type XMODE followed by the new value. For example, to set the printer port for automatic line feeds at the end of every line, enter:
xmode /p alf=1
Parameters specify either file name(s) or options that a program uses. Spaces separate prameters from the command name and from each other (hence parameters and options cannot themselves include spaces). Each NitrOS-9 command has an entry in System command descriptions that describes correct parameter usage.
For example, list displays the contents of a
text file. It's necessary to tell list
which file to show; therefore, the name of the desired
file is a parameter in the command line. To list
the file called startup (the system initialization procedure file),
enter the command line:
list startup
Some commands have two parameters. For example, copy makes an exact copy of a file.
It requires two parameters: the
name of the file to copy, and the name of the copy that's created.
copy startup newstartup
Other commands have parameters that select options.
dir
dir shows the names of the files in the user's data directory. Normally it
only lists file names. However, the -e (for entire)
option tells dir to display complete statistics for each file,
such as the creation date and time, size, and attributes.
dir -e
dir also accepts a file name as a parameter; this
specifies a directory file other than the default data directory.
To list file names in the SYS directory, type:
dir sys
It's also possible to specify both a directory name parameter and the
-e option together to give more information about files in that directory:
dir sys -e
This section is a summary of some commands that new or casual NitrOS-9 users enounter, along with common formats. An example follows each command. Refer to the individual command descriptions for more detailed information and additional examples. Parameters or options shown in brackets are optional. Whenever a command references a directory file name, the file must be a directory file.
CHD filename chd DATA.DIR
Changes the current data working directory to the specified directory.
COPY filename1 filename2 copy oldfile newfile
Creates filename2 as a new file, then copies all data from filename1
to it. filename1 isn't affected.
DEL filename del oldstuff
Deletes (destroys) the file specified.
DIR [filename] [-e] [-x] dir myfiles -e
Lists names of files contained in a directory. Use the -x option
to show files in the current execution directory, or leave it off
to show the files in the current data directory.
The -e option selects the long format and shows detailed
information about each file.
FREE devicename free /d1
Shows how much free space remains on the disk whose name is given.
LIST filename list script
Displays the contents of a text file on the terminal.
MAKDIR filename makdir NEWFILES
Creates a new directory file using filename.
RENAME filename1 filename2 rename zip zap
Changes the name of filename1 to filename2.
NitrOS-9 has many features to expand the capability of the keyboard and
video display. The video display has screen pause, upper/lower case, and
graphics functions. The keyboard can generate all ASCII characters and
has a type-ahead feature that permits you to enter data before a program requests
it. Key definitions with hexadecimal values
contains a list of the characters and codes that the
keyboard generates. You address the keyboard/video display using its device name: /term.
Early Radio Shack Color Computers can't render true lowercase. For those systems, you can force uppercase only rendering on the terminal:
tmode upc=1
However, the Tandy Color Computer 3 and later models of the Color Computer 2 support true lowercase on the 32x16 video display. To see if your Color Computer can do true lowercase, type the following command:
xmode /term typ=1; display e
If your Color Computer doesn't support true lower case, your screen shows unintelligble random graphics. You can reverse the above command:
xmode /term typ=0; display e
The screen pause feature stops programs after a number of screen lines appear. Output continues when you press any key. Here's how to turn off this feature:
tmode pau=0
And here's how to turn it on:
tmode pau=1
The display system supports coodes that emulate commercial data terminals, plus a complete set of graphics commands. These are described in detail in Display codes.
You can combine the Shift and CTRL keys with other keys to change their meaning. The SHIFT KEY selects between upper case and lower case letters or punctuation, and the CLEAR key generates control characters.
The keyboard has a shift lock function similar to a typewriter's, which is normally locked. The keyboard's shift lock may be reversed by depressing the control key and 0 keys simultaneously. The shift lock only affects the letter (A-Z) keys. When the keyboard is locked, these keys generate upper case letters, and lower case only if the SHIFT key is depressed. When the keyboard is unlocked, the reverse is true: lower case letters are generated unless the SHIFT key is depressed at the same time as a letter key.
You can call up a number of useful control functions from the keyboard using control keys. Generate control keys by pressing the CTRL key followed by another key. For example, to generate the character for CTRL-D press and hold the CTRL key, then press the D key.
Note
On CoCo and CoCo 2 keyboards, the CLEAR key acts as the CTRL key.
Repeat the previous input line. The last line entered reappears with the cursor positioned at the end of the line. You can press ENTER to perform the command, or edit the line by backspacing, typing over characters to correct them, and entering CTRL-A again to redisplay the edited line.
Redisplay the present input on next line.
Temporarily halt output to the display to read the screen before the data scrolls off. Output resumes when you press any other key.
Toggle all capitalization mode.
Aborts the current running program.
Interrupts the current running program and reactivates the shell. The current program becomes a background task.
Send an end-of-file to programs that read input from the terminal. This must be the first character on the line for the program to process it.
Erase the previous character.
Erase the entire line.
NitrOS-9 has a unified input/output system whereby data transfers to all I/O devices occur in the same manner, regardless of the particular hardware devices involved. It may seem that the different operational characteristics of the I/O devices might make this difficult. After all, line printers and disk drives behave much differently. However, these differences are overcome by defining a set of standardized logical functions for all devices. These functions enforce conventions that all I/O devices conform to, using software routines to eliminate hardware dependencies wherever possible. This produces a much simpler and more versatile input/output system.
NitrOS-9's unified I/O system is based upon logical entities called I/O paths. Paths are analogous to software I/O channels which the system can route from a program to a mass-storage file, an I/O device, or even another program. Another way of saying the same thing is that paths are files, and all I/O devices behave as files.
NitrOS-9 processes data transfers through paths to conform to the hardware requirements of the specific I/O device involved. These transfers are either bidirectional (read/write) or unidirectional (read only or write only), depending on the device and/or how the path is established.
Data transferred through a path is considered to be a stream of 8-bit binary bytes that have no specific type or value; what the data represents depends on how each program uses it. This is important because it means that NitrOS-9 doesn't require that data have any special format or meaning.
Some of the advantages of the unified I/O system are:
- Programs operate correctly regardless of the particular I/O devices selected and used when the program executes.
- Programs are highly portable from one computer to another, even when the computers have different kinds of I/O devices.
- I/O can be redirected to alternate files or devices without the need to alter the program.
- It's easy to create new or special device driver routines that the user installs.
Whenever a path is established (or opened), NitrOS-9 must be given a description of the routing of the path. This description is given in the form of a character string called a pathlist. It specifies a particular mass-storage file, directory file, or any other I/O device. NitrOS-9 pathlists are similar to filenames on other operating systems.
The name pathlist is used instead of pathname or filename because in many cases it's a list consisting of more than one name to specify a particular I/O device or file. In order to convey all the information required, a pathlist may include a device name, one or more directory file names and a data file name. Each name within a pathlist is separated by slash "/" characters.
Names describe three kinds of things:
- Physical I/O devices.
- Regular files.
- Directory files.
Names can have one to 29 characters and are composed of any combination of the following characters:
- Uppercase letters: A - Z.
- Lowercase letters: a - z.
- Decimal digits: 0 - 9.
- Underscore: _.
- Period: . (cannot be the first character).
Here are examples of legal names:
raw.data.2projectreview.backupreconciliation.reportX042953RJJones22search.bin
Here are examples of illegal names:
-
max*min(*isn't a legal character) -
.data(doesn't start with a letter) -
open orders(cannot contain a space) -
this.name.obviously.has.more.than.29.characters(too long)
Each physical input/output device has a unique name. The names are defined when setting up the system, and can't be changed while the system is running.
Some common device names are:
| DEVICE NAME | DESCRIPTION |
|---|---|
| term | Video display/keyboard |
| p | Printer port |
| d0 | Floppy drive unit zero |
| d1 | Floppy drive unit one |
| s0 | SD card drive unit zero |
| s1 | SD card drive unit one |
| pipe | Interprocess communication |
Device names are the first element of a pathlist, and begin with "/". If the device isn't a disk or similar device, the device name is the only name allowed. This is true for devices like terminals and printers. Some examples of of pathlists that refer to I/O devices are:
/term/p/d1
I/O device names are the names of the device descriptor modules kept by NitrOS-9 in an internal data structure called the module directory. See the NitrOS-9 System Programmer's Guide for more information about device driver and descriptor modules. This directory is automatically set up during NitrOS-9's system start up sequence, and updated as modules are added or deleted while the system is running.
Multifile devices are mass storage devices (usually disk systems) that
store data organized into separate logical entities called files.
Each file has a name which is entered in a directory file. Every
multifile device has a master directory (called the root directory)
that includes the names of the files and sub-directories stored on the
device. The root directory is created automatically when the disk is
initialized by format.
Pathlists that refer to multifile devices may have more than one name.
For example, refer to the file mouse whose name appears in the
root directory of device d1 (disk drive one) like this:
/d1/mouse
When NitrOS-9 creates a path, it uses the names in the pathlist sequentially from left to right to search various directories to obtain the necessary routing information. These directories are organized as a tree-structured hierarchy. The highest-level directory is called the device directory, which contains names and linkages to all the I/O devices on a given system. If any of the devices are of a multifile type they each have a root directory, which is the next-highest level.
The diagram below is a simplified file system tree of a typical NitrOS-9
system disk. Device and directory names are capitalized and
ordinary file names are not. This is a customary (but not mandatory)
practice which allows you to easily identify directory files using the
short form of dir.
System Device Directory
+---------------------------------+
! ! ! !
d0 term p d1
! !
! !
! !
d0 Root Directory d1 Root Directory
+----------------------+ +----------------------+
! ! ! ! ! !
DEFS startup CMDS file1 file2 file3
! !
! !
! !
--+-- +-----+----+-----+-----+
! ! ! ! ! !
OS9Defs copy list dir del backup
The device names in this example system are term, p, d0 and
d1. The root directory of device d0 includes two directory
files, DEFS and CMDS, and one ordinary file startup. Notice that
device d1 has in its root directory three ordinary files. In order
to access the file file2 on device d1, a pathlist having two
names must be used:
list /d1/file2
To construct a pathlist to access the file dir on device d0 it
is necessary to include in the pathlist the name of the intermediate
directory file CMDS. For example, to copy this file requires a
pathlist having three names to describe the from file:
copy /d0/cmds/dir temp
It's possible to create a virtually unlimited number of levels of
directories on a mass storage device using makdir.
Directories are a special type of file (see Examining and changing file
attributes). They are processed by the same I/O functions
used to access regular files which makes directory-related processing
fairly simple.
To demonstrate how directories work, assume that the disk in drive one
(d1) is freshly formatted and has a root directory
only. Use build to create a text file on d1.
build prints ? as a prompt to indicate that it's waiting for a text line to be entered.
It places each line in
the text file until it detects an empty line with only a carriage return:
OS9: build /d1/file1
? This is the first file that
? I created.
?
dir now indicates the existence of the new file:
OS9: dir /d1
Directory of /d1 15:45:29
file1
Use list to display the text stored in the file:
OS9: list /d1/file1
This is the first file
that I created.
Use build again to create two more text files:
OS9: build /d1/file2
? This is the second file
? that I created.
?
OS9: build /d1/file3
? This is another file.
?
dir now shows three file names:
OS9: dir /d1
Directory of /d1 15:52:29
file1 file2 file3
To make a new directory in this directory, use makdir NEWDIR.
Throughout this guide, directory names are always capitalized. This is not a
requirement of NitrOS-9 (see Pathlists).
It's a practice popular with many NitrOS-9 users because it
allows easy identification of directory files at all times since non-directory files are
typically a mix of upper-case and lower-case letters.
OS9: makdir /d1/NEWDIR
The directory file NEWDIR is now a file in the root
directory of /d1:
OS9: dir /d1
Directory of /d1 16:04:31
file1 file2 file3 NEWDIR
Now create a new file and put in the new directory, using copy to duplicate file1:
OS9: copy /d1/file1 /d1/newdir/file1.copy
Observe that the second pathlist now has three names: the name of the
root directory (d1), the name of the next lower directory
(NEWDIR), then the actual file name (file1.copy). Here's what the
directories look like now:
D1 Root Directory
+---------+--------+--------+
! ! ! !
NEWDIR file1 file2 file3
!
!
file1.copy
dir reveals the files in the new directory:
OS9: dir /d1/NEWDIR
Directory of /d1/NEWDIR
file1.copy
It's possible to use makdir to create additional directories
within NEWDIR, and so on, limited only by available disk space.
del cannot delete a directory file. Use this
sequence to delete a directory file:
- Delete all file names in the directory with
del. - Use
attrto turn off the files directory attribute (-d option) to make it an ordinary file (see The file security system). - Now you can delete the directory using
del.
Use deldir as an alternative to perform all these steps for you.
The NitrOS-9 directory system allows each user to privately organize files as desired, such as by project or function, without affecting other users' files. Another advantage of the hierarchical directory system is that files with identical names can be kept on the same device as long as the names are in different directories. For example, you can have a set of test files to check out a program using the same file names as the program's actual working files. You can then run the program with test data or actual data simply by switching directories.
Here are some important characteristics relating to use of directory files:
- Directories have the same ownership and security attributes and rules as regular files.
- The name of a given file appears in exactly one directory.
- A file and the directory it resides in must be on the same device.
Every process has two working directories associated with it at all times: a data directory and an execution directory. The working directory mechanism allows the name searching involved in pathlist processing to start at any level (subtree) of the file system hierarchy. Any directory that the user has permission to access (see The file security system) can be set to a working directory.
Here are the rules used to determine whether pathlists refer to the current working directory or not:
- When the first character of a pathlist is a "/", processing of the pathlist starts at the device directory. For example, the first name must be a device name.
- When the first character of a pathlist is not a "/", processing of the pathlist starts at the current working directory.
Notice that pathlists starting with a "/" must be complete; in other words, they must have all names required to trace the pathlist from the device directory down through all intermediate directories (if any):
/d2/JOE/WORKINGFILES/testresults
On the other hand, use of the current working directory allows all names
in the file hierarchy tree to be implied instead of explicitly given.
This not only makes pathlists shorter, but allows NitrOS-9 to locate
files faster because (typically) fewer directories need be searched. For
example, if the current working directory is /d1/PETE/GAMES and a
pathlist is given such as:
baseball
the actual pathlist implied is:
/d1/PETE/GAMES/baseball
Pathlists using working directories can also specify additional lower-level directories. Referring to the example above, the pathlist:
ACTION/racing
implies the complete pathlist:
/d1/PETE/GAMES/ACTION/racing
Recall that two working directories are referred to as the current execution directory and the current data directory. The reason two working directories are maintained is so that files containing programs can be organized in different directories than files containing data. NitrOS-9 automatically selects either working directory, depending on the usage of the pathlist:
- NitrOS-9 searches the execution directory when it attempts to load files into memory assumed to be executable programs. This means that programs to be run as commands or loaded into memory must be in the current execution directory.
- It then searches the data directory for all other file references, such as text files.
Immediately after startup, NitrOS-9 sets the data directory to be
the root directory of the system disk drive (usually /d0), and the
working directory to be a directory called CMDS on the same drive
(/d0/CMDS). On timesharing systems, login selects the
initial execution and data directories to the file names specified in
each user's information record stored in the system password file (see
Loading multiple programs).
Here's an example of a shell statement using the default
working directory notation, and its equivalent expansion:
copy file1 file2
If the current execution directory is /d0/CMDS and the current data
directory is /d0/JONES, the same command, fully expanded to show
complete pathlists implied is:
OS9: /d0/CMDS/copy /d0/JONES/filel /d0/JONES/file2
Notice that the first pathlist copy expands to the current working
directory pathlist because it's assumed to be an executable program but
the two other file names expand using the data directory because they
are not assumed to be executable.
You can use the built-in shell commands chd and chx to independently
change the current working data and execution directories, respectively.
These command names must be followed by a pathlist that describes the
new directory file. You must have permission to access the directory
according to normal file security rules. Here are some examples:
OS9: chd /d1/MY.DATAFILES
OS9: chx /d0/TESTPROGRAMS
When using chd or chx, pathlists work the same as they
do for regular files, except for the last name in the pathlist must be a
directory name. If the pathlist begins with a "/" , NitrOS-9 will
begin searching in the device directory for the new working directory,
otherwise searching begins with the present directory. For example,
the following sequence of commands set the working directory to the same
file:
OS9: chd /d1/SARAH
OS9: chd PROJECT1
OS9: chd /d1/SARAH/PROJECT1 (same effect as above)
Sometimes is useful to refer to the current directory or the next higher-level directory, but you may not have the full pathlist. That's when you can use special name substitutes:
. refers to the present working directory.
.. refers to the directory that contains the name of the present
directory (the next highest level directory).
... refers to directory two levels up, and so on.
Use these in place of complete pathlists and/or the first name in a pathlist. Here are some examples:
OS9: dir . List file names in the working data directory.
OS9: dir .. List names in the working data directory's
parent directory.
OS9: del ../temp Delete the file `temp` from the working data
directory's parent directory.
The substitute names refer to either the execution or data directory,
depending on the context. For example, if .. is
in a pathlist of a file that's loaded and/or executed, it
represents the parent directory of the execution directory.
Likewise, if . is in a pathlist describing a program's input
file, it represents the current data directory.
Every file (including directory files) has properties called ownership and attributes that determine who may access the file and how to use it.
NitrOS-9 stores the user ID associated with the process that created it. This user ID is the owner of the file.
Usage and security functions use attributes, which define how and by whom the file can be accessed. There are a total of seven attributes; you can turn each on or off independently. The "d" attribute indicates (when on) that the file is a directory file. The other six attributes control whether the file is read, written to, or executed, by either the owner or by the public (all other users). Specifically, these six attributes are:
- WRITE PERMISSION FOR OWNER: If on, the owner may write to the file or delete it. This permission is used to protect important files from accidental deletion or modification.
- READ PERMISSION FOR OWNER: If on, the owner is allowed to read from the file. This is used to prevent binary files from being used as text files.
- EXECUTE PERMISSION FOR OWNER: If on, the owner can load the file into memory and execute it. The file must contain one or more valid NitrOS-9 format memory modules in order to load.
The following public permissions work the same way as the owner permissions above but are applied to processes having DIFFERENT user numbers than the file's owner.
- WRITE PERMISSION FOR PUBLIC: If on, any other user may write to or delete the file.
- READ PERMISSION FOR PUBLIC: If on, any other user may read (and possibly copy) the file.
- EXECUTE PERMISSION FOR PUBLIC: If on, any other user may execute the file.
For example, if a particular file had all permissions on except "write permit to public" and "read permit to public", the owner would have unrestricted access to the file, but other users could execute it, but not read, copy, delete, or alter it.
Use dir -e to examine the security permissions of the
files in any directory. Here's an
example that shows file attributes in the working directory:
Directory of . 2003/03/04 10:20
Owner Last Modified Attributes Sector Bytecount Name
----- ----------------- ---------- ------ --------- ----
1 2002/05/29 14:02 --e--e-r 47 42 file1
0 2002/10/12 02:15 ---wr-wr 48 43 file2
3 2002/04/29 23:35 -s----wr 51 22 file3
1 2003/01/06 16:19 d-ewrewr 6D 800 NEWDIR
This display is fairly self-explanatory. The "attributes" column shows which attributes are currently on by the presence or absence of associated characters in the following format:
dsewrewr
The character positions correspond to directory;
sharable; public execute; public write; public read; owner execute;
owner write; owner read. Use attr to examine or change
a file's attributes. Type attr followed by a file name to see
the file's attributes without changing them:
OS9: attr file2
-s-wr-ewr
If you invoke the command with a list of one or more attribute abbreviations, it changes the file's attributes. For example, the command:
OS9: attr file2 pw pr -e -pe
enables public write and public read permissions and removes execute permission for both the owner and the public.
The directory attribute behaves somewhat differently than the read,
write, and execute attributes. This is because it would be quite
dangerous to be able to change directory files to normal files, and
creation of a directory requires special initialization. Therefore, attr cannot be used to turn the directory (d) attribute on
(only makdir can), and is used to turn it off only if the
directory is empty.
A single file type and format applies to all mass storage files. Files store an ordered sequence of 8-bit bytes. NitrOS-9 isn't usually sensitive to the contents of files for most functions. A given file may store a machine language program, characters of text, or almost anything else. Data is written to and read from files exactly as given. The file can be any size from zero up to the maximum capacity of the storage device, and can be expanded or shortened as desired.
When a file is created or opened a file pointer is established for it. Bytes within the file are addressed like memory, and the file pointer holds the address of the next byte in the file to be written to or read from. The NitrOS-9 read and write service functions always update the pointer as data transfers are performed. Therefore, successive read or write operations performs sequential data transfers.
Any part of a file can also be read or written in non-sequential order by using a function called seek to reposition the file pointer to any byte address in the file. This is used when random access of the data is desired.
To expand a file, you can simply write past the previous end of the file. Reading up to the last byte of a file causes the next read request to return an end-of-file status.
Even though there is physically only one type of file, the logical usage
of files in NitrOS-9 covers a broad spectrum. Because all NitrOS-9 files
have the same physical type, commands such as copy and del can
be used with any file regardless of its logical usage. Similarly, a
particular file can be treated as having a different logical usage at
different times by different programs. The main usage of files covered
in this section are:
- Text.
- Random access data.
- Executable program modules.
- Directories.
- Miscellaneous.
These files contain variable-length sequences (lines) of ASCII characters. Each line is terminated by a carriage return character. Text files are for program source code, procedure files, messages, and documentation. The Text Editor operates on this file format.
Text files are usually read sequentially, and are supported by almost all high-level languages (such as Basic09 READ and WRITE statements). Even though is is possible to randomly access data at any location within a text file, it's rarely done in practice because each line is variable length and it's hard to locate the beginning of each line without reading the data to locate carriage return characters.
The content of text files may be examined using list.
Random-access data files are created and used primarily from within high-level languages such as Basic09, Pascal, C, and Cobol. In Basic09 and Pascal, GET, PUT, and SEEK functions operate on random-access files.
The file is organized as an ordered sequence of records. Each record has exactly the same length, so given a record's numerical index, the record's beginning address within the file can be computed by multiplying the record number by the number of bytes used for each record. Thus, records are directly accessible in any order.
In most cases, the high-level language allows each record to be subdivided into fields. Each field generally has a fixed length and usage for all records within the file. For example, the first field of a record may be defined as being 25 text characters, the next field may be two bytes long and used to hold 16-bit binary numbers.
It's important to understand that NitrOS-9 itself doesn't directly process or deal with records other than providing the basic file functions required by all high-level languages to create and use random-access files.
These files hold program modules generated by the assembler or compiled by high-level languages. Each file may contain one or more program modules.
NitrOS-9 program modules resident in memory have a standard module format that, besides the object code, includes a module header and a CRC check value. Program module(s) stored in files contain exact binary copies of the programs as they exist in memory, and not one byte more. NitrOS-9 doesn't require a load record system commonly used by other operating systems because NitrOS-9 programs are position-independent code and therefore do not have to be loaded into specific memory addresses.
In order for NitrOS-9 to load the program module(s) from a file, the
file itself must have execute permission and each module must have a
valid module header and CRC check value. If a program module is
altered in any way, either as a file or in memory, its CRC check value
becomes invalid, and NitrOS-9 refuses to load the module. verify checks
the correctness of the check values, and update them to corrected values if necessary.
On Level One systems, if a file has two or more modules, they are treated as independent entities after loading and reside at different memory regions.
Like other files that contain binary data, attempts to list
program files results in the display of random characters on the
terminal giving strange effects. dump can
safely examine the contents of this kind of file in hexadecimal and
controlled ASCII format.
Directory files play a key role in the NitrOS-9 file system. They can
only be created by makdir, and are identified by the
"d" attribute being set (see Examining and changing file
attributes). The file is organized into 32-byte records.
Each record can be a directory entry. The first 29 bytes of the record
is a string of characters which is the file name. The last character of
the name has its sign bit (most significant bit) set. If the record is
not in use the first character position has the value zero. The
last three bytes of the record is a 24-bit binary number which is the
logical sector number where the file header record (see Physical file
organization) is located.
makdir initializes all records in a new directory to be
unused entries except for the first two entries. These entries have the
names . and .. along with the logical sector numbers of the
directory and its parent directory, respectively (see Anonymous
directory names).
Directories cannot be copied or listed - dir is used
instead. Directories also cannot be deleted directly (see Deleting
directory files).
NitrOS-9's basic file functions are so versatile it's possible to devise an almost unlimited number of special-purpose file formats for particular applications, which do not fit into any of the three previously discussed categories.
Examples of this category are COBOL Indexed Sequential (ISAM) files and
some special word processor file formats which allow random access of
text lines. As discussed in Sec. 3.9.1, most NitrOS-9 utility commands
work with any file format including these special types. In general, dump is the preferred method for examining the contents of
unusually formatted files.
NitrOS-9's file system implements a universal logical organization for all I/O devices that effectively eliminates most hardware-related considerations for most applications. This section gives basic information about the physical file structure NitrOS-9 uses. For more information, see the NitrOS-9 System Programmer's Manual.
Each NitrOS-9 file is comprised of one or more sectors which are the physical storage units of the disk systems. Each sector holds exactly 256 data bytes, and disk is numbered sequentially starting with sector zero, track zero. This number is called a logical sector number, or LSN. The mapping of logical sector numbers to physical track/sector numbers is done by the disk driver module.
Sectors are the smallest allocatable physical unit on a disk system, however, to increase efficiency on some larger-capacity disk. systems, NitrOS-9 uses uniform-sized groups of sectors, called clusters, as the smallest allocatable unit. Cluster sizes are always an integral power of two (2, 4, 8, and so on). One sector of each disk is allocated as a bitmap (usually LSN 1), in which each data bit corresponds to one cluster on the disk. The bits are set and cleared to indicate which clusters are in use (or defective), and which are free for allocation to files.
Each file has a directory entry (see Directory files) which includes the file name and the logical sector number of the file's file descriptor sector, which contains a complete description of the file including:
- Attributes.
- Owner.
- Date and time created.
- Size.
- Segment list (description of data sector blocks).
Unless the file size is zero, the file has one or more sectors/clusters used to store data. The data sectors are grouped into one or more contiguous blocks called segments.
The basic shell functions were introduced in a prior section in order to provide an understanding of how basic NitrOS-9 commands work. In this section the more advanced capabilities of the shell are discussed. In addition to basic command line processing, the shell has functions that facilitate:
- I/O redirection (including filters).
- Memory allocation.
- Multitasking (concurrent execution).
- Procedure file execution (background processing).
- Execution control (built-in commands).
There is a virtually unlimited combination of ways these capabilities can be used, and it's impossible to give more than a representative set of examples in this guide. You are therefore encouraged to study the basic rules, use your imagination, and explore the possibilities on your own.
The shell is a program that reads and processes command lines one at a time from its input path (usually your keyboard). Each line is first scanned (or parsed) in order to identify and process any of the following parts which may be present:
- A program, procedure file, or built-in command name (verbs).
- Parameters to be passed to the program.
- Execution modifiers to be processed by the shell.
Only the verb (the program or command name) need be present, the other parts are optional. After the verb is identified, the shell processes modifiers (if any). Any other text not yet processed is assumed to be parameters and passed to the program called.
Unless the verb is a built-in command, the shell runs the program named as a new process (task). It then deactivates itself until the program called eventually terminates, at which time it gets another input line, then the process is repeated. This happens over and over until an end-of-file condition is detected on the shell's input path which causes the shell to terminate its own execution.
Here's a sample shell line which calls the assembler:
asm sourcefile l -o >/p #12k
In this example:
-
asmis the verb. -
sourcefile l -oare parameters passed toasm. -
\>/pis a modifier which redirects the output (listing) to the system's printer. -
#12Kis a modifier that requests the process be assigned 12K bytes of memory instead of its (smaller) default amount.
The verb must be the first name in the command line. After the shell scans the line, it checks if the line is a built-in command. If so, the shell immediately executes it. Otherwise, the shell assumes it's a program name and attempts to locate and execute it.
Execution modifiers are processed by the shell before the program is run. If an error is detected in any of the modifiers, the run aborts and the error appears. Characters which comprise modifiers are stripped from the part(s) of the command line passed to the program as parameters, therefore, the characters reserved for use as modifiers ( # ; ! < > & ) cannot be used inside parameters, but can be used before or after the parameters.
When command programs are invoked by the shell, they are allocated the
minimum amount of working RAM memory specified in the program's module
header. A module header is part of all executable programs and holds the
program's name, size, memory requirements, and other values. Sometimes it's
desirable to increase this default memory size. Memory is assignable
in 256-byte pages using the modifier #n where n is the decimal
number of pages, or in 1024 byte increments using the modifier #nK.
The two examples below both request 2048 bytes, each in different ways:
OS9: copy #8 file1 file2
OS9: copy #2K file1 file2
The second kind of modifier redirects the program's standard I/O paths to alternate files or devices. Well-written NitrOS-9 programs use these paths for routine I/O. Because the programs do not use specific file or device names, it's fairly simple to redirect the I/O to any file or device without altering the program itself. Programs that normally receive input from a terminal or send output to a terminal use one or more of the standard I/O paths:
- STANDARD INPUT: This path normally passes data from the terminal's keyboard to the program.
- STANDARD OUTPUT PATH: This path is normally used to output data from the program to the terminal's display.
- STANDARD ERROR OUTPUT PATH: This path outputs routine status messages such as prompts and errors to the terminal's display (defaults to the same device as the standard output path).
Note
The name error output is sometimes misleading since many other kinds of messages besides errors are sent on this path.
When new processes are created, they inherit their parent process' standard I/O paths. Therefore, when the shell creates new processes, they usually inherit its standard I/O paths. When you log-on the shell's standard input is the terminal keyboard; the standard output and error output is the terminal's display. When using a redirection modifier on a shell command line, the shell opens the corresponding paths and pass them to the new process as its standard I/O paths. There are three redirection modifiers:
| MODIFIER | BEHAVIOR |
|---|---|
| < | Redirect the standard input path. |
| > | Redirect the standard output path. |
| >> | Redirect the standard error output path. |
Following any redirection modifier on the command line is the name of
the file or device that receives the I/O. For example, the standard output of
list is being redirected to the printer:
OS9: list correspondence >/p
The shell opens, creates, and closes files referenced by I/O redirection modifiers.
Here, the output of dir is redirected to the file /d1/savelisting:
OS9: dir >/d1/savelisting
Use list on the file /d1/savelisting to see the output:
OS9: list /d1/savelisting
Directory of . 10:15:00
myfile savelisting file1
You can place redirection modifiers before or after the program's parameters, but you can use each modifier only once.
A single shell input line can request execution of more than one program. These programs execute either sequentially or concurrently. Sequential execution means that one program must complete its function and terminate before the next program begins execution. Concurrent execution means that several programs begin execution and run simultaneously.
Programs execute sequentially when each one is staged on a separate
line. You can specify more than one program on a single command
line by separating each program name and its parameters from the next
one with the ; character:
OS9: copy myfile /d1/newfile ; dir >/p
This command line executes copy first, then dir.
If any program returns an error, subsequent commands on the same
line don't execute, regardless of the state of the x option.
Otherwise, ; and return are identical separators.
Here are some more examples:
OS9: copy oldfile newfile; del oldfile; list newfile
OS9: dir >/d1/myfile ; list temp >/p; del temp
All sequentially programs executed are separate child processes of the shell. After initiating sequential execution of a program, the shell enters the wait state until execution of the called program terminates.
The second kind of separator is the & for concurrent
execution. This alows programs to run as a separate, child
process. The shell doesn't wait for the prcoess to complete before
processing the next command.
The concurrent execution separator demonstrates multiprogramming (running two or more programs simultaneously). The number of programs you can run at the same time isn't fixed. It depends upon the amount of free memory in the system versus the memory requirements of the specific programs. Here's an example:
OS9: dir >/p&
&007
OS9:
Here, the shell starts dir then prints the process ID number (&007),
then immediately displays the OS9: prompt and waits for another command.
Meanwhile dir is busy sending a directory listing to the
printer. You can display a status summary of all processes you've
created using procs:
OS9: dir >/p& list file1& copy file1 file2 ; del temp
Because dir, list, and copy are followed by & separators, they
run concurrently. del doesn't run until copy terminates because of the sequential execution
(;) character.
The third kind of separator is the ! character for constructing pipelines.
Pipelines consist of two or more concurrent
programs whose standard input and/or output paths connect to each other
using pipes.
Pipes are the primary means of transfering data from one process to another. This is known as interprocess communication. Pipes are first-in, first-out buffers that behave like mass-storage files.
I/O transfers using pipes automatically buffer and synchronize their content. A single pipe may have several readers and several writers. Multiple writers send, and multiple readers accept, data to/from the pipe on a first-come, first-serve basis. An end-of-file occurs if an attempt is made to read from a pipe when no writers are available to send data. Conversely, a write error occurs if a write is attempted to a pipe without readers.
For each !, the shell redirects the standard output of
the program on the left of the ! to
the standard input of the program on the right of the !.
Each instance of ! causes the shell to create a new pipe:
OS9: update <master_file ! sort ! write_report >/p
In the example above, update has its input redirected from
a path called master_file. Its standard output becomes the standard
input for the program sort. Its output, in turn, becomes the standard
input for the program write_report, which has its standard output
redirected to the printer.
The shell executes all programs in a pipeline concurrently. The pipes
automatically synchronize the programs so the output of one never gets
ahead of the input request of the next program. This
implies that data cannot flow through a pipeline any faster than the
slowest program can process it. Some of the most useful applications of
pipelines are jobs like character set conversion, print file formatting, and
data compression/decompression. Programs that are designed to
process data as components of a pipeline are often called filters.
tee is such a filter. It uses pipes to allow data to be simultaneously
broadcast from a single input path to several output paths.
You can enclose sections of shell input lines in parentheses. This permits modifiers and separators to be applied to an entire set of programs. The shell processes them by calling itself recursively (as a new process) to execute the enclosed program list:
OS9: (dir /d0; dir /d1) >/p
gives the same result as:
OS9: dir /d0 >/p; dir /d1 >/p
except for the subtle difference that the printer is kept
continuously in the first example; in the second case another user could
steal the printer in between dir invocations.
Use command grouping to cause a group of programs to execute sequentially or concurrently:
OS9: (del file1; del file2; del file3)&
A useful extension of this form is to construct pipelines consisting of sequential and/or concurrent programs:
OS9: (dir CMDS; dir SYS) ! makeuppercase ! transmit
Here's a very practical example of the use of pipelines.
dsave generates a procedure file to copy all the files in
a directory. The example below shows how the output of dsave is
pipelined to a shell which executes the NitrOS-9 commands as they
are generated. Assume that you want to copy all files from a
directory called WORKING to a directory called ARCHIVE:
OS9: chd /d0/WORKING; dsave /d0/ARCHIVE ! shell -p
When processing input lines, the shell looks for several special names
of commands or option switches that are built-in the shell. These
commands are executed without loading a program and creating a new
process, and generally affect how the shell operates. They are used
at the beginning of a line, or following any program separator (;,
&, or !). You can separate two or more adjacent built-in commands with spaces or commas.
The built-in commands and their functions are:
| COMMAND | FUNCTION |
|---|---|
chd <path> |
Change the working data directory to the directory specified by the pathlist. |
chx <path> |
Change the working execution directory to the directory specified by the pathlist. |
ex <name> |
Directly execute the module named. This transforms the shell process so it ceases to exist and a new module begins execution in its place. |
w |
Wait for any process to terminate. |
* text |
Comment; the shell ignores it. |
kill <id> |
Abort the process specified. |
setpr <id> <pri> |
Change the process' priority. |
x |
Cause the shell to abort on any error (default). |
-x |
Cause the shell not to abort on error. |
p |
Turn the shell prompt and messages on (default). |
-p |
Inhibits shell prompt and messages. |
t |
Make the shell copy all input lines to output. |
-t |
Don't copy input lines to output (default). |
The change directory commands switch the shell's working directory and,
by inheritance, any subsequently created child process. Use ex
when the shell needs to initiate execution of a program
without the overhead of a suspended shell process. The name is
processed according to standard shell operation, and modifiers can be
used.
The shell is a reentrant program that can be simultaneously executed by more than one process at a time. As is the case with most other NitrOS-9 programs, it uses standard I/O paths for routine input and output. specifically, it requests command lines from the standard input path and writes its prompts and other data to the standard error path.
The shell can start up another process also running the shell by means
of shell. If the standard input path is redirected to a
mass storage file, the new incarnation of the shell can accept and
execute command lines from the file instead of a terminal keyboard. The
text file to be processed is called a procedure file. It contains
one or more command lines that are identical to command lines that are
manually entered from the keyboard. This technique is sometimes called
batch or background processing.
If the <program name> specified on a shell command line can not be found in memory or in the execution directory, shell searches the data directory for a file with the desired name. If one is found, shell automatically executes it as a procedure file.
Execution of procedure files have a number of valuable applications. It can eliminate repetitive manual entry of commonly-used sequences of commands. It can allow the computer to execute a lengthy series of programs in the background while the computer is unattended or while the user is running other programs in the foreground.
In addition to redirecting the shell's standard input to a procedure file, the standard output and standard error output can be redirected to another file which can record output for later review or printing. This can also eliminate the sometimes-annoying output of shell messages to your terminal at random times.
Here are two simple ways to use the shell to create another shell:
OS9: shell <procfile
OS9: procfile
Both do exactly the same thing: execute the commands of the file
procfile. To run the procedure file in a background mode you
simply add the ampersand operator:
OS9: procfile&
NitrOS-9 doesn't have any constraints on the number of jobs that can be simultaneously executed as long as there is memory available. Also, the procedure files can themselves cause sequential or concurrent execution of additional procedure files. Here's a more complex example of initiating two processing streams with redirection of each shell's output to files:
OS9: proc1 t >>stat1& proc2 t >>stat2&
The built-in command t (copy input lines to error output)
was used above. They make the output file contain a record of all lines
executed, but without useless OS9 prompts intermixed. The -x
built-in command can be used if you do not want processing to stop if
an error occurs. The built-in commands only affect the shell
that executes them, and not any others that may exist.
Many programs (including the shell) use NitrOS-9's standard error
reporting function, which displays an error number on the error output
path. The standard error codes are listed in
OS-9 Error Codes. If desired, the printerr
command can be executed, which replaces the smaller, built-in error
display routine with a larger (and slower) routine that looks up
descriptive error messages from a text file called /dd/SYS/errmsg.
Once printerr is run it, you can't undo it. Also,
its effect is system-wide.
Programs called by the shell can return an error code in the CPU's
"B" register (otherwise B should be cleared) upon termination. This
type of error, as well as errors detected by the shell itself,
cause an error message to display, and processing of the command
line or procedure file terminated unless the -x built-in
command has executed.
Before the shell executes a program, it checks the program module's language type. If its type isn't 6809 machine language, shell calls the appropriate run-time system for that module. Versions of the shell supplied for various systems are capable of calling different run-time systems. Most versions of shell call Basic09 when appropriate, and Level Two versions of shell can also call the Pascal P-code interpreter (PascalN), or the CIS Cobol runtime system (RunC).
For example, if you wanted to run a Basic09 I-code module called
adventure, you could type the command given below:
OS9: basic09 adventure
Or you could accomplish the same thing by typing the following:
OS9: adventure
NitrOS-9 systems used for timesharing usually have a procedure file that
brings the system up by means of one simple command or by using the
system startup file. A procedure file which initiates the timesharing
monitor for each terminal is executed to start up the system. The
procedure file first starts the system clock, then initiates concurrent
execution of a number of processes that have their I/O redirected to
each timesharing terminal.
Usually one tsmon is started up concurrently for each
terminal in the system. This is a special program which monitors a
terminal for activity. When a carriage return character is typed on any
of these terminals, tsmon initiates login
program. If a user doesn't enter a correct password or user number in
three tries, login aborts. Here's a sample
procedure file for a 4-terminal timesharing system having terminals
names term, t1, t2, and t3.
* system startup procedure file
echo Please Enter the Date and Time
setime </term
printerr
tsmon /t1&
tsmon /t2&
tsmon /t3&
Note
This procedure won't work unless
/dd/SYS/PASSWORD exists. For more information, please see
LOGIN.
The example above deserves special attention. setime
has its input redirected to the system console term, which
is necessary because it would otherwise attempt to read the time
information from its current standard input path, which is the procedure
file and not the keyboard.
One of NitrOS-9's most extraordinary abilities is multiprogramming, which is sometimes called timesharing or multitasking. Simply states, NitrOS-9 lets you computer run more than one program at the same time. This can be a tremendous advantage in many situations. For example, you can be editing one program while another is being printed. Or you can use your computer to control household automation and still be able to use it for routine work and entertainment.
NitrOS-9 uses this capability all the time for internal functions. The
simple way for you to do so is by putting a & character at the end
of a command line which causes the shell to run your command as a
background task.
The information presented in this section is intended to give you an insight into how NitrOS-9 performs this amazing feat. You certainly don't have to know every detail of how multiprogramming works in order to use NitrOS-9, but a basic working knowledge can help you discover many new ways to use your computer.
In order to allow several programs to run simultaneously and without interference, NitrOS-9 must perform many coordination and resource allocation functions. The major system resources managed by NitrOS-9 are:
- CPU Time.
- Memory.
- The input/output system.
In order for the computer to have reasonable performance, these resources must be managed in the most efficient manner possible. Therefore, NitrOS-9 uses many techniques and strategies to optimize system throughput and capacity.
CPU time is a resource that must be allocated wisely to maximize the computer's throughput. It's characteristic of many programs to spend much unproductive time waiting for various events, such as an input/output operation. A good example is an interactive program which communicates with a person at a terminal on a line-by line basis. Every time the program has to wait for a line of characters to be typed or displayed, it (typically) cannot do any useful processing and would waste CPU time. An efficient multiprogramming operating system such as NitrOS-9 automatically assigns CPU time to only those programs that can effectively use the, time.
NitrOS-9 uses a technique called timeslicing which allows processes to share CPU time with all other active processes. Timeslicing is implemented using both hardware and software functions. The system's CPU is interrupted by a real time clock many times each second. This basic time interval is called a tick, hence, the interval between ticks is a time slice. This technique is called timeslicing because each second of CPU time is sliced up to be shared among several processes. This happens so rapidly that to a human observer all processes appear to execute continuously, unless the computer becomes overloaded with processing. If this happens, a noticeable delay in response to terminal input may occur, or batch programs may take much longer to run than they ordinarily do. At any occurrence of a tick, NitrOS-9 can suspend execution of one program and begin execution of another. The starting and stopping of programs is done in a manner that doesn't affect the program's execution. How frequently a process is given time slices depends upon its assigned priority relative to the assigned priority of other active processes.
The percentage of CPU time assigned to any particular process cannot be exactly computed because there are dynamic variables such as time the process spends waiting for I/O devices. It can be roughly approximated by dividing the process's priority by the sum of the priority numbers of all processes:
Process Priority
Process CPU Share = -------------------
Sum of All Active
Process' Priorities
The CPU time allocation system automatically assigns programs one of three states that describe their current status. Process states are also important for coordinating process execution. A process may be in one and only one state at any instant, although state changes may be frequent. The states are:
- ACTIVE: processes which can currently perform useful processing. These are the only processes assigned CPU time.
- WAITING: processes which have been suspended until another process terminates. This state coordinates execution of sequential programs. The shell, for example, is in the waiting state during the time a command program it has initiated is running.
- SLEEPING: processes suspended by self-request for a specified time interval or until receipt of a signal. Signals are internal messages used to coordinate concurrent processes. This is the typical state of programs which are waiting for input/output operations.
Sleeping and waiting processes are not given CPU time until they change to the active state.
The sequence of operations required to create a new process and initially allocate its resources (especially memory) are automatically performed by NitrOS-9's fork function. If for any reason any part of the sequence cannot be performed the fork is aborted and the prospective parent is passed an appropriate error code. The most frequent reason for failure is unavailablity of required resources (especially memory) or when the program specified to be run cannot be found. A process can create many new processes, subject only to the limitation of the amount of unassigned memory available.
When a process creates a new process, the creator is called the parent process, and the newly created process is called the child process. The new child can itself become a parent by creating yet another process. If a parent process creates more than one child process, the children are called siblings with respect to each other. If the parent/child relationship of all processes in the system is examined, a hierarchical lineage becomes evident. In fact, this hierarchy is a tree structure that resembles a family tree. The family concept makes it easy to describe relationships between processes, and so it's used extensively in descriptions of NitrOS-9's multiprogramming operations.
When the parent issues a fork request to NitrOS-9, it must specify the following required information:
- A PRIMARY MODULE, which is the name of the program to be executed by the new process. The program can already be present in memory, or NitrOS-9 may load it from a mass storage file having the same name.
- PARAMETERS, which is data specified by the parent to be passed to the new process. This data is copied to part of the child process' memory area. Parameters are frequently used to pass file names, initialization values, and other information. The shell passes command line parameters this way.
The new process also inherits copies of certain of its parent's properties. These are:
- A USER NUMBER which the file security system uses to identify all processes belonging to a specific user. This isn't the same as the process ID, which identifies a specific process. . This number is usually obtained from the system password file when a user logs on. The system manager always is user number zero.
- STANDARD INPUT AND OUTPUT PATHS: the three paths (input, output, and error/status) used for routine input and output. Most paths (files) may be shared simultaneously by two or more processes. The two current working directories are also inherited.
- PROCESS PRIORITY which determines what proportion of CPU time the process receives with respect to others.
As part of the fork operation, NitrOS-9 automatically assigns:
- A PROCESS ID: a number from 1 to 255, which identifies specific processes. Each process has a unique process ID number.
- MEMORY: enough memory required for the new process to run. Level Two systems give each process a unique address space. In Level One systems, all processes share the single address space. A data area, used for the program's parameters, variables, and stack is allocated for the process' exclusive use. A second memory area may also be required to load the program (primary module) if it's not resident in memory.
To summarize, the following items are given to or associated with new processes:
- Primary module (program module to be run).
- Parameter(s) passed from parent to child.
- User number.
- Standard I/O paths and working directories.
- Process priority.
- Process ID.
- Memory.
An important NitrOS-9 function is memory management. NitrOS-9 automatically allocates all system memory to itself and to processes, and also keeps track of the logical contents of memory (meaning which program modules are resident in memory at any given time). The result is that you seldom have to be bothered with the actual memory addresses of programs or data.
Within the address space, memory is assigned from higher addresses downward for program modules, and from lower addresses upward for data areas, as shown below:
+---------------------------+ highest address
! program modules !
! (RAM or ROM) !
! !
! - - - - - - - - - - - - - !
! !
! unused space !
! (RAM or empty) !
! !
! - - - - - - - - - - - - - !
! !
! data areas !
! (RAM) !
! !
+---------------------------+ lowest address (0)
When performing a fork operation, NitrOS-9's first step is to attempt to locate the requested program module by searching the module directory, which has the address of every module present in memory. The 6809 instruction set supports a type of program called reentrant code which means the exact same copy of a program can be shared by two or more different processes simultaneously without affecting each other, provided that each incarnation of the program has am independent memory area for its variables.
Almost all NitrOS-9 family software is reentrant and can make most efficient use of memory. For example, Basic09 requires 22K bytes of memory to load into. If a request to run Basic09 is made, but another user (process) had previously caused it to be loaded into memory, both processes share the same copy, instead of causing another copy to be loaded (which would use an additional 22K of memory). NitrOS-9 automatically keeps track of how many processes are using each program module and deletes the module (freeing its memory for other uses) when all processes using the module have terminated.
If the requested program module isn't already in memory, the name is used as a pathlist (file name) and an attempt is made to load the program from mass storage.
Every program module has a module header that describes the program and its memory requirements. NitrOS-9 uses this to determine how much memory for variable storage needs to be allocated to the process (it can be given more memory by specifying an optional parameter on the shell command line). The module header also includes other important descriptive information about the program, and is an essential part of NitrOS-9 operation at the machine language level. A detailed description of memory modules and module headers can be found in the "NitrOS-9 System Programmer's Manual".
Programs can also be explicitly loaded into memory using the load
command. As with fork, the program loads only if it's
not already in memory. If the module isn't in memory, NitrOS-9 will
copy a candidate memory module from the file into memory, verify the
CRC, and then, if the module isn't already in the module directory, add
the module to the directory. This process is repeated until all the
modules in the file are loaded, the 64K memory limit is exceeded, or
until a module with an invalid format is encountered. NitrOS-9 always
links to the first module read from the file.
If the program module is already in memory, the load proceeds as described above, loading the module from the specified file, verifying the CRC, and when attempting to add the valid module to the module directory, noticing that the module is already known, the load merely increments the known module's link count (the number of processes using the module.) The load command can be used to lock a program into memory. This can be useful if the same program is to be used frequently because the program resides in memory continuously, instead of being loaded repeatedly.
The opposite of load is unlink, which decreases a
program module's link count by one. Recall that when this count becomes
zero (indicating the module in no longer in use), the
module is deleted, its memory is deallocated, and its name is
removed from the module directory. unlink is generally
used in conjunction with load (programs loaded by fork are
automatically unlinked when the program terminates).
Here's an example of the use of load and unlink to lock a program
in memory. Suppose copy is invoked five times. Normally,
the copy command would be loaded each time copy is called.
If you use load first, copy is locked into memory:
OS9: load copy
OS9: copy file1 file1a
OS9: copy file2 file2a
OS9: copy file3 file3a
OS9: unlink copy
It's important to use unlink after the program is no
longer needed, or the program continues to occupy memory which
otherwise could be used for other purposes. Be very careful not to
completely unlink modules in use by any process! This causes the
memory that the module occupies to be deallocated and its contents destroyed.
This causes all programs using the unlinked module to
crash.
Another important aspect of program loading is the ability to have two or more programs resident in memory at the same time. This is possible because all NitrOS-9 program modules are position-independent code, or PIC. PIC programs do not have to be loaded into specific, predetermined memory addresses to work correctly, and can therefore be loaded at different memory addresses at different times. PIC programs require special types of machine language instructions which few computers have. The ability of the 6809 microprocessor to use this type of program is one of its most powerful features.
load can therefore be used two or more times (or a single
file may contain several memory modules), and each program module will
be automatically loaded at different, non-overlapping addresses (most
other operating systems write over the previous program's memory
whenever a new program is loaded). This technique also relieves the user
from having to be directly concerned with absolute memory addresses. Any
number of program modules can be loaded until available system memory is
full.
Even though PIC programs can be initially loaded at any address where free memory is available, program modules cannot be relocated dynamically afterwards. Once a program is loaded it must remain at the address at which it was originally loaded (however Level Two systems can load (map) memory resident programs at different addresses in each process' address space). This characteristic can lead to a sometimes troublesome phenomenon called memory fragmentation. When programs are loaded, they are assigned the first sufficiently large block of memory at the highest address possible in the address space. If a number of program modules are loaded, and subsequently one or more modules which are located in between other modules are unlinked, several fragments of free memory space appear. The sum of the sizes of the free memory space may be quite large, but because they are scattered, not enough space exists in a single block to load a program module larger than the largest free space.
mfree shows the location and size of each unused memory
area and mdir -e shows the address, size, and link (use)
count of each module in the address space. These commands can be used to
detect fragmentation. Memory can usually be de-fragmemted by unlinking
scattered modules and reloading them. Make certain none are in use
before doing so.
Disk-based NitrOS-9 systems use a system disk to load many parts of the
operating system during the system startup and to provide files
frequently used during normal system operations. Therefore, the system
disk is generally kept in disk drive zero (/d0) when the system is
running.
Two files used during the system startup operation, OS9Boot and
startup must reside in the system disk's root directory. Other
files are organized into three directories: CMDS (commands), DEFS
(system-wide definitions), and SYS (other system files). Other files
and directories created by the system manager and/or users may also
reside on the system disk. These frequently include each user s initial
data directory.
The OS9Boot file loads into RAM by routines on the computer's firmware.
It includes file managers, device drivers and descriptors, and other modules that
permanently reside in memory. Color Computer users can create new bootstrap files
with OS9GEN.
Modules in the bootfile always remain in memory and can't be unlinked.
The directory /d0/SYS contains several important files:
| FILE | PURPOSE |
|---|---|
| password | System password file (see LOGIN). |
| errmsg | Error message file. |
| helpmsg | Help database file. |
These files and the SYS directory itself, aren't required
to boot NitrOS-9. They are needed if you use login, tsmon, or `help.
You can add other system-wide files into this directory if you wish.
The startup file resides in the root directory and is a procedure file
that the shell invokes at system startup. You
can include any legal shell command line in startup such as
setime to start the system clock or a custom message using echo.
startup is an optional file, and if not present, the system still starts up
correctly.
The directory CMDS is the system-wide command object code directory.
All users share it as their working execution
directory. If shell isnt' part of the OS9Boot file (and it
shouldn't be in a Level 2 system), it must exist in this
directory. The system startup process sysgo makes CMDS the initial
execution directory.
The directory DEFS contains assembly language
source code that hold system-wide symbolic definitions.
These files are needed for assembly language programs using the assembler.
This directory is optional, but highly recommended for anyone writing
assembly language programs. The files commonly contained in this
directory are:
| FILE | PURPOSE |
|---|---|
| OS9Defs | System-wide definition file. |
| RBFDefs | RBF file manager definition file. |
| SCFDefs | SCF file manager definition file. |
| Systype | System types definition file. |
The system disk isn't usually removed while the system is running,
especially on multiuser systems. If it's, the chx and chd (if the
working data directory was on the system disk) commands should be
executed to reset the working directory pointers because the directories
may be at different addresses on the new disk:
chx /d0/cmds
chd /d0
In general, it's unwise to remove a disk and replace it with another if any paths are open to files resident on the disk. It's dangerous to exchange any disk if any files on it are open in WRITE or UPDATE modes.
To make a system disk, the following steps must be performed:
- The new disk must be formatted.
- The
OS9Bootfile must be created and linked byos9genorcobbler. - The
startupfile must be created or copied. - The
CMDSandSYSdirectories and the files they contain must be copied. - For Level 2, the
sysgofile in the root directory must be copied.
Steps 2 through 5 may be performed manually, or automatically by any of the following methods:
- A shell procedure file created by the user.
- A shell procedure file generated by
dsave. - The
backupcommand.
This section contains descriptions for each of the command programs that are supplied with NitrOS-9. These programs are usually called using the shell, but can be called from most other NitrOS-9 family programs such as Basic09, the interactive debugger, and the macro text editor. Unless otherwise noted, these programs are designed to run as individual processes.
Important
Although many NitrOS-9 commands may work on Level 1 or Level 2 systems, there are differences. Take care not to mix command files from Level 1 systems on Level 2, or the reverse.
Each command description includes a syntax definition which describes how the command sentence can be constructed. These are symbolic descriptions that use the following notation:
| NOTATION | MEANING |
|---|---|
| [ ] | The enclosed item(s) are optional. |
| { } | The enclosed item(s) can be omitted or repeated multiple times. |
| Any legal pathlist. | |
| Any legal device name. | |
| Any legal memory module name. | |
| A process identifier. | |
| A integer value. | |
| One or more options defined in the command description. | |
| A list of arguments (parameters). | |
| A two character hexadecimal value. | |
| A character string terminated by an end-of-line character. |
Note
The syntax of the commands given doesn't include the shell's built in options such as alternate memory size and I/O redirection. This is because the shell filters its options out of the command line before it's passed to the program being called.
Modify a file's security attributes.
attr <path> [<opts>]
s = set sharable file
-s = inhibit sharable file
r = set owner read
-r = inhibit owner read
w = set owner write
-w = inhibit owner write
e = set owner execute
-e = inhibit owner execute
pr = set public read
-pr = inhibit public read
pw = set public write
-pw = inhibit public write
pe = set public execute
-pe = inhibit public execute
attr examines or changes the security attributes of a
file. Type attr followed by the pathlist and the attributes to
turn on or off.
Turn on an attribute with its abbreviation, or turn it off off by preceding its abbreviation with a minus sign. Permissions not explicitly named aren't affected. If you don't supply any attributes, the current attributes are shown. If you're user 0, you can change attributes of any file; otherwise, you can only change the attributes of files that you own.
Here are the file attributes:
d = Directory file
s = Sharable file
r = Read permit to owner
w = Write permit to owner
e = Execute permit to owner
pr = Read permit to public
pw = Write permit to public
pe = Execute permit to public
You can use attr to change a directory file to a
non-directory file once the directory is empty. Since del only deletes
non-directory files, this is the only way to delete a directory.
For more information, see The file security system and Examining and changing file attributes.
attr myfile -pr -pw
attr myfile r w e pr rw pe
attr datalog
-s-wr-wr
Make a backup copy of a disk.
backup [<opts>] <devname> <devname>
e = Exit if any read error occurs
s = Print the single drive prompt message
-v = Don't verify
#nK = More memory makes backup run faster
This command copies all data from one device to another, sector by sector, without regard to file structures. In almost all cases, the specified devices must have the exact same format such as size and density, and must not have defective sectors.
If you omit both device names, the command assumes /d0 and /d1.
If you omit only the second device name, the command attempts a single unit backup.
backup /d2 /d3
backup -v
OS9: backup
Ready to BACKUP from /d0 to /d1 ?: Y
MYDISK is being scratched
OK ?: Y
Number of sectors copied: $04D0
Verify pass
Number of sectors verified: $04D0
OS9:
Below is an example of a single drive backup that reads a
portion of the source disk into memory. When you remove the source disk and
place the destination disk into the drive, backup writes to the
destination disk. Then you remove the destination disk and place the source
disk into the drive. This continues until the entire disk is
copied. Give backup as much memory as possible to reduce the number of
required disk exchanges.
For more information, see Running the backup program.
OS9:backup /d0 #10k
Ready to BACKUP from /d0 to /d0 ?: Y
Ready DESTINATION, hit a key:
MYDISK is being scratched
OK ?: Y
Ready SOURCE, hit a key:
Ready DESTINATION, hit a key:
Ready SOURCE, hit a key:
Ready DESTINATION, hit a key:
(several repetitions)
Ready DESTINATION, hit a key:
Number of sectors copied: $4D0
Verify pass
Number of sectors verified: $4D0
Convert a binary file to an S-Record file.
binex <path1> <path2>
S-Record files are a type of text file that contains records that represent binary data in hexadecimal characters. This Motorola-standard format is often directly accepted by commercial PROM programmers, emulators, logic analyzers and similar devices that interface to RS-232 ports. You can also use it for transmitting files over data links that can only handle character-type data, or to convert NitrOS-9 assembler or compiler-generated programs to load on non-NitrOS-9 systems.
binex converts path1, a NitrOS-9 binary format file, to a new file
named path2 in S-Record format. If invoked on a non-binary load
module file, a warning message appears and the command prompts the user
to proceed anyway. A "Y" response means yes; any other
answer terminates the program. S-Records have a header record to
store the program name for informational purposes and each data record
has an absolute memory address that's not meaningful to NitrOS-9 since
it uses position-independent-code. However, the S-Record format requires
them, so binex prompts the user for a program name and starting
load address:
binex /d0/cmds/scanner scanner.s1
Enter starting address for file: $100
Enter name for header record: scanner
To download the program to a device such as a PROM programmer (for
example using serial port /t1) type:
list scanner.s1 >/t1
Build a text file from standard input.
build <path>
This command builds short text files by copying the standard
input path into the file specified by . build creates a file
according to the path parameter, then displays a ? prompt to
request an input line. It writes each line to the path.
Enter a blank line to stop the input.
build small_file
build /p (copies keyboard to printer)
You may also redirect the standard input path to a file:
build <mytext /t2 (copies file "mytext" to terminal 22)
OS9: build newfile
? The powers of the NitrOS-9
? operating system are truly
? fantastic.
?
OS9: list newfile
The powers of the NitrOS-9
operating system are truly
fantastic.
Change the working data or execution directory.
chd <path>
chx <path>
These are built-in shell commands that change NitrOS-9's data directory or execution directory. Many commands in NitrOS-9 work with user data, such as text files and programs. These commands assume that a file is located in the working data directory. Other NitrOS-9 commands assume that a file is in the working execution directory.
Note
These commands don't appear in the CMDS directory because they're
built into the shell.
For more information, see Using and changing working directories and Changing current working directories.
chd /d1/PROGRAMS
chx ..
chx binary_files/test_programs
chx /d0/CMDS; chd /d1
Compare the contents of two files.
cmp <path1> <path2>
This command opens two files and performs a comparison of the binary values of the contents. If there are any differences, the file offset (address) and the values of the bytes from each file appear in hexadecimal.
The comparison ends when an end-of-file is encountered on either file. The command then displays a summary of the number of bytes compared and the number of differences found.
OS9: cmp red blue
Differences
byte #1 #2
======== == ==
00000013 00 01
00000022 B0 B1
0000002A 9B AB
0000002B 3B 36
0000002C 6D 65
Bytes compared: 0000002D
Bytes different: 00000005
OS9: cmp red red
Differences
None ...
Bytes compared: 0000002D
Bytes different: 00000000
Create a bootstrap file.
cobbler <devname>
This command creates the OS9Boot file required on any disk that
NitrOS-9 boots from. The boot file consists of the
same modules that are loaded into memory during the most recent
boostrap. To add modules to the bootstrap file, use os9gen. cobbler also writes the NitrOS-9 kernel on the 18
sectors of track 34, and excludes these sectors from the disk allocation
map. If any files are present on these sectors, cobbler displays an
error message.
For more information, see Running the backup program and The OS9Boot file.
OS9: cobbler /d1
Copy data from one path to another.
copy <path1> <path2> [<opts>]
-a = abort if error received
-p = don't echo filenames when copying
-r = rewrite the destination
-s = perform a single drive copy
-w=<dir> = copy to <dir>
-x=<dir> = execution-relative directory.
This command copies data from the first file or device specified to the second. The first file or device must already exist, the second file is automatically created if the second path is a file on a mass storage device. Data may be of any type and is NOT modified in any way as it's copied.
Data is transferred using large block reads and writes until end-of-file
occurs on the input path. Because the transfer uses block transfers, normal
output processing of data doesn't occur on character-oriented devices
such as terminals and printers. Therefore, list is
preferred over copy when a file consisting of text is to be sent to a
terminal or printer.
The -a option forces copy to abort its operation if it
receives an error during the copy of a file. If this option isn't
specified, copy continues to attempt to copy any other files
specified on its command line.
The -p option prevents copy from echoing the filenames that it's
copying (used in conjunction with -w).
The -r option allows copy to rewrite the destination file if it
matches the name of a source file that is being copied. If this option
isn't used, then the user is prompted to overwrite a file of the
same name.
The -s option causes copy to perform a single drive copy
operation. The second pathlist must be a full pathlist if -s appears.
copy reads a portion of the source disk into memory, you remove
the source disk and place the destination disk into the drive, enter a
C whereupon copy writes on the destination disk, this process
continues until the entire file is copied.
The -w=<dir> option allows you to specify a destination directory
where all the files are copied to. Use this option when specifying
multiple filenames on the command line.
The -x=<dir> causes the files to be copied to an
execution-relative directory.
Using the shell's alternate memory size modifier to give a large memory space increases speed and reduce the number of media exchanges required for single drive copies.
copy file1 file2 #15k (copies file1 to file2)
copy /d1/joe/news /d0/peter/messages
copy /d1/joe/news /d1/joe/weather -w=/d0/PETER (where /d0/PETER is a directory)
copy /term /p (copies console to printer)
copy /d0/cat /d0/animals/cat -s #32k
Ready DESTINATION, hit C to continue: c
Ready SOURCE, hit C to continue: c
Ready DESTINATION, hit C to continue:c
Identify the CPU on the system.
cputype
Identifies the CPU as 6809 or 6309.
Display the system date and time.
date [<opts>]
-t = show time along with date
This command displays the current system date, and if the -t
option is given, the current system time.
date -t
date -t >/p (Output is redirected to printer)
OS9: setime
yyyy/mm/dd hh:mm:ss
Time ? 2003/04/15 14:19:00
OS9:date
April 15, 2003
OS9:date -t
April 15, 2003 14:20:20
Check an RBF device's file structure.
dcheck [<opts>] <devname>
-b = suppress listing of unused clusters
-m = preserve allocation map work files
-o = print valid options
-p = print pathlists for questionable clusters
-s = display count of files and directories only
-w=<path> = pathlist to directory for work files
It's possible for sectors on a disk to be marked as being allocated but
in fact are not associated with a file or the disk's free
space. This can happen if a disk is removed from a drive while files are
still open, or if a directory which still contains files is deleted (see
Deleting directory files). dcheck is a diagnostic that can
be used to detect this condition, as well as the general integrity of
the directory/file linkages.
dcheck is given as a parameter the name of the disk device to be
checked. After verifying and printing some vital file structure
parameters, dcheck follows pointers down the disk's file system tree
to all directories and files on the disk. As it does so, it verifies the
integrity of the file descriptor sectors, reports any discrepancies in
the directory/file linkages, and builds a sector allocation map from the
segment list associated with each file. If any file descriptor sectors
(FDs) describe a segment with a cluster not within the file structure of
the disk, a message is reported like:
*** Bad FD segment ($xxxxxx-$yyyyyy) for file: pathlist
This indicates that a segment starting at sector xxxxxx and ending at sector yyyyyy cannot really be on this disk. Because there is a good chance the entire FD is bad if any of it's segment descriptors are bad, the allocation map is not updated for corrupt FDs.
While building the allocation map, dcheck also makes sure that each
disk cluster appears only once and only once in the file structure. If
this condition is detected, dcheck displays a message like:
Cluster $xxxxxx was previously allocated
This message indicates that cluster xxxxxx was found at least once before in the file structure. The message may be printed more than once if a cluster appears in a segment in more than one file.
The newly created allocation map is then compared to the allocation map stored on the disk, and any differences are reported in messages like:
Cluster $xxxxxx in allocation map but not in file structure
Cluster $xxxxxx in file structure but not in allocation map
The first message indicates sector number xxxxxx (hexadecimal) was found not to be part of the file system, but was marked as allocated in the disk's allocation map. In addition to the causes mentioned in the first paragraph, some sectors may have been excluded from the allocation map by the FORMAT program because they were defective or they may be the last few sectors of the disk, the sum of which was two small to comprise a cluster.
The second message indicates that the cluster starting at sector xxxxxx
is part of the file structure but is not marked as allocated in the
disk's allocation map. It's possible that this cluster may be
allocated to another file later, overwriting the contents of the cluster
with data from the newly allocated file. Any clusters that have been
reported as previously allocated by dcheck as described above
surely have this problem.
The -s option causes dcheck to display a count of files and
directories only; only FDs are checked for validity. The -b option
suppresses listing of clusters allocated but not in file structure. The
-p option causes dcheck to make a second pass through the file
structure printing the pathlists for any clusters that dcheck finds as
"already allocated" or "in file structure but not in allocation
map". The -w= option tells dcheck where to locate it's
allocation map work file(s). The pathlist specified must be a FULL
pathlist to a directory. The directory /d0 is used if
-w isn't specified. It's recommended that this pathlist NOT be
located on the disk being dchecked if the disk's file structure
integrity is in doubt.
dcheck builds its disk allocation map in a file called
/DCHECKppO, where is as specified by the
-w= option and pp is the process number in hexadecimal. Each bit in
this bitmap file corresponds to a cluster of sectors on the disk. If the
-p option appears on the command line, dcheck creates a second
bitmap file (/DCHECKpp1) that has a bit set for each cluster
dcheck finds as "previously allocated" or "in file structure but
not in allocation map" while building the allocation map. dcheck them
makes another pass through the directory structure to determine the
pathlists for these questionable clusters. These bitmap work files may
be saved by specifying the -m option on the command line.
For best results, dcheck should have exclusive access to the disk
being checked. Otherwise dcheck may be fooled if the disk allocation
map changes while it's building its bitmap file from the changing file
structure. dcheck cannot process disks with a directory depth greater
than 39 levels.
For more information, see Physical file organization, Deleting directory files, FORMAT, and 6.1 of NitrOS-9 Systems Programmer's Manual.
OS9: dcheck /d2 (workfile is on /d0)
Volume - 'My system disk' on device /d2
$009A bytes in allocation map
1 sector per cluster
$0004D0 total sectors on media
Sector $000002 is start of root directory FD
$0010 sectors used for id, allocation map and root directory
Building allocation map work file...
Checking allocation map file...
'My system disk' file structure is intact
1 directory
2 files
OS9: dcheck -mpw=/d2 /d0
Volume - 'System disk' on device /d0
$0046 bytes in allocation map
1 sector per cluster
$00022A total sectors on media
Sector $000002 is start of root directory FD
$0010 sectors used for id, allocation map and root directory
Building allocation map work file...
Cluster $00040 was previously allocated
*** Bad FD segment ($111111-$23A6F0) for file: /d0/test/junky.file
Checking allocation map file...
Cluster $000038 in file structure but not in allocation map
Cluster $00003B in file structure but not in allocation map
Cluster $0001B9 in allocation map but not in file structure
Cluster $0001BB in allocation map but not in file structure
Pathlists for questionable clusters:
Cluster $000038 in path: /d0/OS9boot
Cluster $00003B in path: /d0/OS9boot
Cluster $000040 in path: /d0/OS9boot
Cluster $000040 in path: /d0/test/double.file
1 previously allocated clusters found
2 clusters in file structure but not in allocation map
2 clusters in allocation map but not in file structure
1 bad file descriptor sector
'System disk' file structure is not intact
5 directories
25 files
Inspect memory and registers.
debug
Interactive Debugger.
| COMMAND | FUNCTION |
|---|---|
| [SPACEBAR]expression | Evaluate; display in hexadecimal and decimal form. |
| . | Display dot address and contents. |
| .. | Restore last dot address; display address and contents. |
| .expression | Set dot to result of expression; display address and contents. |
| =expression | Set memory at dot to result of expression. |
| - | Decrement dot; display address and contents. |
| [ENTER] | Increment dot; display address and contents. |
| : | Display all registers' contents. |
| :register | Display the specified register's contents. |
| :register expression | Set register to the result of expression. |
| E module-name | Prepare for execution. |
| G | Go to the program. |
| G expression | Goto the program at the address specified by the result of expression. |
| L module-name | Link to the module named; display address. |
| B | Display all breakpoints. |
| B expression | Set a breakpoint at the result of the expression. |
| K | Kill all breakpoints. |
| K expression | Kill the breakpoint at address specified by expression. |
| M expression1 expression2 | Display memory dump in tabular form. |
| C expression1 expression2 | Clear and test memory. |
| S expression1 expression2 | Search memory for pattern. |
| $ command | Call NitrOS-9 shell with optional command. |
| Q | Quit (exit) Debug. |
Edit RBF files in hexadecimal interactively.
ded <path>
dEd is a screen-oriented disk editor utility. It was originally
conceived as a floppy disk editor, so the display is organized around
individual sectors. It performs most of the functions of Patch, from
Computerware, but is faster, more compact, and screen-oriented rather
than line-oriented. Individual files or the disk itself (hard, floppy,
RAM) can be examined and changed, sectors can be written to an output
file, and executable modules can be located, linked to and verified.
To use, type:
ded pathlist
where is of the form: filename or dirname or /path/filename or /d0@ (edits entire disk)
ded reads in and display the first 256 bytes in the file (disk).
This is Logical Sector Number (LSN) zero. You move through the file
sector (LSN) by sector using the up and down arrow keys. The current LSN
number is displayed in Hex and Decimal in the upper left corner of the
screen. If the disk itself was accessed (by appending '@' to it's
name when dEd was called), the LSN is the disk sector number. If an
individual file is being editted, however, the LSN displayed refers to
the file, not to the disk. All numbers requested by dEd must be in Hex
format. All commands are accessed by simply pressing the desired key.
Delete a file.
del [<opts>] <path> {<path>}
-x = file is in execution directory
This command deletes the file(s) specified by the pathlist(s). The user must have write permission for the file(s). Directory files cannot be deleted unless their type is changed to non-directory. See ATTR.
For more information, see Deleting directory files and Examining and changing file attributes.
del test_program old_test_program
del /d1/number_five
OS9:dir /d1
Directory of /d1 14:29:46
myfile newfile
OS9:del /d1/newfile
OS9:dir /d1
Directory of /d1 14:30:37
myfile
OS9:del myprog -x
OS9:del -x CMDS.SUBDIR/file
Delete all files in a directory file.
deldir <path>
This command is a convenient alternative to manually deleting directories and files they contain. It's only used when all files in the directory system are to be deleted.
deldir prompts for deletion:
OS9: deldir OLDFILES
Deleting directory file.
List directory, delete directory, or quit ? (l/d/q)
An l response causes dir -e to be run so you can
have an opportunity to see the files in the directory before they are
deleted.
A d response initiates the process of deleting files.
A q response aborts the command before action is taken.
The directory to be deleted may include directory files, which may
themselves include directory files. In this case, deldir operates
recursively, so all lower-level directories are
deleted as well. In this case the lower-level directories are processed
first.
You must have correct access permission to delete all files and
directories encountered. If not, deldir aborts upon encountering
the first file for which you do not have write permission.
deldir automatically calls the DIR and ATTR commands, so
they both must reside in the current execution directory.
Show device table entries.
devs
devs displays a list of the system's device table. The device table
contains an entry for each active device known to NitrOS-9. devs does
not display information for uninitialized devices. The
header lists the system name, the NitrOS-9 version number, and the
maximum number of devices allowed in the device table.
Each line in the devs display contains five fields:
| Name | Description |
|---|---|
| Device | Name of the device descriptor. |
| Driver | Name of the device driver. |
| File Mgr | Name of the file manager. |
| Data Ptr | Address of the device driver's static storage. |
| Links | Device use count. |
Note
Each time a user executes a chd to an RBF device, the use count of that device is incremented by one. Consequently, the Links field may be artificially high.
Modify RBF device descriptors.
dmode <devname> | <path> [<opts>]
This new version allows any combination of upper or lower case options to be specified.
Also, current parameters are displayed with a \$ preceding to remind
the user that the values are hexadecimal.
Options may be prefixed with a \$. It's simply ignored.
Typical dmode output:
OS9: dmode /dd {enter}
drv=$00 stp=$00 typ=$80 dns=$01 cyl=$0334 sid=$06
vfy=$00 sct=$0021 tos=$0021 ilv=$00 sas=$20
Now, let's say you want to change the number of cylinders this
descripter shows. The following command lines would all be valid and
accepted by the new dmode:
OS9: dmode /dd CYL=276
-or- dmode /dd Cyl=$276
-or- dmode /dd cYL=276
Lastly, you may now specify either TOS or T0S to setup the
number of sectors per track in track zero. Example:
OS9: dmode /dd tos=21
-or- dmode /dd t0s=21
Display the names of files contained in a directory.
dir [<opts>] <path>
Displays a formatted list of files names in a directory file on. the
standard output path. If no parameters are given, the current data
directory is shown. If the x option is given, the current
execution directory is shown. If a pathlist of a directory file is
given, it's shown.
If the e option is included, each file's entire description is
displayed: size, address, owner, permissions, date and time of last
modification.
For more information, see Using the keyboard and disks, Creating and using directories, and Examining and changing file attributes.
dir (display data directory)
dir -x (display execution directory)
dir -x -e (display entire description of execution dir)
dir .. (display parent of working data directory)
dir newstuff (display newstuff directory)
dir -e test_programs (display entire description of test_programs)
Disassemble NitrOS-9 modules.
disasm [<opts>] <modname> | <path>
Disasm was written to hack apart NitrOS-9 system modules,command
modules, file managers and device drivers/descriptors either from memory
or disk. Unlike most other disassemblers, disasm is a two pass
disassembler, creating output using only referenced labels. This output
can be redirected to a file and (after modifications if desired) then
re-assembled.
Disasm provides completely commented disassembly of Device Descriptors... very useful for building a customized boot file.
disasm -m
: links to module in memory - if not found, disasm loads the module from the execution directory then links to it. After disassembly, it unlinks the module.
disasm /module name>
: 'read's the module from the specified path without loading.
other options:
: o = display line number,address,object code & source code... useful for hard to crack modules with data embedded in the middle.
x = look for module in execution directory.
ANY combination of options is allowed (upper or lower case) but they must immediately follow the '-' and there must be no spaces separating the options.
Display raw characters from hexadecimal.
display <hex> {<hex>}
Display reads one or more hexadecimal numbers given as parameters, converts them to ASCII characters, and writes them to the standard output. It's commonly used to send special characters (such as cursor and screen control codes) to terminals and other I/O devices.
display 0C 1F 02 7F
display 15 >/p (sends "form feed" to printer)
OS9: display 41 42 43 44 45 46
ABCDEF
Generate a procedure file to copy files.
dsave [<opts>] <path>
dsave performs a backup or copy of all files in one or more directories. It
doesn't execute the commands; instead, it echos commands to standard
output. This output can be redirected to a file and executed later as a
procedure file.
When dsave executes, it writes copy commands to standard output
to copy files from the current data directory to the directory
specified by . If dsave encounters a directory file, it will
automatically include makdir and chd in the output before
generating copy commands for files in the subdirectory. Since dsave is
recursive in operation, the procedure file exactly replicates all
levels of the file system from the current data directory downward (such
a section of the file system is called a subtree).
If the current working directory happens to be the root directory of the
disk, dsave creates a procedure file that backs up the entire
disk file by file. This is useful when it's necessary to copy many
files from different format disks, or from floppy disk to a hard disk.
Available dsave options are:
-b make output disk a system disk by using source disk's
OS9Boot file, if present.
-b= make output disk a system disk using as source
for the OS9Boot file.
-i indent for directory levels
-l do not process directories below the current level
-m do not include makdir in procedure file
-r forces the copy command to rewrite the file at its destination if it already exists
-s set copy size parameter to K
For more information, see Common command formats.
Example which copies all files on d2 to d1:
chd /d0 (select "from" directory)
dsave /d1 >/d0/makecopy (make procedure file "makecopy")
/d0/makcopy (run procedure file)
chd /d0/MYFILES/STUFF
dsave -is32 /d1/BACKUP/STUFF >saver
/d0/MYFILES/STUFF/saver
Display file data in formatted hexadecimal and ASCII.
dump [<opts>] <path>
This command produces a formatted display of the physical data contents of the path specified which may be a mass storage file or any other I/O device. If a pathlist is omitted, it uses the standard input path. The output is written to standard output. This command is commonly used to examine the contents of non-text files.
The data is displayed 16 bytes per line in both hexadecimal and ASCII character format. Data bytes that have non-displayable values are represented by periods in the character area.
The addresses displayed on the dump are relative to the beginning of the file. Because memory modules are position-independent and stored on files exactly as they exist in memory, the addresses shown on the dump correspond to the relative load addresses of memory-module files.
-h prevent dump from printing its header every 256 bytes
-m names on the command line are modules in memory
-x names on the command line are files relative to the execution directory
dump (display keyboard input in hex)
dump myfile >/p (dump myfile to printer)
dump -m kernel (dump the kernel module in memory)
Address 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
-------- ---- ---- ---- ---- ---- ---- ---- ---- ----------------
00000000 87CD 0038 002A P181 2800 2E00 3103 FFE0 .M.8.*q.(...1..'
00000010 0418 0000 0100 0101 0001 1808 180D 1B04 ................
00000020 0117 0311 0807 1500 002A 5445 S2CD 5343 .........*TERMSC
00000030 C641 4349 C10E 529E FACIA.R.
^ ^ ^
starting data bytes in hexadecimal data bytes in
address format ASCII format
Echo text to an output path.
echo <text>
This command echoes its argument to the standard output path. It's typically used to generate messages in shell procedure files or to send an initialization character sequence to a terminal. The text should not include any of the punctuation characters that the shell uses.
echo >/t2 Hello John how's it going & (echo to t2)
echo >/term ** warning ** disk about to be scratched 1
echo >/p Listing of Transaction File; list trans >/p
OS9: echo This is an important message!
This is an important message!
Execute a program as overlay.
ex <modname> [<opts>]
This a built-in shell command that causes the process executing the shell to start execution of another program. It permits a transition from the shell to another program without creating another process, thus conserving system memory.
This command is often used when the shell is called from another program
to execute a specific program, after which the shell isn't needed. For
instance, applications which only use basic09 need not waste memory
space on shell.
Ensure that ex is the last command on a shell input line since any commands
that follow it never executes.
Note
Since this is a built-in shell command, it doesn't appear in the CMDS directory.
For more information, see Built-in shell commands and options, Shell procedure files, and Setting up timesharing system procedure files.
ex basic09
tsmon /t1&; tsmon /t2&; ex tsmon /term
Convert an S-Record file to a binary file.
exbin <path2> <path1>
S-Record files are a type of text file that contains records that represent binary data in hexadecimal character form. This Motorola-standard format is often directly accepted by commercial PROM programmers, emulators, logic analyzers and similar devices that are interfaced RS-232 interfaces. It can also be useful for transmitting files over data links that can only handle character-type data; or to convert NitrOS-9 assembler or compiler-generated programs to load on non-NitrOS-9 systems.
path1 is assumed to be an S-Record format text file which exbin
converts to pure binary form on a new file called path2. The load
addresses of each data record must describe continguous data in
ascending order.
exbin doesn't generate or check for the proper NitrOS-9 module
headers or CRC check value required to load the binary file.
The IDENT or VERIFY commands can be used to check the validity of the
modules if they are to be loaded or run. Example:
exbin program.S1 cmds/program
Initialize disk media.
format <devname>
This command physically initializes, verifies, and establishes an initial file structure on a disk. All disks must be formatted before they can be used on an NitrOS-9 system.
Note
If the diskette is to be used as a system disk, os9gen or
cobbler must be run to create the bootstrap after the disk has been
formatted.
The formatting process works as follows:
-
The disk surface is physically initialized and sectored.
-
Each sector is read back and verified. If the sector fails to verify after several attempts, the offending sector is excluded from the initial free space on the disk. As the verification is performed, track numbers are displayed on the standard output device.
-
The disk allocation map, root directory, and identification sector are written to the first few sectors of track zero. These sectors cannot be defective.
format prompts for a disk volume name, which can be up to 32
characters long and may include spaces or punctuation. This name can
later be displayed using the FREE command.
For more information, see Physical file organization.
Display free space remaining on mass-storage device.
free <devname>
This command displays the number of unused 256-byte sectors on a device
which are available for new files or for expanding existing files. The
device name given must be that of a mass-storage multifile device.
Free also displays the disk's name, creation date, and cluster size.
Data sectors are allocated in groups called clusters. The number of
sectors per cluster depends on the storage capacity and physical
characteristics of the specific device. This means that small amounts of
free space may not be divisible into as many files. For example, if a
given disk system uses 8 sectors per cluster, and free shows
32 sectors free, a maximum of four new files could be created even if
each has only one cluster.
For more information, see Physical file organization.
OS9: free
BACKUP DATA DISK created on: 80/06/12
Capacity: 1,232 sectors (1-sector clusters)
1,020 free sectors, largest block 935 sectors
OS9: free /d1
NitrOS-9 Documentation Disk created on: 81/04/13
Capacity: 1,232 sectors (1-sector clusters)
568 Free sectors, largest block 440 sectors
Display the usage and syntax of NitrOS-9 commands.
help {<command>}
Provide as argument the command for which you want syntax help. Include
as many command names in one help line as you wish. The proper form
and syntax appears for each valid command you include.
If you do not include a command name, help shows you the list of available topics for you to choose from.
help ex
Syntax: Ex <modname>
Usage : Chain to the given module
help me
me: no help available
help
Help available on:
ASM ATTR [...]
Print NitrOS-9 module information.
ident [<opts>] <path>
This command displays header information from NitrOS-9 memory
modules. ident displays the module size, CRC bytes (with
verification), and for program and device driver modules, the execution
offset and the permanent storage requirement bytes. ident prints
and interprets the type/language and attribute/revision bytes. In
addition, ident displays the byte immediately following the module
name since most Microware-supplied modules set this byte to indicate the
module edition.
ident displays all modules contained in a disk file. If the -m
option appears, <path> is assumed to be a module in memory.
If the -v option is specified, the module CRC isn't verified.
The -x option implies the pathlist begins in the execution
directory.
The -s option causes ident to display the. following module
information on a single line:
Edition byte (first byte after module name)
Type/Language byte
Module CRC
A . if the CRC verifies correctly, or ? if incorrect. (ident leaves this field blank when using the -v option.)
Module name
OS9: ident -m ident
Header for: Ident <Module name>
Module size: $06A5 #1701 <Module size>
Module CRC: $1CE78A (Good) <Good or Bad>
Hdr parity: $8B <Header parity>
Exec. off: $0222 #546 <Execution offset>
Data size: $0CA1 #3233 <Permanent storage requirement>
Edition: $05 #5 <First byte after module name>
Ty/La At/Rv: $11 $81 <Type/Language Attribute/Revision>
Prog mod, 6809 obj, re-en <Module type, Language, Attribute>
OS9: ident /d0/os9boot -s
1 $C0 $A366DC . KrnP2
83 $C0 $7FC336 . Init
1 $11 $39BA94 . SysGo
1 $C1 $402573 . IOMan
3 $D1 $EE937A . RBF
82 $F1 $526268 . DD
82 $F1 $526268 . D0
82 $F1 $D65245 . D1
82 $F1 $E32FFE . D2
1 $D1 $F944D7 . SCF
2 $E1 $F9FE37 . VDGInt
83 $F1 $765270 . Term
2 $D1 $BBC1EE . PipeMan
2 $E1 $5B2B56 . Piper
80 $F1 $CC06AF . Pipe
2 $C1 $248B2C . Clock
2 $C1 $248B2C . Clock2
^ ^ ^ ^ ^
| | | | |
| | | | Module name
| | | CRC check " " if -v, "." if OK, "?" if bad
| | CRC value
| Type/Language byte
Edition byte (first byte after name)
Initialize a device.
iniz <devname> {<devname>}
Links the specified device to NitrOS-9, places the device addres in a
new device table entry, allocates the memory needed by the device
driver, and calls the device driver initialization routine. If the
device is already installed, iniz doesn't reinitialize it.
devicename is the name of the device drivere you want to initialize. Specify as
many device drivers as you wish with one iniz.
You can use Iniz in the startup file or at the system startup to initialize devices and allocate their static storage at the top of memory (to reduce memory fragmentation).
iniz p t2
initializes the p (printer) and t2 (terminal 2) devices.
Show the interrupt polling table.
irqs
irqs displays a list of the system's IRQ polling table. The IRQ polling
table contains a list of the service routines for each interrupt handler
known by the system.
The irqs display header lists the system name, the NitrOS-9 version
number, the maximum number of devices allowed in the device table, and
the maximum number of entries in the IRQ table.
Abort a process.
kill <procID>
This shell built in command sends an abort signal to the process
having the process ID number specified. The process to be aborted must
have the same user ID as the user that executed the command. Use procs
to obtain the process ID numbers.
Note
If a process is waiting for I/O, it may not die until it completes
the current I/O operation, therefore, if you kill a process and procs shows it still exists, it's probably waiting for
receive a line of data from a terminal before it can die. Since this is
a built-in shell command, it doesn't appear in the CMDS directory.
For more information, see Built-in shell commands and
options, Process states, and PROCS.
kill 5
kill 22
OS9: procs
User # Id pty state Mem Primary module
----- --- --- -------- --- --------------
20 2 0 active 2 Shell <TERM
20 1 0 waiting 1 Sysgo <TERM
20 3 0 sleeping 20 Copy <TERM
OS9: kill 3
OS9: procs
User # Id pty state Mem Primary module
----- --- --- -------- --- --------------
20 2 0 active 2 Shell <TERM
20 1 0 waiting 1 Sysgo <TERM
OS9:
Link module into memory.
link <modname>
This command locks a previously loaded module into memory.
The link count of the module specified is incremented by one each time
it's linked. unlink unlocks the module when it's no longer needed.
For more information, see Basic memory management functions, Loading program modules into memory, Loading multiple programs, and Memory fragmentation.
OS9: LINK edit
OS9: LINK myprogram
List the contents of a text file.
list <path> {<path>}
This command copies text lines from the path(s) given as parameters to the standard output path. The program terminates upon reaching the end-of-file of the last input path. If more than one path is specified, the first path is copied to standard output, the second path will be copied next.
This command is most commonly used to examine or print text files.
For more information, see Common command formats and Text files.
list /d0/startup >/p & (output is redirected to printer)
list /d1/user5/document /d0/myfile /d0/Bob/text
list /term >/p (copy keyboard to printer - use
"escape" key to terminate input)
OS9: build animals
? cat
? cow
? dog
? elephant
? bird
? fish
?
OS9: list animals
cat
cow
dog
elephant
bird
fish
Load module(s) from file into memory.
load <path> {<path>}
The path specified is opened and one or more modules is read from it and loaded into memory. The names of the modules are added to the module directory. If a module is loaded that has the same name and type as a module already in memory, the module having the highest revision level is kept.
For more information, see Executable program module files, Loading program modules into memory, and Loading multiple programs.
load new_program
OS9:mdir
Module Directory at 13:36:47
DCB4 D0 D1 D2 D3
OS9P2 INIT OS9 IOMAN REF
SCF ACIA TERM T1 T2
T3 P PIA CDS H1
Sysgo Clock Shell Tsmon Copy
Mdir
OS9:load edit
OS9:mdir
Module Directory at 13:37:14
DCB4 D0 D1 D2 D3
OS9P2 INIT OS9 IOMAN REF
SCF ACIA TERM T1 T2
T3 P PIA CDS H1
Sysgo Clock Shell Tsmon Copy
Mdir EDIT
Manage access to the system.
login
Timesharing systems like tsmon use login to provide log-in security. It
requests a user name and password and checks it against a
validation file. If the information is correct, the user's system
priority, user ID, and working directories are set up according to
information stored in the file. It then executes the initial program specified in the
password file (usually shell).
If the user cannot supply a
correct user name and password after three attempts, the process aborts.
The validation file is called password and must be present in
the directory /d0/SYS. The file contains one or more variable-length
text records, one for each user name. Each record has the following
comma-delimited fields:
- User name (up to 32 characters, may include spaces). If this field is empty, any name matches.
- Password (up to 32 characters, may include spaces) If this field is omitted, no password is required by the specific use.
- User index (ID) number (from 0 to 65535, 0 is superuser). The file security system uses this number as the system-wide user ID to identify all processes initiated by. The system manager should assign a unique ID to each potential user. See The file security system.
- Initial process (CPU time) priority: 1 - 255 (see Process states)
- Pathlist of initial execution directory (usually
/d0/CMDS) - Pathlist of initial data directory (specific user's directory)
- Name of initial program to execute (usually
shell).
Here's a sample validation file:
superuser,secret,0,255,.,.,shell
steve,open sesame,3,128,.,/d1/STEVE,shell
sally,qwerty,10,100,/d0/BUSINESS,/d1/LETTERS,wordprocessor
bob,,4,128,.,/d1/BOB,Basic09
To use login, enter:
login
This causes prompts for the user's name and (optionally) password
to be displayed, and if answered correctly, the user is logged into the
system. Login initializes the user number, working execution
directory, working data directory, and executes the initial program
specified by the password file. The date, time and process number (which
is not the same as the user ID, see Creation of new
processes) are also displayed.
Note
if the shell from which login was called won't be needed
again, it may be discarded by using ex to start login.
To log off the system, the initial program specified in the password
file must be terminated. For most programs (including shell) this may
be done by typing an end of file character (escape) as the first
character on a line.
If desired, a file named motd appearing in the SYS directory will
cause login to display it's contents on the user's terminal after
successful login. This file isn't required for login to operate.
For more information, see TSMON, Setting up timesharing system procedure files, The file security system, and Creation of new processes.
OS9: login
NitrOS-9/6309 Timesharing System
Level 2 V03.02.01
2003/12/04 13:02:22
User name?: superuser
Password: secret
Process #07 logged on 2003/12/04 13:03:00
Welcome!
Create a directory file.
makdir <path>
Creates a new directory file acdording to the pathlist given. The pathlist must refer to a parent directory for which the user has write permission.
The new directory is initialized and initially doesn't contain files
except for the . and .. pointers to its parent directory and itself,
respectively (see Anonymous directory names). All access
permissions are enabled (except sharable).
It's customary (but not mandatory) to capitalize directory names.
For more information, see Multifile devices and directory files, Creating and using directories, Deleting directory files, Anonymous directory names, and Directory files.
makdir /d1/STEVE/PROJECT
makdir DATAFILES
makdir ../SAVEFILES
Display the module directory.
mdir [<opts>]
Displays the present module names in the system module directory:
OS9: mdir
Module Directory at 14:44:35
D0 Pipe OS9 OS9P2
Init Boot DDisk D1
KBVDIO TERM IOMan RBF
SCF SysGo Clock Shell
PRINTER P PipeMan Piper
Mdir
If the -e option is given, a full listing of the physical address,
size, type, revision level, reentant attribute, user count, and name of
each module is displayed. All numbers shown are in hexadecimal.
OS9: mdir -e
Module Directory at 10:55:04
ADDR SIZE TY RV AT UC NAME
---- ---- -- -- -- -- --------
C305 2F F1 1 R D0
F059 7EB C1 1 R OS9
F852 4F4 C1 1 R OS9P2
FD46 2E CO 1 R INIT
C363 798 E1 1 R 2 KBVDIO
CAFB 38 F1 1 R 2 TERM
Important
Many of the modules listed by mdir are NitrOS-9 system modules and
not executable as programs: always check the module type code before
running a module if you are not familiar with it!
For more information, see Loading program modules into memory.
Combine files together.
merge <path> {<path>}
This command copies multiple input files specified by the pathlists
given as parameters to the standard output path. It's commonly used to
combine several files into a single output file. Data is copied in the
order the pathlists are given. Merge does no output line editing (such
as automatic line feed). The standard output is generally redirected to
a file or device.
OS9: merge file1 file2 file3 file4 >combined.file
OS9: merge compile.list asm.list >/printer
Display free system memory.
mfree
Displays a list of which areas of memory are not presently in use and available for assignment. The address and size of each free memory block are displayed. The size is given as the number of 256-byte pages. This information is useful to detect and correct memory fragmentation (see Memory fragmentation).
For more information, see Basic memory management functions and Memory fragmentation.
OS9: mfree
Address pages
--------- -----
700- 7FF 1
B00-AEFF 164
B100-B1FF 1
Total pages free = 166
Build and link a boot file.
os9gen <devname>
os9gen creates and links the OS9Boot file on any
disk from that OS-9 boots from. os9gen adds
modules to an existing boot, and can create an entirely new boot file. If
an exact copy of the existing OS9Boot file is desired, the cobbler
command should be used instead.
The name of the device on which the OS9Boot file is to be installed is
passed to os9gen as a command line parameter. os9gen then creates a
working file called TempBoot on the device specified. Next it reads
file names (pathlists) from its standard input, one pathlist per line.
Every file named is opened and copied to TempBoot. This is repeated
until end-of-file or a blank line is reached on os9gen's standard
input. All boot files must contain the OS-9 component modules listed in
section The OS9Boot file.
After all input files have been copied to TempBoot, the old OS9Boot
file, if present, is deleted. TempBoot is then renamed to OS9Boot,
and its starting address and size is linked in the disk's
Identification Sector (LSN 0) for use by the OS-9 bootstrap firmware.
WARNING: Any OS9Boot file must be stored in physically contiguous
sectors. Therefore, os9gen is normally used on a freshly formatted
disk. If the OS9Boot file is fragmented, os9gen prints a warning
message indicated the disk cannot be used to bootstrap OS-9.
The list of file names given to os9gen can be entered from a keyboard,
or os9gen's standard input may be redirected to a text file
containing a list of file names (pathlists) . If names are entered
manually, no prompts are given, and the end-of-file key (usually ESCAPE)
or a blank line is entered after the line containing the last pathlist.
For more information, see Use of the System Disk, The OS9Boot file, and Changing system disks.
To manually install a boot file on device d1 which is an exact copy
of the OS9Boot file on device d0:
OS9: os9gen /d1 (run os9gen)
/d0/os9boot (enter file to be installed)
[ESCAPE] (enter end-of-file)
To manually install a boot file on device d1 which is a copy of the
OS9Boot file on device d0 with the addition of modules stored in
the files /d0/tape.driver and /d2/video.driver:
OS9: os9gen /d1 (run os9gen)
/d0/os9boot (enter main boot file name)
/d0/tape.driver (enter name of first file to be added)
/d2/video.driver (enter name of second file to be added)
[ESCAPE] (enter end-of-file)
As above, but automatically by redirecting os9gen standard input:
OS9: build /d0/bootlist (use build to create file bootlist)
? /d0/os9boot (enter first file name)
? /d0/tape.driver (enter second file name)
? /d2/video.driver (enter third file name)
? (terminate build)
OS9: os9gen /d1 </d0/bootlist (run os9gen with redirected input)
Print full text error messages.
printerr
This command replaces the basic OS-9 error printing routine (F$Perr
service request) which only prints error code numbers, with a routine
the reads and displays textual error messages from the file
/d0/SYS/errmsg. Printerr's effect is system-wide.
A standard error message file is supplied with OS-9. This file can be edited or replaced by the system manager. The file is a normal text file with variable length line. Each error message line begins with the error number code (in ASCII characters), a delimiter, and the error message text. The error messages need not be in any particular order. Delimiters are spaces or any character numerically lower then $20. Any line having a delimiter as its first character is considered a continuation of the previous line(s) which permits multi-line error messages.
Important
If you invoke printerr, you can't undo it. Once
installed, don't unlink the printerr module. It uses
the current user's stack for an I/O buffer, so
reserve reasonably large stacks.
For more information, see Error reporting and The SYS directory.
OS9: printerr
Display processes.
procs [<opts>]
Displays a list of processes running on the system. Normally only
processes having the user's ID are listed, but if the -e option is
given, processes of all users are listed. The display is a snapshot
taken at the instant the command is executed: processes can switch
states rapidly, usually many times per second.
PROCS shows the user and process ID numbers, priority, state (process status), memory size (in 256 byte pages), primary program module, and standard input path.
For more information, see Processor time allocation and timeslicing, Process states, and Creation of new processes.
Level One Example:
User# Id pty state Mem Primary module
---- --- --- -------- --- --------------
0 2 0 active 2 Shell
0 1 0 waiting 1 SysGo
1 3 1 waiting 2 Tsmon
1 4 1 waiting 4 Shell
1 5 1 active 64 Basic09
Print the working or execution directory.
pwd
pxd
Pwd displays a pathlist that shows the path from the root directory to
the user's current data directory. Programs can use it to
discover the actual physical location of files, or by humans who get
lost in the file system. Pxd is identical except that is shows the
pathlist of the user's current execution directory.
OS9: chd /d1/STEVE/TEXTFILES/MANUALS
OS9: pwd
/d1/STEVE/TEXTFILES/MANUALS
OS9: chd ..
OS9: pwd
/d1/STEVE/TEXTFILES
OS9: chd ..
OS9: pwd
/d1/STEVE
OS9: pxd
/d0/CMDS
Change the name of a file.
rename <path1> <path2>
Gives the mass storage file specified in the pathlist a new name. The
user must have write permission for the file to change its name. It's
not possible to change the names of devices, ., or ..
rename blue purple
rename /D3/user9/test temp
OS9: dir
Directory of . 16:22:53
myfile animals
OS9:rename animals cars
OS9:dir
Directory of . 16:23:22
myfile cars
Basic09 run time package.
runb <modname>
Basic09 run time package
Once one or more Basic09 procedures are debugged to the programmer's satisfaction, they can be packed or converted permanently to the bytecode form.
Packed Basic09 procedures are in fact OS-9 modules, and the OS-9 shell recognizes them as I-code and passes them off to the virtual machine emulator RunB for execution. RunB avoids a great deal of the overhead of the typical interpreted BASICs of the day -- not to mention that one can do integer calculations where appropriate rather than doing everything in floating point -- so that Basic09 programs run very quickly in comparison with interpreted BASICs.
Save memory module(s) on a file.
save <path> <modname> {<modname>}
Creates a new file and writes a copy of the memory module(s) specified on to the file. The module name(s) must exist in the module directory when saved. The new file is given access permissions for all modes except public write.
Note
save's default directory is the current data directory.
Executable modules should generally be saved in the default execution
directory.
save wordcount wcount
save /d1/mathpack add sub mul div
Activate and set the system clock.
setime y,m,d,h,m,s
This command sets the system date and time, then activates the real time
clock. The date and time can be entered as parameters, or if no
parameters are given, setime issues a prompt. Numbers are one or
two decimal digits using space, colon, semicolon or slash delimiters.
OS-9 system time uses the 24 hour clock. For example, 1520 is 3:20 PM.
Important
This command must be executed before OS-9 can perform multitasking operations. If the system doesn't have a real time clock this command should still be used to set the date for the file system.
Tip
Systems With Battery Backed up Clocks - setime should still be run to start time-slicing, but only the year
need be given, the date and time is read from the clock.
OS9: setime 82,12,22,1545 (Set to: Dec. 12, 1981, 3:45 PM)
OS9: setime 821222 154500 (Same as above)
OS9: setime 82 (For system with battery-backup clock)
Set a process' priority.
setpr <procID> <number>
This command changes the CPU priority of a process. It may only be used
with a process having the user's ID. The process number is a decimal
number in the range of 1 (lowest) to 255. Use procs to obtain process ID numbers and present priority.
Note
This command doesn't appear in the CMDS directory as it's built-in to the shell.
For more information, see Processor time allocation and timeslicing, and PROCS.
setpr 8 250 (change process #8 priority to 250)
OS9: procs
User # Id pty state Mem Primary module
----- --- --- -------- --- --------------
0 3 0 waiting 2 Shell <TERM
0 2 0 waiting 2 Shell <TERM
0 1 0 waiting 1 Sysgo <TERM
OS9: setpr 3 128
OS9: procs
User # Id pty state Mem Primary module
----- --- --- -------- --- --------------
0 3 128 active 2 Shell <TERM
0 2 0 waiting 2 Shell <TERM
0 1 0 waiting 1 Sysgo <TERM
OS-9 command interpreter.
shell [<opts>]
The shell is OS-9's command interpreter program. It reads data from
its standard input path (the keyboard or a file), and interprets the
data as a sequence of commands. - The basic function of the shell is to
initiate and control execution of other OS-9 programs.
The shell reads and interprets one text line at a time from the standard input path. After interpretation of each line it reads another until an end-of-file condition occurs, at which time it terminates itself. A special case is when the shell is called from another program, in which case it takes the parameter area (rest of the command line) as its first line of input. If this command line consists of built in commands only, more lines are read and processed; otherwise control returns to the calling program after the shell processes the single command line.
The rest of this description is a technical specification of the shell
syntax. Use of the shell is described fully in Chapters 2 and 4 of
this manual.
pgm line := pgm {pgm}
pgm := [params] [name [modif] [pgm params] [modif] ] [sep]
Program Specifications
name := module name
:= pathlist
:= (pgm list)
Parameters
params := param {delim param}
delim := space or comma characters
param := ex name [modif] chain to program specified
:= chd pathlist change working directory
:= kill procID send abort signal to process
:= setpr procID pty change process priority
:= chx pathlist change execution directory
:= w wait for any process to die
:= p turn `OS9:` prompting on
:= -p turn prompting off
:= t echo input lines to std output
:= -t don't echo input lines
:= -x dont abort on error
:= x abort on error
:= * text comment line: not processed
sep := ; sequential execution separator
:= & concurrent execution separator
:= ! pipeline separator
:= cr end-of-line (sequential execution separator)
Modifiers
modif := mod { delim mod }
mod := < pathlist redirect standard input
:= > pathlist redirect standard output
:= >> pathlist redirect standard error output
:= # integer set process memory size in pages
:= # integer K set program memory size in 1K increments
Suspend process for period of time
sleep <ticks>
This command puts the user's process to sleep for a number of clock ticks. It's generally used to generate time delays or to break up CPU-intensive jobs. The duration of a tick is 16.66 milliseconds.
A tick count of 1 causes the process to give up its current time slide. A tick count of zero causes the process to sleep indefinitely (usually awakened by a signal)
OS9: sleep 25
Copy standard input to multiple output paths
tee {<path>}
This command is a filter (see Pipes and filters) that copies all text lines from its standard input path to the standard output path and any number of additional output paths whose pathlists are given as parameters.
The example below uses a pipeline and tee to simultaneously send the
output listing of dir to the terminal, printer, and a disk
file:
dir e ! tee /printer /d0/dir.listing
The following example sends the output of an assembler listing to a disk file and the printer:
asm pgm.src l ! tee pgm.list >/printer
The example below broadcasts a message to four terminals:
echo WARNING System down in 10 minutes ! tee /t1 /t2 /t3 /t4
Change terminal operating mode
tmode {.} <pathnum> [<opts>]
This command displays or changes the operating parameters of the user's terminal.
If no arguments are given, the present values for each parameter are displayed, otherwise, the parameter(s) given in the argument list are processed. Any number of parameters can be. given, and are separated by spaces or commas. A period and a number can be used to optionally specify the path number to be affected. If none is given, the standard input path is affected.
Note
If you use this command in a shell procedure file, use the
.<pathnum> option to specify one of the standard output
paths (0, 1 or 2) in order to change the terminal's operating characteristics.
The change remains in effect until the path closes. To effect a
permanent change to a device characteristic, change the device descriptor with xmode instead. This command works only if a path to the file/device is already
open.
| PARAMETER | DESCRIPTION |
|---|---|
| upc | Uppercase flag. 1 = all characters convert to uppercase. 0 = upper and lowercase (default). |
| bsb | Erase on backspace. 1 = backspace characters echoed as a backspace-space-backspace sequence (default). 0 = no erase on backspace; echoes single backspace only. |
| bsl | Backspace over line. 1 = lines are deleted by sending backspace-space-backspace sequences to erase the same line (default). 0 = no backspace over line: lines are deleted by printing a new line sequence (for hard-copy terminals). |
| eko | Echo input characters (default). 1 = characters echo back to the terminal. 0 = no echo. |
| alf | Auto line feed (default). 1 = line feeds automatically echo to the terminal on input and output carriage returns. 0 = auto line feed is off. |
| pau | Screen pause. 1 = output suspended upon full screen (see pag parameter for definition of screen size); output resumes when typing a key.0 = screen pause off. |
| nul | Null count. The number of null ($00) characters transmitted after carriage returns for return delay. Default is $00. |
| pag | Screen page length. Used when pau is 1. |
| bsp | Input backspace character. Default is $08 (CTRL-H). |
| bse | Output backspace character. Default is $08 (CTRL-H). |
| del | Input delete line character. Default is $18 (CTRL-X). |
| ovf | Overflow (alert) output character. Default is $07 (CTRL-G). |
| eor | End-of-record (carriage return) input character. Default is $0D (CTRL-M). |
| eof | End-of-file input character. Default is $1B. |
| typ | ACIA initialization value, sets parity, word size, and stop bits. |
| rpr | Reprint line character. |
| dup | Duplicate last input line character. |
| psc | Pause character. |
| int | Interrupt character. Default is $03 (CTRL-C). |
| qut | Quit character. Default is $05 (CTRL-E). |
| bau | Baud rate for software-controllable interface. Numeric code mapping: 0=110 1=300 2=600 3=1200 4=2400 5=4800 6=9600 7=19200. |
tmode upc=1 alf=1 nul=4 bselF pau=1
tmode pag=24 pau=0 bsl -echo bsp=8 bsl=C
Note
If you use tmode in a procedure file, it's necessary to
specify one of the standard output paths (.1 or .2) since the shell's
standard input path is redirected to the disk file (Tmode
can be used on an SCFMAN-type devices only). Example:
tmode .1 pag=24 (set lines/page on standard output)
Timesharing monitor.
tsmon <path>
This command supervises idle terminals and initiate the login
sequence in timesharing applications. If a pathlist is given, standard
I/O paths are opened for the device. When a carriage return is typed,
tsmon automatically calls login. If the login fails
because the user could not supply a valid user name or password, it will
return to tsmon.
Note
login and its password file must be present for
tsmon to work correctly (see LOGIN).
Most programs terminate when an end of file character (escape) is
entered as the first character on a command line. This logs you off
of the system and return control to tsmon.
For more information, see Setting up timesharing system procedure files, and LOGIN.
OS9:tsmon /t1&
&005
Tune the printer port on the Color Computer.
tuneport <devname> [<opts>]
This command lets you test and set delay loop values for the current baud rate and select the best value for your printer or terminal.
Examples
tuneport /p
Provides a text operation for your printer. After a short delay,
tuneport displays the current baud rate and sends data to the printer to
test if it's working properly. The program then displays the current
delay value and asks for a new value. Enter a decimal delay value and
press [ENTER]. Again, test data is sent to the printer as a test.
Continue this process until you find the best value. When you are
satisfied, press [ENTER] instead of entering a value at the prompt. A
closing message displays your new value.
Use the same process to set a new delay loop value for /t1 terminal
tuneport /p -s=225
Sets the delay loop value for your printer at 225. Use such a command on
future system boots to set the optimum delay value determined with
tuneport. Then, using os9gen or cobbler, generate a new
boot file for your system diskette. You can also use tuneport in your
system startup file to set the value using the -s option.
Unlink memory modules.
unlink <modname> {<modname>}
Tells OS-9 that the memory module(s) named are no longer needed by the user. The module(s) may or may not be destroyed and their memory reassigned, depending on if in use by other processes or user, whether resident in ROM or RAM.
It's good practice to unload modules whenever possible to make most efficient use of available memory resources.
Warning
Never unlink a module you did not load or link to.
For more information, see Basic memory management functions, Loading program modules into memory, and Loading multiple programs.
unlink pgml pgm5 pgm99
OS9: mdir
Module Directory at 11:26:22
DCB4 D0 D1 D2 D3
OS9P2 INIT OS9 IOMAN RBF
SCF ACIA TERM T1 T2
T3 P PIA Sysgo Clock
Shell Tsmon Edit
OS9: unlink edit
OS9: mdir
Module Directory at 11:26:22
DCB4 D0 D1 D2 D3
OS9P2 INIT OS9 IOMAN RBF
SCF ACIA TERM T1 T2
T3 P PIA Sysgo Clock
Shell Tsmon
Verify or update module header and CRC values.
verify [<opts>]
This command verifies that module header parity and CRC value of one or more modules on a file (standard input) are correct. Module(s) are read from standard input, and messages are sent to the standard error path.
If the -u (update) option is specified, the module(s) are copied to
the standard output path with the module's header parity and CRC values
replaced with the computed values. A message is displayed to
indicate whether or not the module's values matched those computed by
verify.
If the option is NOT specified, the module won't be copied to
standard output. Verify only displays a message to indicate
whether or not the module's header parity and CRC matched those which
were computed.
OS9: verify <EDIT >NEWEDIT
Module's header parity is correct.
Calculated CRC matches module's.
OS9: verify <myprograml >myprogram2
Module's header parity is correct.
CRC does not match.
OS9: verify <myprogram2
Module's header parity is correct.
Calculated CRC matches module's.
OS9: verify -u <module >temp
Examine or change device initialization mode values.
xmode <devname> [<opts>]
This command displays or changes the initialization parameters of any SCF-type device such as the video display, printer, or serial port. A common use is to change baud rates and control key definitions.
xmode is very similar to tmode. tmode only operates on
open paths so its effect is temporary. xmode updates the
device descriptor so the change persists as long as the computer is
running, even if paths to the device are repetitively opened and closed.
If you use xmode to change parameters, then use cobbler to make a new system disk,
the changed parameter is permanently reflected on the new system disk.
xmode requires a device name to be given. If no arguments are given,
the present values for each parameter are displayed, otherwise, the
parameter(s) given in the argument list are processed. Any number of
parameters can be given, and are separated by spaces or commas.
The parameters for xmode are the same as tmode. Refer to TMODE for the parameter names and values.
xmode /term upc=0 alf=1 nul=4 bse=1F pau=1
xmode /t1 pag=24 pau=1 bsl=1 eko=0 bsp=8 bsl=C
xmode /p bau=3 alf=0
The error codes are shown in both hexadecimal (first column) and decimal (second column). Error codes other than those listed are generated by programming languages or user programs.
| HEX | DEC | ERROR DESCRIPTION |
|---|---|---|
| $C8 | 200 | PATH TABLE FULL - The file cannot be opened because the system path table is currently full. |
| $C9 | 201 | ILLEGAL PATH NUMBER - Number too large or for non-existent path. |
| $CA | 202 | INTERRUPT POLLING TABLE FULL. |
| $CB | 203 | ILLEGAL MODE - Attempt to perform I/O function that the device or file is incapable of. |
| $CC | 204 | DEVICE TABLE FULL - Can't add another device. |
| $CD | 205 | ILLEGAL MODULE HEADER - Module not loaded because its sync code, header parity, or CRC is incorrect. |
| $CE | 206 | MODULE DIRECTORY FULL - Can't add another module. |
| $CF | 207 | MEMORY FULL - Level One: Not enough contiguous RAM free. Level Two: Process address space full. |
| $D0 | 208 | ILLEGAL SERVICE REQUEST - System call had an illegal code number. |
| $D1 | 209 | MODULE BUSY - Non-sharable module is in use by another process. |
| $D2 | 210 | BOUNDARY ERROR - Memory allocation or deallocation request not on a page boundary. |
| $D3 | 211 | END OF FILE - End of file encountered on read. |
| $D4 | 212 | RETURNING NON-ALLOCATED MEMORY - Attempted to deallocate memory not previously assigned. |
| $D5 | 213 | NON-EXISTING SEGMENT - Device has damaged file structure. |
| $D6 | 214 | NO PERMISSION - File attributes do not permit access requested. |
| $D7 | 215 | BAD PATH NAME - Syntax error in pathlist (illegal character). |
| $D8 | 216 | PATH NAME NOT FOUND - Can't find pathlist specified. |
| $D9 | 217 | SEGMENT LIST FULL - File is too fragmented to be expanded further. |
| $DA | 218 | FILE ALREADY EXISTS - File name already appears in current directory. |
| $DB | 219 | ILLEGAL BLOCK ADDRESS - Device's file structure has been damaged. |
| $DC | 220 | ILLEGAL BLOCK SIZE - Device's file structure has been damaged. |
| $DD | 221 | MODULE NOT FOUND - Request for link to module not found in directory. |
| $DE | 222 | SECTOR OUT OF RANGE - Device file structure damaged or incorrectly formatted. |
| $DF | 223 | SUICIDE ATTEMPT - Request to return memory where your stack is located. |
| $E0 | 224 | ILLEGAL PROCESS NUMBER - No such process exists. |
| $E2 | 226 | NO CHILDREN - Can't wait because process has no children. |
| $E3 | 227 | ILLEGAL SWI CODE - Must be 1 to 3. |
| $E4 | 228 | PROCESS ABORTED - Process aborted by signal code 2. |
| $E5 | 229 | PROCESS TABLE FULL - Can't fork now. |
| $E6 | 230 | ILLEGAL PARAMETER AREA - High and low bounds passed in fork call are incorrect. |
| $E7 | 231 | KNOWN MODULE - For internal use only. |
| $E8 | 232 | INCORRECT MODULE CRC - M odule has bad CRC value. |
| $E9 | 233 | SIGNAL ERROR - Receiving process has previous unprocessed signal pending. |
| $EA | 234 | NON-EXISTENT MODULE - Unable to locate module. |
| $EB | 235 | BAD NAME - Illegal name syntax. |
| $EC | 236 | BAD HEADER - Module header parity incorrect. |
| $ED | 237 | RAM FULL - No free system RAM available at this time. |
| $EE | 238 | UNKNOWN PROCESS ID - Incorrect process ID number. |
| $EF | 239 | NO TASK NUMBER AVAILABLE - All task numbers in use. |
The following error codes are generated by I/O device drivers, and are somewhat hardware dependent. Consult manufacturer's hardware manual for more details.
| HEX | DEC | ERROR DESCRIPTION |
|---|---|---|
| $F0 | 240 | UNIT ERROR - Device unit does not exist. |
| $F1 | 241 | SECTOR ERROR - Sector number is out of range. |
| $F2 | 242 | WRITE PROTECT - Device is write protected. |
| $F3 | 243 | CRC ERROR - CRC error on read or write verify. |
| $F4 | 244 | READ ERROR - Data transfer error during disk read operation, or SCF (terminal) input buffer overrun. |
| $F5 | 245 | WRITE ERROR - Hardware error during disk write operation. |
| $F6 | 246 | NOT READY - Device has "not ready" status. |
| $F7 | 247 | SEEK ERROR - Physical seek to non-existant sector. |
| $F8 | 248 | MEDIA FULL - Insufficient free space on media. |
| $F9 | 249 | WRONG TYPE - Attempt to read incompatible media (for example, attempt to read double-side disk on single-side drive). |
| $FA | 250 | DEVICE BUSY - Non-sharable device is in use. |
| $FB | 251 | DISK ID CHANGE - Media was changed with files open. |
| $FC | 252 | RECORD IS LOCKED-OUT - Another process is accessing the requested record. |
| $FD | 253 | NON-SHARABLE FILE BUSY - Another process is accessing the requested file. |
NORM SHFT CTRL NORM SHFT CTRL NORM SHFT CTRL
---- ---- ------ ---- ---- ------ ---- ---- ------
0 30 0 30 -- @ 40 ' 60 NUL 00 P 50 p 70 DLE 10
1 31 1 21 | 7C A 41 a 61 SOH 01 Q 51 q 71 DC1 11
2 32 " 22 00 B 42 b 62 STX 02 R 52 r 72 DC2 12
3 33 # 23 - 7E C 43 c 63 ETX O3 S 53 s 73 DC3 13
4 34 $ 24 00 0 44 d 64 EOT 04 T 54 t 74 DC4 14
5 35 % 25 00 E 45 e 65 END O5 U 55 u 75 NAK 15
6 36 & 26 00 F 46 f 66 ACK 06 V 56 V 76 SYN 16
7 37 ' 27 5E G 47 g 67 BEL O7 W 57 w 77 ETB 17
8 38 ( 28 [ 5B H 48 h 68 BSP 08 X 58 x 78 CAN 18
9 39 ) 29 ] 5D I 49 i 69 HT O9 Y 59 y 79 EM 19
: 3A * 2A 00 J 4A j 6A LF CA Z 5A z 7A SUM 1A
; 3B + 2B 00 K 4B k 6B VT OB
, 2C < 3C { 7B L 4C l 6C FF 0C
- 2D = 3D - 5F M 4D m 6D CR 00
. 2E > 3E } 7D N 4E n 6E CO CE
/ 2F ? 3F \ 5C O 4F o 6F CI OF
FUNCTION KEYS
NORM SHFT CTRL
---- ---- ----
BREAK 05 03 1B
ENTER 0D 0D 0D
SPACE 20 20 20
<- 08 18 10
-> 09 19 11
v 0A 1A 12
^ 0C 1C 13
NitrOS-9: Empowering 6809 CPUs with a modern, efficient operating system