Skip to main content

Full text of "Australian National OS9 Newsletter (October 1992)"

See other formats

Unlink < mod name > Usage : Unlinks module (s) from memory 
@WCREATE Syntax: Wcreate [opt] or /wX [-s=type] xpos ypos 
xsiz ysiz fcol bcol [bord] Usage : Initialize and create windows 

Opts : -? 
= display 
help -z = 


lines from 
s t d i n 
-s=type = 

set screen 
type for a 

window on a new screen @XMODE Syntax: XMode <devname> 
[params] Usage : Displays or changes theparameters of an SCF 
type device @COCOPR Syntax: cocopr [<opts>] {<path> 
[<opts>]} Function: display file in specified format gets defaults 
from /dd/sys/env.file Options : -c set columns per page -f use 
form feed for trailer -h=num set number of lines after header 

EDEFOR :M :: : 



Gordon I 

Bol , 

Don Be 

Jean-Pierre Jacquet 
Fax Messages 

Brisbane OS9 Users Group 




(07) 372-4675 

-l=num set line length -m=num set left margin -n=num set 
starting line number and incr -o truncate lines longer than Inlen 
-p=num set number of lines per page -t=num number of lines 

in trailer -u 

do not use 
-u= title 


Editorial Material: 
Gordon Bentzen 
8 Odin Street 

Library Requests: 
Jean-Pierre Jacquet 
27 Hampton Street 
DURACK Qld 4077 






-z[=path] read 
file names 

from stdin or 
<path> if 

=4 given 
©CONTROL Syntax: control [-e] Usage : Control Panel to set 
palettes, mouse and keyboard parameters and monitor type for 


Bditorial Page2 

C Tutorial chaplO .. Page3 
FAT Display prog ... Page6 

0S9 Attitude Page7 

Ed & Rev limbers .. Pagel4 

Volume 6 

October 1992 

Number 9 

Multi-Vue. Selectable from desk utilities menu as the Control 
Panel. Opts : -e = execute the environment file @GCLOCK 


Newsletter of the National 0S9 User Group 

Volume 6 Number 9 

EDITOR : Gordon Bentzen 
SUBEDITOR : Bob Devries 


SUPPORT : Brisbane 0S9 Level 2 Users Group. 

Don Berrie 
Jean-Pierre Jacquet 

This OS-9 Machine just won't die! I refer of course 
to the humble CoCo3 with its Level 2 version of 6809 
OS-9 which is still in use by the majority of our 
members. And a National CoCoFest in Melflburne later 
this month even yet I 

It is great to see this continued support for OS-9 
and the National OS-9 Usergroup for yet another year. 
Our membership for the new subscription year has 
already reached 46 which I must say has somewhat 
surprised us in spite of an active International OS-9 

As we have suggested several times before, the future 
of OS-9 for personal users will rest with OSK and the 
68xxx based machines. We are anxiously awaiting an 
article from Don Berrie on his recently acquired MM/1 
and from what I have observed of Don's demos, the 
MM/1 runs just like a CoCo but MUCH, MUCH faster. 

So for those OSK'ers who have supported us for such a 
long time, we are certain to have more of interest 
for you in the pages of future newsletters. So what 
about an article from you to get things rolling? 

It is probably about time that I got serious again 
about our appeal for newsletter articles, so how 
about each of you take the time to send us something 
to share with others. Submissions to the newsletter 
can take the form of a tutorial, hints and tips, 
questions or problems or even some of those 
frustrations. In fact anything at all to do with 0S- 
9 would be of interest to others. 

improvement. A good friend of mine had generously 
offered to me a spare RLL controller card which would 
suit the Burke & Burke interface and allow my /HO 20 
meg drive to be formatted to 30 meg, and my /HI 10 
meg drive to be formatted to 15 meg. A total of 45 
meg Hard Disk storage instead of 30 meg. This just 
had to be a worthwhile upgrade, so let's get into it. 
THE PLAN Now the first thing is to make a "backup" 
of /HO. That took just sixteen 80 track 720k disks, 
not bad for what was there, and another ten 720k 
disks for the data on /HI. I used the Shareware 
programme "Stream" which was mentioned in last 
month's editorial. (Stream. ar is available from our 
librarian upon request) 

Next, new drive descriptors are needed for /HO and 
/HI. The utility supplied by Burke & Burke, DDMAKER 
is used to make the required descriptors. Then build 
a new 0S9Boot which will include the new descriptors. 
Now switch off the power and remove the old MFM 
controller card from the B & B interface, fit the RLL 
controller and put everything back together. Well 

Switch on and "boot" OS-9 from floppy drive /DO. So 
far so good. Make sure pause is not active on the 
Term window to be used, tmode -pause. Now the 
command, Format /HO. Several cups of coffee later, a 
"free /HO" command reports 120 thousand odd free 
sectors, 30meg, Great!! 

Next, "Bootport" 0S9Boot from the floppy to /HO, and 
then use "Stream" to restore all the files to the 
hard drive. Some time later this process is 
completed and the "acid test" is will it still "boot" 
from /HO. 


I would like to share with you one of my own little 
frustrations which involves Hard Drives on my CoCo3. 
I have been running a 20meg Hard Drive and Burke & 
Burke XT interface for some time now and wonder how I 
ever managed without it. As always happens though, 
no matter how much storage space, RAM or whatever one 
has, it inevitably seems to decrease to "not enough". 
Now one would think that having a reliable system 
that has given very little trouble over the past 
twelve months the wise thing would be to leave it 

Well, as we are not always driven by wisdom, I 
entered into a programme of significant system 

YOU GUESSED IT ! CoCo does not want to play anymore, 
0S-9 just won't "boot", and then it does. After 
several attempts it appears that the No-Go's far 
outweigh the Go's. The 0S9Boot is re-installed, 
checked, built again etc, until, with time running 
short and the newsletter due out, a decision needs to 
be made. So everything is undone and the MFM 
controller is again in charge of a 20meg /h0 and 
lOmeg /hi. 

Where else could one get such entertainment? 

Cheers, Gordon. 

Page 2 

October 1992 


A C Tutorial 
Chapter 10 - File Input/Output 


Load and display the file named FORMOUT.C for your 
first example of writing data to a file. We begin as 
before with the 'include' statement for 'stdio.h', 
then define some variables for use in the example 
including a rather strange looking new type. The type 
'FILE' is used for a file variable and is defined in 
the 'stdio.h' file. It is used to define a file 
pointer for use in file operations. The definition of 
C contains the requirement for a pointer to a 'FILE', 
and as usual, the name can be any valid variable name. 


Before we can write to a file, we must open it. 
What this really means is that we must tell the system 
that we want to write to a file and what the filename 
is. We do this with the 'fopen' function illustrated 
in the first line of the program. The file pointer, 
■fp' in our case, points to the file and two arguments 
are required in the parentheses, the filename first, 
followed by the file type. The filename is any valid 
DOS filename, and can be expressed in upper or lower 
case letters, or even mixed if you so desire. It is 
enclosed in double quotes. For this example we have 
chosen the name TENLINES.TXT. This file should not 
exist on your disk at this time. If you have a file 
with this name, you should change its name or move it 
because when we execute this program, its contents 
will be erased. If you don't have a file by this 
name, that is good because we will create one and put 
some data into it. 

READING ("r') 

The second parameter is the file attribute and can 
be any of three letters, 'r\ V, or 'a 1 , and must be 
lower case. When an 'r' is used, the file is opened 
for reading, a V is used to indicate a file to be 
used for writing, and an 'a' indicates that you desire 
to append additional data to the data already in an 
existing file. Opening a file for reading requires 
that the file already exist. If it does not exist, 
the file pointer will be set to NULL and can be 
checked by the program. 


When a file is opened for writing, it will be 
created if it does not already exist and it will be 
reset if it does resulting in deletion of any data 
already there. 


When a file is opened for appending, it will be 
created if it does not already exist and it will be 
initially empty. If it does exist, the data input 
point will be the end of the present data so that any 
new data will be added to any data that already exists 
in the file. 


The job of actually outputting to the file is 
nearly identical to the outputting we have already 
done to the standard output device. The only real 
differences are the new function names and the 
addition of the file pointer as one of the function 
arguments. In the example program, 'fprintf replaces 
our familiar 'printf function name, and the file 
pointer defined earlier is the first argument within 
the parentheses. The remainder of the statement looks 
like, and in fact is identical to, the 'printf 


To close a file, you simply use the function 
■fclose' with the file pointer in the parentheses. 
Actually, in this simple program, it is not necessary 
to close the file because the system will close all 
open files before returning to DOS. It would be good 
programming practice for you to get in the habit of 
closing all files in spite of the fact that they will 
be closed automatically, because that would act as a 
reminder to you of what files are open at the end of 
each program. You can open a file for writing, close 
it, and reopen it for reading, then close it, and open 
it again for appending, etc. Each time you open it, 
you could use the same file pointer, or you could use 
a different one. The file pointer is simply a tool 
that you use to point to a file and you decide what 
file it will point to. Compile and run this program. 
When you run it, you will not get any output to the 
monitor because it doesn't generate any. After 
running it, look at your directory for a file named 
TENLINES.TXT and 'type' it. That is where your output 
will be. Compare the output with that specified in 
the program. It should agree. Do not erase the file 
named TENLINES.TXT yet. We will use it in some of the 
other examples in this chapter. 


Load the next example file, CHAROUT.C, and display 
it on your monitor. This program will illustrate how 

Page 3 

October 1992 


to output a single character at a tine. The program 
begins with the 'include 1 statement, then defines soie 
variables including a file pointer. We have called 
the file pointer 'point' this tine, but we could have 
used any other valid variable naoe. Ve then define a 
string of characters to use in the output function 
using a 'strcpy' function. We are ready to open the 
file for appending and we do so in the 'fopen' 
function, except this time we use the lower cases for 
the filename. This is done simply to illustrate that 
DOS doesn't care about the case of the filenaie. 
Notice that the file will be opened for appending so 
we will add to the lines inserted during the last 
program. The program is actually two nested 'for' 
loops. The outer loop is simply a count to ten so 
that we will go through the inner loop ten times. The 
inner loop calls the function 'putc' repeatedly until 
a character in "others' is detected to be a zero. 


The part of the program we are interested in is 
the 'putc' function. It outputs one character at a 
time, the character being the first argument in the 
parentheses and the file pointer being the second and 
last argument. Vhy the designer of C made the pointer 
first in the ■fprlntf ■ function, and last in the 
■putc' function is a good question for which there may 
be no answer. It seems like this would have been a 
good place to have used some consistency, When the 
textline "others' is exhausted, a newline is needed 
because a newline was not included in the definition 
above. A single 'putc 1 is then executed which outputs 
the '\n' character to return the carriage and do a 
linefeed. When the outer loop has been executed ten 
times, the program closes the file and terminates. 
Compile and run this program but once again there will 
be no output to the monitor. Following execution of 
the program, 'type' the file named TENLINES.TXT and 
you will see that the 10 new lines were added to the 
end of the 10 that already existed. If you run it 
again, yet another 10 lines will be added. Once 
again, do not erase this file because we are still not 
finished with it. 


Load the file named READCHAR.C and display it on 
your monitor. This is our first prograa to read a 
file. This program begins with the familiar 
'include', some data definitions, and the file opening 
statement which should require no explanation except 
for the fact that an 'r 1 is used here because we want 
to read it. In this program, we check to see that the 
file exists, and if it does, we execute the main body 
of the program. If it doesn't, we print a message and 
quit. If the file does not exist, the system will set 

the pointer equal to NOLL which we can test. The main 
body of the program is one "do while" loop in which a 
single character is read from the file and output to 
the monitor until an EOF (end of file) is detected 
from the input file. The file is then closed and the 
program is terminated. 


At this point, we have the potential for one of 
the most common and most perplexing problems of 
programming in C. The variable returned from the 
■getc" function is a character, so we could use a 
"char" variable for this purpose. There is a problem 
with that however, because on some, if not most, 
implementations of C, the EOF returns a minus one 
which a "char" type variable is not capable of 
containing. A 'char' type variable can only have the 
values of zero to 255, so it will return a 255 for a 
minus one on those compilers that use a minus one for 
EOF. This is a very frustrating problem to try to 
find because no diagnostic is given. The program 
simply can never find the EOF and will therefore never 
terminate the loop. This is easy to prevent, always 
use an 'int' type variable for use in returning an 
EOF. You can tell what your compiler uses for EOF hy 
looking at the "stdio.h' file where EOF is defined. 
That is the standard place to define such values. 
There is another problem with this program but we will 
worry about it when we get to the next program and 
solve it with the one following that. After you 
compile and run this program and are satisfied with 
the results, it would be a good exercise to change the 
name of 'TENLINES.TXT' and run the program again to 
see that the NOLL test actually works as stated. Be 
sure to change the name back because we are still not 
finished with ■TENLINES.TXT 1 . 


Load and display the file named READTEXT.C for an 
example of how to read a word at a time. This program 
is nearly identical as the last except that this 
program uses the "fscanf function to read in a string 
at a time. Because the 'fscanf function stops 
reading when it finds a space or a newline character, 
it will read a word at a time, and display the results 
one word to a line. You will see this when you 
compile and run it, but first we must examine a 
programming problem. 


Inspection of the program will reveal that when we 
read data in and detect the EOF, we print out 
something before we check for the EOF resulting in an 
extra line of printout. What we usually print out is 

October 1992 

Page 4 


the same thing printed on the prior pass through the 
loop because it is still in the buffer 'oneword'. We 
therefore Must check for EOF before we execute the 
■printf ■ function. This has been done in READGOOD.C, 
which you will shortly examine, compile, and execute. 
Compile and execute the original program we have been 
studying, READTEXT.C and observe the output. If you 
haven't changed TENLINES.TXT you will end up with 
'Additional 1 and 'lines.' on two separate lines with 
an extra 'lines.' displayed because of the "printf 
before checking for EOF. Compile and execute 
READGOOD.C and observe that the extra 'Hnes.' does 
not get displayed because of the extra check for the 
EOF in the middle of the loop. This was also the 
problem referred to when we looked at READCHAR.C, but 
I chose not to expound on it there because the error 
in the output was not so obvious. 


Load and display the file READLINE.C for an 
example of reading a complete line. This program is 
very similar to those we have been studying except for 
the addition of a new quantity, the NULL. We are 
using 'fgets' which reads in an entire line, including 
the newline character into a buffer. The buffer to be 
read into is the first argument in the function call, 
and the maximum number of characters to read is the 
second argument, followed by the file pointer. This 
function will read characters into the input buffer 
until it either finds a newline character, or it reads 
the maximum number of characters allowed minus one. 
It leaves one character for the end of string NULL 
character. In addition, if it finds an EOF, it will 
return a value of NULL. In our example, when the EOF 
is found, the pointer 'c 1 will be assigned the value 
of NULL. NULL is defined as zero in your 'stdio.h' 
file. When we find that 'c 1 has been assigned the 
value of NULL, we can stop processing data, but we 
must check before we print just like in the last 
program. Last of course, we close the file. 

of reading from any file. This program asks the user 
for the filename desired, reads in the filename and 
opens that file for reading. The entire file is then 
read and displayed on the monitor. It should pose no 
problems to your understanding so no additional 
comments will be made. Compile and run this program. 
When it requests a filename, enter the name and 
extension of any text file available, even one of the 
example C programs. 


Load the last example file in this chapter, the 
one named PRINTDAT.C for an example of how to print. 
This program should not present any surprises to you 
so we will move very quickly through it. Once again, 
we open TENLINES.TXT for reading and we open PRN for 
writing. Printing is identical to writing data to a 
disk file except that we use a standard name for the 
filename. There are no definite standards as far as 
the name or names to be used for the printer, but some 

of the usual names are, 'PRN 1 

LPT 1 

'LPT1V and 

'LPT2'. Check your documentation for your particular 
implementation. Some of the newest compilers use a 
predefined file pointer such as 'stdprn 1 for the print 
file. Once again, check your documentation. The 
program is simply a loop in which a character is read, 
and if it is not the EOF, it is displayed and printed. 
When the EOF is found, the input file and the printer 
output files are both closed. You can now erase 
TENLINES.TXT from your disk. We will not be using it 
in any of the later chapters. 


I. Write a program that will prompt for a filename 
for a read file, prompt for a filename for a write 
file, and open both plus a file to the printer. 
Enter a loop that will read a character, and 
output it to the file, the printer, and the 
monitor. Stop at EOF. 


Load and display the file ANYFILE.C for an example 

Prompt for a filename to read. Read the file a 
line at a time and display it on the monitor with 
line numbers. 


Page 5 

October 1992 


File Allocation Table Display 

by Chris Bergerson 

edited by Bob Devries 

Here is one of the programmes I have recently boundaries. Previously, the author just left in the 

received through my affiliation with the 0S9 Community nap what data was read even though it did not 

Network, a group of 0S9 users who communicate represent the FAT data. Here now is the Basic09 

regularly via the FIDO BBS network. I have made one programme, with the docuient file after, as produced 

modification to the programme, commented by Chris Bergerson, and included in the archive, 
appropriately, to clear the garbage from the display Bob Devries 

where the graphics went beyond the actual FAT table 

PROCEDURE fatjisplay 

0000 (* Procedure to graphically display a disk's File Allocation Table 

0042 (* C. Bergerson 7/31/88 0S9 Level II 

0069 TYPE registers=cc,a,b,dp:BYTE; x,y,u:INTEGER 

008E DIM regs: registers 

0097 DIM dpathrBYTE 

009E DIM spath: INTEGER 

00A5 DIM name:STRING[3] 

00B1 DIM i,dd_map, pages, count: INTEGER 


00CB DIM aap(4960):BYTE \(* Approximately 10 meg at a time. 

00F9 \ \\ \\ \ \ \\ \(* (4960*8*256=10,158,080) 

011D DIM z:INTEGER \(* Added by Bob Devries 

013D RUN syscall($0C,regs) \(* Get process, user IDs 

0163 gr=regs.a \(* Group 1= Process ID 

0184 SHELL "merge /dd/sys/stdfonts;display lb 3a c8 01' 

01B2 OPEN »spath,7w' 

01BD RUN gfx2(spath,"DWSef,5,0,0,80,10,l,0,2) 

01E7 RUN gfx2(spath, , Selecf) 

01FA PRINT itspath, "Graphic File Allocation Table Display..." 

022B INPUT »spath,"Disk name to display, (e.g. /HO): \name 

025A OPEN »dpath,name+T:READ 

02 6A SEEK #dpath,4 \(* Go to LSN0, byte 4 for ddjaap 

0293 GET »dpath,dd_map \(* Get size of FAT 

02AF pages=INT((dd_map-l)/4960)+l \(* Do about 10 meg at a time 

02E0 SEEK »dpath,256 \(* Go to start of FAT 

0300 FOR count=l TO pages 

0311 (* RUN gfx2(spath, "clear") 

032B GET fdpath,map 

0335 IF count=pages THEN \(* Added by Bob Devries 

0359 FOR z=dd_map-(pages-l)*4960 TO 4960 \(* Added by Bob Devries 

038D map(z)=255 \(* Added by Bob Devries 

03AF NEXT z \(* Added by Bob Devries 

03D1 ENDIF \(* Added by Bob Devries 

03EA RUN gfx2(spath,"GPLoad\gr 1 l,5,639,61,4960) 

0413 PUT fspath,map 

041D RUN gfx2(spath,"Bell") 

042E RUN gfx2(spath, , Put\gr,l,0,0) 

044C RUN gfx2(spath,"CurtY",0,8) 

0464 PRINT f spath, "page '; count; " of "; pages; " "; 
RUN gfx2(spath,'CurfY",20,8) 

October 1992 Page 6 


04A0 INPUT #spath,"Press <enter> to continue" , name 

04C6 NEXT count 


04D2 RUN gfx2( H KillBuff\gr,l) 

04EA RUN gfx2(l, "Select") 

04FB RUN gfx2(spath, , DWEnd") 

050D CLOSE ffdpath 

0513 CLOSE Kspath 

Just what we needed... another utility 
graphically displaying a disk's free space! 


This program will create the required type 5 
window, and then ask for the name of the disk. It 
works quite well for hard disks. For floppies, only 
the first few lines will be meaningful, since I assume 
that the File Allocation Table represents at least 10 

Blue, (or black on a monocrome monitor), 
represents used clusters. White means that the 
clusters are free. Each pixel is one cluster. 

Runb and Gfx2 must be in memory or in your 

current execution directory! Program also will 

attempt to load /dd/sys/stdfonts, so you better be 

sure they're there. After unARing, be sure to set the 

e attribute, and move to your execution directory. 
Call by simply typing: 


I find this util kind of interesting for seeing 
how 0S9 fills up the disk. 

Questions/comments are welcome 

Chris Bergerson 
CIS 72227,127 


Getting the 0S9 Attitude 

(This is a limited peek into a powerful, complex 
system. It is not intended as a 'how to' manual, 
rather to help you "get the feel 1 . Some specifics are 
given and every attempt has been made to be accurate 
in these cases.) 

From the very outset I will make it clear that, as 
it comes, 0S9 for CoCo is a rather crippled system 
because of its packaging and lack of support from the 
producer. There are several things you can do, as 
soon as you are able, that will make it vastly 
superior to what it is in its original form. 

First, have Level 2 on a CoCo3. There is no 
comparison between a 32 or 40 column screen and an 80 
column screen, but for strange reasons 0S9 arrives in 
a low resolution package and on single sided, 35 track 
disks. Personally, I wouldn't even consider using it 
that way. It is like having a powerful new car with 
special full time brakes installed and all but one 
window painted black. 

So you have an 80 column computer; how do you get 0S9 
to use it? There is an article by RICKULAND entitled 
"The First Step" included in this collection. It 
tells you how to switch to 80 columns, double sided 40 
track disks and high speed drive stepping. It is a 

fairly long tedious procedure, but when it's done, 
you'll be able to see what you're doing and you'll 
have more than double the disk space. 

Another real aid 
Nodules database. 
Kevin Darling and 
TWO. Again it is a 

in using 0S9 is in the System 

It is written by 0S9 programmer 


task and a half to install, but is 

WELL worth it. It is a command line editor that makes 
life in the 0S9 world of long command lines greatly 
easier, especially if you're not an expert typist. If 
you do not have a friend who can install this feature 
for you the guys on the SIG will help you through it 
like they did me. I will talk more about this later. 

There are many other improvements and additions to 
0S9 that you will get as you go along, but these are 
tops in my opinion. Next in line would be the new 
shell, SHELL+, with several improvements. As of this 
writing the highest version is v2.1. The sooner you 
can arrive at an updated system the better off you'll 

Coming to 0S9 from CoCo Disk Extended Color BASIC 
involves something besides the software and dreams of 
owning a hard drive - if you don't already have one. 
No doubt you've heard about the power and versatility 

Page 7 

October 1992 


of 0S9. It is, indeed, several steps ahead of DECB in 
many respects. But the change in environments can be 
almost overwhelming if you don't grasp a few 
essentials - a few of the differences between DECB and 
0S9. You can't maintain a DECB attitude while 
learning 0S9. 

DECB is a BASIC language with some of the power of a 
DOS (disk operating system) thrown in. 0S9 is an 
operating system with some of the power of a language 
thrown in. This much is mundane. But getting into 
the actual differences is both interesting and 

A simple concept that sheds light on the move to 0S9 
can be illustrated this way. If you had all the money 
you wanted, but all audio/video systems were alike, it 
would take you minutes to buy a complete system. But 
with all the hundreds or thousands of TVs, CDs, amps, 
tuners, speakers, stereos, tape players, recorders, 
multi media systems, etc., etc., in the equation, it 
is a major job deciding on an intelligent system 

The more options an operating system has, the more 
decisions you must make, the more you must remember, 
and the more occasions you have to make mistakes. 
What might involve 3 factors in a simple system might 
involve 10 in a more powerful system. The 3 would 
give you 9 paths to choose from. The 10 would give 
you 100 choices - for starters. 

The importance of this point can't be over estimated. 
And it directly relates to one of the things that 
causes the most trouble and consternation to new 0S9 
users - multiple directory disk organization. That 
will be our starting point and our prime 

For all practical purposes an 0S9 system might as 
well have 6 or 8 (or more) different drives. You can 
imagine how much you could do by organizing them all 
in creative order! But you can also imagine the 
headaches of remembering which drive had what on it if 
they weren't organized. This dilemma would ideally be 
solved by arranging them in a logical heirarchical 

Which drives would get which files? Remember, we're 
talking about much power and large numbers of files! 
And, to make it interesting most of the commands you 
would use like "deldir 1 aren't usually in memory, but 
on disk! To get all the power, THERE ARE SO MANY 
commands they'd choke the computer if you put them all 
in memory at the same time! And you'd go crazy looking 
for the right one on the disk - except for the 

(Pay close attention to the use of words like 'might 1 
and "could 1 . This is not a "how to 1 article. I will 
go out of my way to avoid setting down 'how to" rules 
while hypothesizing.) 

A level of organization is USUALLY, but not always 
(another variable) indicated by a '/' mark. Let's 
look at some levels. 

Within the disk in a drive there might be a section 
of commands. Listed under commands (besides scores of 
things we usually think of as commands) might be WP, a 
word processor, and SS a spread sheet . Let's see 
what this starts to look like. Then I'll back up and 
make things better (and relieve those who just KNOW 
I'm doing this wrong.). 

You start with a '/' for the top level / 
You add a drive number /d0 
You add another ■/' for a level within dO /d0/ 
You add the commands identifier /dO/cmds 
You add another level indicator /dO/cmds/ 
Finally the name of the word processor 

In BASIC you enter RUN'WP 1 . In 0S9 you enter 
/dO/cmds/wp. A 3 level command. (Nothing magic about 
the '3\ There can be more levels.) Let's do a tiny 
bit of computing - deleting WP from the disk. That 
will add another dimension to remember. If there were 
only one level you could enter 'del wp. 1 But the 
computer wants something like this: del /dO/cmds/wp 
The real beginners 0S9 system usually starts with 2 
drives at the top level of organization. So let's put 
a backup copy of WP on the other drive - drive 1. 
Let's see how complicated this can turn out: 

First you would divide everything up into files that 
do work and files that are worked on - executable 
files and data files. If you have a great many 
executable files you might have to divide them into 2 
or more sets. The data files must be divided into 
many more sets and subsets. There are data files like 
messages, there are tables, lists, subroutines, logs, 
graphics, music, controls, etc. Some files even defy 

copy /dO/cmds/wp /dl/cmds/wp 

Already you can see something that is similar to DECB 
- spaces separate items within a statement. Something 
different is that both the word 'copy 1 and the word 
'WP 1 are executable and considered commands on the 
disk. Some people separate these kinds of files 
making yet another thing to remember. Now remember 
that you have tons of stuff on your disk - commands 

October 1992 

Page 8 


and data. The authors of 0S9 came up with a way to 
cut down on a lot of the typing you need to do to 
slice through all the levels of organization. You can 
set the systei to know what drive and/or level you're 
working with and whether it is executable or data. 
Voila, the commands CHD (data) and CHX (executable). 
(Let's switch to computer talk for these levels of 

What they are called is directories and sub- 
directories. Like a general index for an encyclopedia 
then a different index for each book.) If you enter 
"chx /dO/cmds' you set the executable commands pointer 
to that drive and directory. Then you can leave off 
that part from a typed command! Since WP is in the 
cmds directory, to get it you just enter 'wp'! At this 
point you could delete it by entering "del wp." 
Simplifies things, doesn't it? 

(Let's do some more computerese. After the command 
itself, a line like we've been using is called a 
pathlist. It indicates the path down through the 
levels of directories to a given item you're after. 
Remember - the effective name [pathlist] of a file 
includes the names of the drives and directories above 
the filename itself.) These helpful commands (CHD and 
CHX) are perhaps even more time saving if you're 
dealing with data. For example, if you have to 
decompress several files that are located in the ARC 
directory, you could enter: 

■chd /dl/arc". 

Then you could call all the files without the full 
command line and all the files you decompress 
(dearchive) would be stored in that same directory. 
(Still more. When you set chx to a directory it is 
then called the 'execution' directory and the system 
will look there for any command you use that doesn't 
have a pathlist preceding it.) CHD and CHX are a lot 
like connecting to two single directory drives, one 
for data and one for commands. 

That simplifies things doesn't it? But are you 
thinking what I'm thinking? Chd and chx are also two 
more things to remember! So what happens if you 
forget? You get an error!! If you set "chx /dl/cmds' 
and then call for a command that is on drive you 
will get an 'error 216' - pathname not found. That is 
like an NE error in DECB. But you can't just blame 
things on CHD or CHX, because the system will have to 
look in SOME specific place for what you command. And 
if you ask the wrong thing, you get the wrong thing. 

Note that the error message uses 'pathname', not 
'pathlist'. Consider a pathname a segment (between 
slashes) of a pathlist. Let's look closer at errors. 

Forwarned is indeed forarmed. Usually errors are the 
bane of the 0S9 beginners existance. With so many 
things to remember it is easy to make multiple 
mistakes. And as with other systems the actual error 
number doesn't always tell you what's wrong - even if 
you look up the number. But there is something you 
can keep in mind that will ease your recovery from 
such things with the least frustration and time. 

Knowing it in advance will at least allow you to 
analyze problems in an intelligent way. Remember that 
the file name is called 'pathlist' because it includes 
the path of drives or directories through which the 
file is accessed. Any part of the pathlist can give 
you the error - not just the file name at the end of 
it. Let me describe just one error problem. If the 
command you start a line with is not in the directory 
of executable commands that you indicate, you can get 
a 216 error there. If the drive you name, has the 
wrong disk in it, you can get an error from that part 
of the pathlist. If the directory you name is not on 
the indicated disk, that will give the same error, 216 
- pathname not found. And, of course, if the file you 
want turns out not to be in the indicated directory, 
same thing. 

Of course, misspelling can effect any of these 
things. At least you now know to look in different 
places for trouble. All this really involves a state 
of mind. To get at all that power you have to think 
differently (and more) with 0S9 than you did in DECB. 
It's like moving into a house with 10 times as many 
rooms and 10 times the stuff. At first you'll have 
trouble remembering where you put everything. 

You will find, as you progress, that there are 
alternative ways to do a given task. The third 
section will involve a little less attitude and a 
little more technique. There I will go a little 
deeper into some points I have made so far. Now 
section two. Beyond the System A sort of philosophy 
is also involved when you begin to deal with 0S9 
software. If you used only smoothly functioning, 
shrink wrapped commercial software, you probably 
wouldn't be reading this. You've probably been on 
Delphi to try the OS9 SIG's software or ask for help 
with something that is not so smooth running. There 
are beginners who frequent Delphi. Often they're as 
full of questions as you are, but they have answers. 
At the other end of the spectrum there are some very 
expert and brilliant programmers who know "everything 
there is to know" about 0S9. 

Too often, you will find yourself simply talking a 
different language than these "tech types.' It isn't 
that they don't want to help. They're helping each 
other every day! If you want to know something about 

Page 9 

October 1992 


the exact syntax of an obscure part of a brand new 
update to the latest XYZ language enhancement, you're 
in luck. But if you want to know how to get the menu 
on yesterdays spreadsheet it might take longer. Some 
very bright programmers dash off experimental programs 
for fun. Sometimes they like what they end up with 
and post it on Delphi. 

Maybe they wrote 2 pages of documentations for a 
complicated communications program. Maybe they didn't 
finish it. Maybe they forgot they even wrote it! 
Grabbing the first thing in sight may or may not be a 
good idea. If you're looking to 0S9 to be the cure 
for the common cold, the end all, be all, you need to 
rethink things. It is a tough thing to learn. But 
some of those brilliant programmers I mentioned have 
worked long and hard at getting rid of bugs in the 
original package and adding yet more power to it. 

I guess the irony is that this system sits in such a 
tiny box wishing it had some place to go. Users 
require more and more function. That calls for more 
and bigger software, and that calls for more memory 
and/or data storage space. When that space is 
limited, you cut something. What should get cut? 

A very appealing aspect of 0S9 is the ability to snap 
from one program to another with the push of a button. 
But with space and CPU speed limited, how many 
programs of what size, power and function can you 
squeeze into a little CoCo? Working Delphi is nice. 
You run a terminal program. Maybe you have an editor 
to generate messages which are stored. You download a 
file to disk or ramdisk. Maybe you print out 
documentation in the background. Fun! 

But what are you downloading? A spreadsheet that 
will hold all your small business bookkeeping for a 
year? Will you run that at the same time you have a 
memory gobbling graphics program in place? And the 
graphics user interface you use? And the big game you 
didn't finish last time you played? 

Then, perhaps more importantly, there is the 6809 CPU 
a terrific little chip that could blow the doors off 
everything when it first came out (and later). DECB 
users who've been around a while remember when 
everyone was scrambling to get things running at 
double speed - (still less than 2 mhz). If one 
program can need that, what about several, running at 
once? Some programs take little CPU time. Some take 
a lot more, like when there is much disk I\0. Special 
disk controllers can help a lot, but that is only one 
of the angles. 

How successful multi-tasking will be for you will 
depend on what you'll be running. Don't plan on 

October 1992 

having three action games running on three different 

With applications growing to accomodate users demands 
for computing power, more memory and speed is needed. 
If you're a purist of the 68xx genre, the new 68xxx 
computers may be interesting. They have many times 
more memory and speed than CoCo. You'll find 
programmers right on Delphi who are working day and 
night to develop applications for these computers. 

Take a look at things. If you're a budding 
programmer, learning 0S9 can be very educational. If 
you're a hobbiest you can do a lot of experimenting 
with 0S9 software and utilities. You can even run 
some of those very good applications programs. Or 
power a rock concert via Ultimuse and MIDI! 

A little Body For the Attitude 

So far, I've given you just a peek at how life can be 
in the 0S9 world. Some things I've described may be 
very unlike what you ultimately find to be your 
specific experience. But I have been more interested 
in the general idea of things. Now I'll touch on a 
few points that will probably effect everyday 
computing more. Still, this isn't an 0S9 "how to 1 , 
just a whiff of its perfume. 

Why is it so important to have so many levels of 
directories? Firstly, as I mentioned, there is a lot 
of stuff to organize. With people writing constantly 
there are new "tools' coming out almost every week! 
(I have 16 clocks on file and that isn't all of them.) 
By 'tools" I mean utilities to do jobs, etc. Earlier 
I used "del" in an illustration. That is a very 
simple tool. "List 8 is a fairly simple tool. "Free" 
is like free in DECB. "Mfree" is like 'MEM'. (There 
ARE differences between such similar DECB and 0S9 
commands but the general idea is the same). Improved 
versions of various commands are written, often 
somewhat larger. Most veteran 0S9 users have an 
entirely new shell - SHELL +. 

Other commands are replaced if the user prefers 
something different (and if an alternative is 
available). But you really can't just toss out the 
original commands. There WILL be a time when you need 
at least some of them if you stick with 0S9 long! So 
you keep copies of them. Probably on a separate disk. 
But if you happen to want to use both versions you 
might want them on one disk. You can't do that with 
DECB if you use the same name, but it is easy with 
0S9, because you can put them in different 

You might want to put them on the same level in 

Page 10 


differently named directories. You could have, for 
example, CMDS1 and CMDS2. Then it would be possible 
to have one version of (perhaps) ATTR in one and 
another version in the other - (/dO/cidsl/attr or 
/d0/cids2/attr). How much of this you can do sight 
depend on your own memory. 

Or you light want to put then on different levels. 
You could actually have a CHDS directory listed under 
the regular CHDS directory (/dQ/cmds/cmds/attr), 
although it would probably not be a very good idea. A 
■dir 1 could confuse you if you didn't remember which 
level you were looking at. 

Another reason for various directories is the wide 
variety of data you can (sometimes must) have on disk. 
Frequently you will see directories named SYS, DOC, 
MODULES or ARC. SYS might have data essential to the 
function of an assembler. It might have "help 1 or 
"error" messages. 'DOC 1 would probably have 
documentation for programs or commands. "MODULES 1 
would likely have descriptions of the parameters of 
your various I/O devices such as your printer or RS- 
232 pak (40 isn't unusual). ARC would probably have 
archived (compressed) copies of programs, data, or 
other files. 

As mentioned, directories CAN be "stacked" many 
levels deep. One communications program stores 
dialing information like this: /dO/sys/dial/filename. 
A MultiVue screen icon might be named like this: 
/dO/cmds/icon/ I saw an example in which 
BasicOS commands were on the same disk with others. 
Under the regular CMDS directory was BASIC09, and 
under that was another CMDS. To copy it you could end 
up with this line: 

copy /dQ/Basic09/filename /dl/basic09/filename, 

(Note, above, that I have put directory names in 
capital letters but the command lines in lowercase. 
If you have many things on the same level, caps make a 
directory stand out on the screen. When you set up a 
directory (using MAKDIR) you can just enter the name 
in caps. After that you need not use caps to call it. 
In most cases, 0S9 accepts lowercase keyboard input 
for the system. Programs run under 0S9 make their own 
decision on that). 

If you see the reason for multiple directories, we 
can go on. At some point you will probably come 
across the phrase "Unified I/O System". So far I've 
referred to pathlists only as long paths through the 
maze of directories to files on your disks. But paths 
can access other things. Via pathlists you can list a 
text file to the screen or you can list it to your 
printer or to a screen in another window to be seen 

later! Via a pathlist you can read input from your 
RS-232 pak (and therefore whatever it is connected 
to). You can run a program in a window you don't see. 
These things can happen because of this "unified" 

In section one I mentioned that most commands are 
usually kept on disk. When you need, for example, the 
command "format 1 it will probably be on disk. When 
you enter "format" the computer loads it into memory 
and executes it (but not by firing squad) then unloads 
it when it is done with it. But you can also load 
commands into memory manually, then unload them when 
you wish. 

(Computereze for "unload" is "unlink".) 

In section one I mentioned that mis-spelling 
something in a command line could cause an error such 
as 216 (pathname not found). Something that you can 
do in 0S9 does make life easier when this and other 
things happen - the command line buffer. What you 
enter as a command line is saved in memory. You can 
then repeat it with the appropriate keypresses. As it 
comes, OS9 has an command repeat that is activated by 
CTRL-A. Before you press <ENTER> you can do some 
overstrike type editing. 

With one very popular new version of this you use 
right arrow or shifted right arrow instead of CTRL-A. 
You can easily key over to the offending characters, 
change, insert or delete them and repeat the command. 
This is the "SCF EDITOR" I mentioned at the beginning 
of this article. 

This saves MUCH time over typing in whole lines 
again, especially when dealing with long full 
pathlists. If you're not the best typist, it can be a 
life saver. It also comes in handy if, for example, 
you have several similar files to copy. By changing 
only the actual filename part of the pathlist you 
could move several files without retyping much. 

On the other hand, when in doubt about where you are, 
you can usually enter a full pathlist to "feed the 
hungry computer", (Sometimes, specific programs might 
not allow that). 

There are other things that can really frustrate the 
beginner. One thing is the time it takes to do 
certain tasks according to the manual. For example, 
at some point you will wish to rewrite your startup 
file. Beginners haul out the "build" command and start 
a new startup file from scratch as instructed by the 
manual. One tiny error and you're back to deleting, 
renaming, rewriting or what all, from the top down. 

Page 11 

October 1992 


Startup is actually a text file called a script. 
(This may be in the manual somewhere, but I've never 
found it. It is definitely not in ly indexes). Each 
command is on a separate line. If you can get hold of 
a line editor such as SLED from Delphi, (or a word 
processor) you can load such a script as "startup" and 
add or subtract at will. Just loading one and looking 
at it will take much of the mystery out of it. 

Always press <ENTER> after each command as you would 
on the keyboard. Just as in regular word processing, 
this will start a new line for the next command. 

If you wish to keep a copy of the original startup 
file you can rename it the way the manual suggests - 
before starting on a new one. Then when you are 
finished with the new one you save it to disk as 
'startup' just like the original. If your line editor 
has an overwrite feature (such as the one in SLED) you 
can just write the file into the space where the 
original was. Once you get comfortable with the 
system you will probably do this. 

The 'edit' utility that comes with 0S9 can do this 
job. If you find it easy to use, by all means do so. 
But with a regular text editor you can see it all at 
once and use the arrow keys to edit. 

Since a script is just a series of commands in a text 
file, you can write different scripts to do different 
things and call them just as you would any other 
command. This is a good way to set up a series of 
commands you use repeatedly. If a particular program 
calls for doing several things to prepare for it, you 
can probably do them in a script. You could put your 
preparatory commands in it, save it in the 'crnds" 
directory as "pstart\ for program start, and do the 
job by just entering 'pstart' (assuming your chx was 
set to 'crnds'). 

you that this is just the 'tip of the iceberg." 

The Firing Line 

Since directories and the CHD and CHX commands are at 
the center of a lot of beginners problems here is 
still more to help make things clear. 

When you type in a line like: 

list /dl/modules/bootlist 

the system looks for those names on the disk. It 
looks first for 'list' in the execution directory then 
looks for a descriptor named "d0\ a directory named 
■modules" and a file named "bootlist". It must have 
the numbers that these names represent, and it scours 
one or more disks looking for them in logical ways. 

But when you use CHD and CHX those numbers are stored 
for quick use. If the 'CMOS' directory is, for 
example, on line 1 to drive 1 and on sector 872, the 
CHX command stores that information. It is as if a 
big arrow were pointing to that sector. After that, 
any time the system "sees" a command it jumps to those 
numbers - that sector. That is why it cannot look for 
the "CMDS" directory by name. 

Here are some typical command line problems. 

Say you have put a system disk in drive and issued 
a 'CHX /dO/cmds' command. Then you enter; 

copy /dO/sys/stdptrs /dl/sys/stdptrs 

Things will probably be okay, 
hurry it may be: 

But if you were in a 

cpy /dO/sys/stdptrs /dl/sys/strptrs 

Scripts are really very easy to write. You'll see. 
But all is not rose petals here either. Sometimes, 
even when the script lines appear to be perfect, a 
line will just not work. Swapping lines sometimes 
makes a difference. Script lines do not give error 
messages. Shell+ will automatically get a script from 
the execution directory (set by chx). You can NOT 
load a script into memory like other commands unless 
you upgrade to ShelU v2.0 or higher. 

I have tried to say (perhaps warn), in a simple way, 
how complex 0S9 can be. (Even the explanation has 
become somewhat complex.) I have tried to offer some 
preparation for dealing with that by covering an area 
or two that has been especially problematic for the 
new 0S9 user - the manuals can be very frustrating 
sometimes. Perhaps the best preparation is to tell 

The system cannot find 

'cpy' and you get a 216 error, 

If you put the disk in but forgot the CHX command, a 
perfect command line will probably give you a 215 
error - bad pathname - because the system jumped to 
sector so-and-so and there was no 'CMOS' directory 
there! See?? Right there is where a lot of 
frustration comes in. (Sometimes this may work, 
because if the command is in memory [where the system 
first looks] it will work anyway.) 

'copy /dO/sys/stdptrs /dl/sys.stdptrs' 
isn't a hard mistake to make if you're not a good 
typist. This will cause the system to store a file in 
the directory last indicated by CHD and name it 

October 1992 

Page 12 


'copy /dO/sys/strptrs /dO/sys/stdptrs" 
will probably give you a 218 error - file already 

'copy /dO/sys/stdptrs /dl/sys/stdprts" 
will not give you an immediate error. But when 
something looks for "stdptrs' and there is nothing but 
'strprts' it is 216 time again. 

Believe it or not, if you have set CBX to /dl/cmds, 
for instance, and you decide to use a command (let's 
say Mist') which is in your /dO/cmds directory you 
can enter something like: 

/dO/cmds/list /dO/txt/message. 

Lastly let me touch on redirection again. While 
making up a new bootfile (0S9Boot) 1 had some 
problems. I decided to use the 'ident 1 utility to 
look at what was in the file. With 30 or 40 or more 
modules in 0S9Boot you just can't get the idea on the 
screen. So I redirected the output of the ident. A 
normal ident on a single module might look like this: 

ident /d0/modules/cc3disk.dr 

By redirecting output like this: 

ident /dO/OS9Boot >/p 

I had all of the modules information sets printed out 
in hardcopy instead of the screen. 

You don't have to be typing command lines to get 
errors. Some utilities REQUIRE certain CHD settings, 
and if you just forgot to do one the utility could be 

getting the wrong information or none at all. 

To really bring your system up to date, RICKULAND is 
distributing some very cheap sets of all the things 
you need to make a new system out of what you started 
out with. Contact him on the 0S9 Sig. 

This is really a good idea, because you can spend 
days, weeks or even months acquiring all the patches 
and getting them flawlessly into place. AND you will 
find that some of the very good public domain software 
available does not work well unless the original bugs 
are eliminated from the operating system itself. 

I'm going to mention something Rick suggested, so you 
can 'chew 1 on it. It comes with a sort of catch 22 
built in so be careful how you size it up. 

Although the 0S9Boot file must be in one contiguous 
file, not stored in various parts of the disk, it does 
not need to start at the beginning of the disk. So 
you could put your commands directory on the disk 
first - on all your system disks - and the pointer set 
up by the CHX command would be the same for every 
disk. Therefore you would not have to reset it except 
for times when you used /dl. 

The trick here is that by the time you might feel you 
have the expertise to do this you would probably have 
several system disks set up the other way. Those 
disks would require 'CHXing' as usual and the mix 
might not be worth the effort. 

Jim LaLone 


(upper middle class neophyte) On Delphi: 


Page 13 

October 1992 



Have you come to the same problem I came to lately? 
After updating my Boot file several times with modules 
from the public domain library, I could not tell later 
where these were coming from. When "Ident" gives you 
edition and revision numbers, those might not have 
been changed by the programmer who wrote the new 

version. And what about those you patched with 
■Ipatch 1 ? I found that the only reliable information 
is the CRC number, and if I had a listing of all the 
versions I know of a particular module with their CRC 
numbers, life would be much easier. So, here are a 







OS9 Level II System Disk 
Public Domain Library 111 





OS9 Level II System Disk 
Public Domain Library fll 




0S9 Level II System Disk 
Public Domain Library fll 




OS9 Level II System Disk 
Public Domain Library fll 




Kevin Darling 

OS9 L.II Development System 
0S9 L.II Development System 
0S9 L.II Development System 

Rammer. a r 
rO 96k. dd 
rO 128k. dd 



OS9 L.II Development System 
Kevin Darling 

Rammer. ar 

They will be more for you next time. Happy computing! 

October 1992 

Page 14