Skip to main content

Full text of "Australian National OS9 Newsletter (November 1991)"

See other formats


sides *No. of cylinders' 0^ decimal) interleave value: On decimal) @FREE Syntax: 
Free [devname] Usage : Displays number of free sectors on a device @<jfFX 
Syntax: RUN GFX(<functxargs>) Usage : Graphics interface package for 
BASIC09 to do compatible VDG graphics commands @GFX2 Syntax: RUN 
GFX20path]<funct><args>) Usage : Graphics interface package for BASIC09 to 


Gordon Bentzen 
Bob Devries 



help to 


from OS 

single lin 



input a 

the pro< 


text files 

memory @)MAKDIR Syntax: Makdir <pathname> Usage : Creates 

directory file @MDIR Syntax: Mdir [e] Usage : Displays the present memory 

module directory Opts : e = print extended module directory @MERGE Syntax: 






Merge <path> 
@MFREE Svnt 
memory from c 
compare modul 
to module C o 
module M = mf 
Usage : Set m< 
monochrome rr 
and links an OS 
Procs [e] Usa 
display all pro* 
current data dir 




Editorial Material: 

Gordon Bentzen 
8 Odin Street 

J bra ry Regu^ ts: 
Jean-Pierre Jacquet 
27 Hampton Street 
DU RACK Ql d 40 Z7 

ndard output 
^M memory 
module in 
^rnings -c = 
ame = link 
V = verify 
ntype [opt] 
onitor m = 
e : Oeates 
CS Syntax: 
Opts : e = 
Prints the 
he current 

execution directory path @RENAME Syntax: Rename <filename> <new filenamo 
Usage : Gives the file or directory a new name @>RUNB Syntax: Runb <i-code 





the operating parameters of the terminal (g)TUNEPORT Tuneport </tl or /p> 

[value] Adjust the baud value for the serial port @UNLINK Syntax: Unlink 

<modname> Usage : Unlinks module(s) from memory @>WCREATE Syntax: 

Newsletter of the National 0S9 User Group 
Volume 5 Number 10 

EDITOR : Gordon Bentzen 
SUBEDITOR : Bob Devries 

TREASURER : Don Berrie 
LIBRAEIA8 : Jean-Pierre Jacquet 

SUPPORT : Brisbane 0S9 Level 2 Users Group 

As you can see ve are still producing the newsletter, and 
in fact we have changed the format to give you sore 
infornation for your aoney. With sialLer cargins all 
round, we can fit siore words on each page. Of course, 
this neans we have to think up more to go into it. 

One of the hardest things that we have to do is to try to 
provide articles of interest to our readers. It would be 
extrenely helpful to us, if you could provide us with 
soae ideas as to the type of article that YOU would like 
to read. To do this, sinply drop us a line, and we will 
take it froi there. 

file. This will save having 
convert the file to ASCII, 

to go back to RSDos and 

Ve also have tore text froa the BitNet systei with 
discussions about 'Windows' on OSK iiachines. It seeiis 
that there are quite a lot of different ideas about how 
that should be iiplimented. 

For those who have a lot of back-issues of 'The Rainbow', 
we have continued the listing of the index of all the 0S9 
articles which appeared, along with their authors, and 
page numbers. 

We would, for exasiple, like to publish articles which 
include source code, but iiany of the public donain 
subiissions that we receive, or that we get froE overseas 
sources, only contain executable code. This aliost 
always precludes the use of those submissions as material 
for the Newsletter. We figure that it is better to 
distribute that material on disks via our Public Donain 
library system. 

This month we feature a Basic09 programme by Bob Devries 
which will read an ESDos 'tokenised' file (i.e. one saved 
normally, not in ASCII), and print it to standard out in 
ascii. This means, that if you want to convert such a 
programme to Basic05, all you need do is read it from 
your RSDos disk (using the programme ESDos) and run it 
through this programme, with its output re-directed to a 

Ve have some news items from American 0S9 users, and what 
they have to put up with over there, It makes some very 
interesting reading. 

Well as you can guess I am back from Europe and the 
holiday is over. I must say that it is good to be back 
home again to things familar. I will never complain 
again about the cost of living in Australia again but the 

experience in U.K. and Europe is one not to missed. 

Ve do hope that you find something of interest in this 
edition and remind you all that we will be happy to 
include any articles which you may wish to share with 
other members. 

Regards, Gordon 

Page 2 

November 1991 


Read ESDos BASIC tokenised files 
bv Bob Devries 

Here is a programie which vill read a^RSDos BASIC 
tokenised file and print it out as ASCII text. You itust 
of course have some vay of moving the file from a ESDos 
disk to 0S9, but there is already a utility to do this 
called 'ESDos'. It is in our PD library. 

This progranne expects the filename on the coamand 
line, and prints the ASCII to STDOUT, so you can redirect 
it to a file, or the printer. If you don't give it a 
name, it prints a usage message. This is donr by setting 
up an ON ERROR GOTO lin€ first up, and then using the 
PARAM line, which reads in the variables from the coEiand 
line. If none exist, an error 56 would occur, but as it 
is trapped, the programme quits cleanly. 

After opening the file, the programne junps over the 
first five bytes, and reads the next two to get the first 
line number. It then enters a loop to keep reading 
characters until a zero value is read, which is the end 
of line character, and prints a carriage return, After 
skipping two bytes (the address pointer to the next 
line), it reads two bytes for the next line number. This 
goes on until three zero bytes are read in a row, which 
means the end of the programme has been reached. The 
file is then closed and the programme ends. 


is the source. 


I translate 




PAEAH file:STEI(iG[100l 


DIM token:BYTE 


DIM coiiiiaDd;STEIHG[20l 






DIM flag,eriiuji:INTEGEE 


DIM lineilfiTEGEE 




OPES »path,file:EEAD 


FOE x^l TO 5 


GET Ipath, token 




GET #patli, token 




GET »path, token 




PEIHT line; • ■; 


iffllLE fiOTIEOFItpathl) 1 


GET Jfpath, token 


IF flag:l THEN 




GET #path, token 




IF line=0 THEN 






GET tpath, token 




GET »path, token 




PEINT line; ' •; 




GET Ipath, token 




IF tokenOO THEN 




IF token>127 THEN 




IF taken:128 THEN 




GET Ipath, token 










FOE x^l TO token 


EEAD coiiand 




PEINT comand; 




PEINT CHE$(token|; 














CLOSE Ipath 



01F9 1000 



IF ernuin=56 THEN 


PEINT 'usagertranslate (filenaie)' 


PEINT • converts ESDos basic tokenized 


to ASCII" 






PEINT "0S9 error '; ernun; ' has occured!' 


END -..-. -- 

028F 1010 DATA •FOR",«GO',"REH",*",'ELSE','IF',"DATA","PRIfiT',''Or,"INPUT« 




November 1991 

Page 3 



















069D 1020 












DATA ' + '/-'/*•//'/'• /AND'/OE" /)'/="/(• 

(* coffiinaiids for ECB follow *) 





(^ coEMiids for DECB *) 




(* comnds for SECB (CC3) *) 





(* function coiiands CB *) 




(* function conand for ECB *) 



(* function coimands for DECB *) 


(* function cosiEands for SECB (CC3) *) 

DATA " \(* empty one for CC3 bug M 



A C Tutorial 
Chapter 4 - Assignaent k Logical 



The conpares in the second group are a bit more 
involved. Starting with the first coiipare, we find a 
rather strange looking set of conditions in the 
parentheses. To understand this we Bust understand just 
what a 'true" or "false" is in the C language. A "false" 
is defined as a value of zero, and "true' is defined as a 
non-zero value, Any integer or char type of variable can 
be used for the result of a true/false test, or the 
result can be an implied integer or char. Look at the 
first coipare of the second group of conpare statements. 
The expression 'r != s" will evaluate as a "true" since 
'r" was set to 0,0 above, so the result will be a non- 
zero value, probably 1, Even though the two variables 
that are compared are 'float' variables, the result will 
be of type 'integer'. There is no explicit variable to 
which it will be assigned so the result of the compare is 
an implied integer. Finally the resulting number, 1 in 
this case, is assigned to the integer variable "x". 

If double equal signs were used, the phantom value, 
namely 1, would be compared to the value of 'x", but 

since the single equal sign is used, the value 1 is 
simply assigned to 'x', as though the statement were not 
in parentheses, Finally, since the result of the 
assignment in the parentheses was non-zero, the entire 
expression is evaluated as 'true", and 'z' is assigned 
the value of 1000. Thus we accomplished two things in 
this statement, we assigned "x' a new value, probably 1, 
and we assigned 'z" the value of 1000. Ve covered a lot 
in this statement so you may wish to review it before 
going on, The important things to remember are the 
values that define 'true' and 'false', and the fact that 
several things can be assigned in a conditional 
statement. The value assigned to 'x' was probably a 1 
but different compilers may assign a different value as 
long as it is non-zero. 

The next example should help clear up some of the 
above in your mind. In this example/, "x"" is assigned the 
value of "y", and since the result is 11, the condition 
is non-zero, which is true, and the variable "z" is 
therefore assigned 222. The third example, in the second 
group, compares "x" to zero. If the result is true, 
meaning that if "x" is not zero, then 'z' is assigned the 

Page 4 

November 1991 


value of 333, which it will be. The last example in this 
group illustrates the same concept, since the result will 
be true if "x" is non-zero. The compare to zero is not 
actually needed and the result of the compare is true. 
The third and fourth examples of this group are therefore 


The third group of compares will introduce some 
additional concepts, namely the logical "A8D' and the 
logical 'OR'. Be assign the value of 77 to the three 
integer variables simply to get started again with some 
defined values. The first compare of the third group 
contains the new control "SS", which is the logical 
'AND', The entire statement reads, if 'x' equals "y' AND 
if 'x' equals 77 then the result is 'true". Since this 
is true, the variable z is set equal to 33, The next 
compare in this group introduces the ' " operator which 
is the 'OS', The statement reads, if "x" is greater than 
"y' OR if 'z' is greater than 12 then the result is true. 
Since "z" is greater than 12, it doesn't matter if 'x' is 
greater than 'y' or not, because only one of the two 
conditions must be true for the result to be true. The 
result is true, so therefore 'z' will be assigned the 
value of 22. 


iihen a compound expression is evaluated, the 
evaluation proceeds fron left to right and as soon as the 
result of the outcome is assured, evaluation stops. 
Namely, in the case of an "AND" evaluation, when one of 
the terms evaluates to "false", evaluation is 
discontinued because additional true terms cannot make 
the result ever become "true". In the case of an "OR" 
evaluation, if any of the terms is found to be "true", 
evaluation stops because it will be impossible for 
additional terms to cause the result to be "false'. In 
the case of additionally nested terms, the above rules 
will be applied to each of the nested levels. 


The question will come up concerning the precedence 
of operators, Which operators are evaluated first and 
which last? There are many rules about this topic, which 
your compiler will define completely, but I would suggest 
that you don't worry about it at this point. Instead, 
use lots of parentheses to group variables, constants, 
and operators in a way meaningful to you. Parentheses 
always have the highest priority and will remove any 
question of which operations will be done first in any 
particular statements. Going on to the next example in 
group three, we find three simple variables used in the 
conditional part of the compare. Since all three are 
non-zero, all three are "true", and therefore the "AND* 

of the three variables are true, leading to the result 
being "true", and "z' being assigned the value of 11. 
Note that since the variables, "r", "s", and "t" are 
"float' type variables, they could not be used this way, 
but they could each be compared to zero and the same type 
of expression could be used. 

Continuing on to the fourth example of the third 
group we find three assignment statements in the compare 
part of the "if" statement. If you understood the above 
discussion, you should have no difficulty understanding 
that the three variables are assigned their respective 
new values, and the result of all three are non-zero, 
leading to a resulting value of 'TRUE". 


The last example of the third group contains a bit of 
a trick, but since we have covered it above, it is 
nothing new to you. Notice that the first - part of the 
compare evaluates to 'FALSE". The remaining parts of the 
compare are not evaluated, because it is an "AND" and it 
will definitely be resolved as a 'FALSE' because the 
first term is false. If the program was dependent on the 
value of 'y' being set to 3 in the next part of the 
compare, it will fail because evaluation will cease 
following the 'FALSE' found in the first term. Likewise, 
"z" will not be set to 4, and the variable 'r' will not 
be changed. 


The last group of compares illustrate three 
possibilities for getting into a bit of trouble. All 
three have the common result that *z" will not get set to 
the desired value, but for different reasons. In the 
case of the first one, the compare evaluates as 'true', 
but the semicolon following the second parentheses 
terminates the 'if clause, and the assignment statement 
involving 'z" is always executed as the next statement. 
The "if therefore has no effect because of the misplaced 
semicolon. The second statement is much more 
straightforward because "x" will always be equal to 
itself, therefore the inequality will never be true, and 
the entire statement will never do a thing, but is wasted 
effort. The last statement will always assign to 'x" 
and the compare will therefore always be 'false', never 
executing the conditional part of the 'if statement. 
The conditional statement is extremely important and must 
be thoroughly understood to write efficient C programs, 
If any part of this discussion is unclear in your mind, 
restudy it until you are confident that you understand it 
thoroughly before proceeding- anward,— ^ - 


There are three constructs used in C that make no 
sense at all when first encountered because they are not 

November 1991 

Page 5 


intuitive, but they greatly increase the efficiency of 
the conpiled code and are used extensively by experienced 
C programmers. You should therefore be exposed to them 
and learn to use them because they will appear in most, 
if not all, of the programs you see in the publications. 
Load and examine the file named CRYPTICC for examples of 
the three new constructs, .. In this program, some 
variables are defined and initialized in the same 
statements for use belov. The first executable statement 
simply adds 1 to the value of 'x', and should come as no 
surprise to you. The next tvo statements also add one to 
the value of 'x', but it is not intuitive that this is 
what happens. It is simply by definition that this is 
true. Therefore, by definition of the C language, a 
double plus sign either before or after a variable 
increments that variable by I. 

Additionally, if the plus signs are before the 
variable, the variable is incremented before it is used, 
and if the plus signs are after the variable, the 
variable is used, then incremented. In the next 
statement, the value of "y' is assigned to the variable 
"z*, then 'y" is incremented because the plus signs are 
after the variable "y". In the last statement of the 
incrementing group of example statements, the value of 
"y' is incremented then its value is assigned to the 
variable 'z'. The next group of statements illustrate 
decrementing a variable by one. The definition works 
exactly the same way for decrementing as it does for 
incrementing. If the minus signs are before the 
variable, the variable is decremented, then used, and if 
the minus signs are after the variable, the variable is 
used, then decremented. 


Another useful but cryptic operator is the arithmetic 
operator. This operator is used to modify any variable 
by some constant value. The first statement of the 
"arithmetic operator' group of statements simply adds 12 
to the value of the variable 'a*. The second statement 
does the same, but once again, it is not intuitive that 
they are the same. Any of the four basic functions of 
arithmetic, '+', '-', '*', or '/', can be handled in this 
way, by putting the function desired in front of the 
equal sign and eliminating the second reference to the 
variable name. It should be noted that the expression on 
the right side of the arithmetic operator can be any 
valid expression, the examples are kept simple for your 
introduction to this new operator. Just like the 
incrementing and decrementing operators, the arithmetic 
operator is used extensively by experienced C programmers 
and it would pay you well to understand it. 


The conditional expression is just as cryptic as the 
last two, but once again it can be very useful so it 

would pay you to understand it. It consists of three 
expressions within parentheses separated by a question 
mark and a colon. The expression prior to the question 
mark is evaluated to determine if it is "true" or 
"false". If it is true, the expression between the 
question mark and the colon is evaluated, and if it is 
not true, the expression following the colon is 
evaluated. The result of the evaluation is used for the 
assignment. The final result is identical to that of an 
"if" statement with an "else" clause. This is 
illustrated by the second example in this group. The 
conditional expression has the added advantage of more 
compact code that will compile to fewer machine 
instructions in the final program. The final two lines 
of this example program are given to illustrate a very 
compact way to assign the greater of two variables "a" or 
'b' to "c", and to assign the lessor of the same two 
variables to "c". Notice how efficient the code is in 
these two examples. 


Several students of C have stated that they didn't 
like these three cryptic constructs and that they would 
simply never use them. This would be fine if they never 
have to read anybody else's program, or use any other 
programs within their own. I have found many functions 
that I wished to use within a program but needed a small 
modification to use it, requiring me to understand 
another person's code. It would therefore be to your 
advantage to learn these new constructs, and use them. 
They will be used in the remainder of this tutorial, so 
you will be constantly exposed to them. This has been a 
long chapter but it contained important material to get 
you started in using C. In the next chapter, we will go 
on to the building blocks of C, the functions. At that 
point, you will have enough of the basic materials to 
allow you to begin writing meaningful programs. 


1. Vrite a program that will count from I to 12 and 
print the count, and its square, for each count, 

1 I 

2 t 

3 9 etc. 

2. Write a program that counts from 1 to 12 and prints 
the count and its inversion to 5 decimal places for 
each count. This will require a floating point 


2 .50000 

3 .33333 

4 .25000 etc. 

3. Write a program that will count from I to 100 and 
print only those values between 32 and 39, one to a 

Page 6 

November 1991 


OSR Wiadows 

(sonewhat lengthy) 
of discussioas about 
(and existing) OSK 
a knowlege of soiie 
taken place on the 

Til Kient^le, a regular writer from the CoCo Hailing 

List, has posted the following 

message, as a precis of a number 

windowing systems for the new 

machines. Unfortunately, it. assumes 

of the prior discussions that have 

List. It is still worthwhile reading, however, as it 

raises some interesting possibilities about uses of more 

sophisticated windowing systems - Ed. 

Vheeee! Boy this discussion took off. Ed Gow's basic 
point seems to be to Keep It Simple, which is something I 
agree with. It does seem that there are different ideas 
of "simple* around here, though, (grin) I feel like I've 
pretty well outlined my ideas, so Til try to keep my 
responses here as simple as possible... (though I'll 
doubtless fail <sigh>). I've edited this to keep it 
short (!), so I apologize if things are unclear. 

responsible for re-drawing text windows in order to keep 
simple programs simple.) 

Greg Law points out that: 

Obviously you don't always need the max 
resolution with max colors. 

Veil put. Hopefully, if the window manager knows what 
the applications really _need_, it can do clever things 
like creating a monochrome screen if there's not enough 
video memory for something fancier. 

Mike Rnudsen comments about Eddie's DVSet idea: 

Good idea -- a small set of MM/I window 
types that can be met on other platforms 
as well. And right, don't change em! 

Ed has concerns about my comment 
regarding applications re-opening at the 
same position they were last at. 

Frank Hogg's idea of having applications keep 
configuration files in the user's hone directory was 
essentially what I had in mind. The biggest reason I 
mentioned this was to make a case for allowing the 
application to specify where it's window belongs on the 
screen, as opposed to Eddie Kunz's idea that the user 
should do that. 

Ed asks about another detail: 

This raises the window/screen thing 
again. ' What if the window change 
requires a screen change?? Vhat of the 
other windows on the screen?? 

One idea is simply to ignore requests that might require 
a screen change. Thus, an application could make sure it 
got a window on the current screen by asking for a Ixl 
window with 1 color, then create the window, then ask for 
more. The application always has the option of closing 
the window and creating a new one if a new screen is 

Another idea is that if the change would force a screen 
change, you change the screen, then ask the other windows 
to re-draw. (Note: Any system that allows overlapping 
windows has to address the question of how to handle 
exposures. It seems to me that the burden of re-drawing 
exposed graphics windows must rest on the application. 
Bit-mapped backing store just takes too much memory. 

This is a reasonable idea, except that the 'met on other 
platforms' requires some conservatism. For example, the 
VSC supports a 720-across screen, but that's an uncommon 
width, so your 'standard* type codes would have to stop 
at 640-across. |0r maybe smaller?) 

Ed Gow: 

Most programs can run in all screen 
types. The heavy-duty graphics progs 
will probably want their own screen 

I agree, but with a minor clarification. Most heavy-duty 
graphics programs will want a large window, not 
necessarily their own screen, as Hike already pointed 
out. Some heavy-duty graphics progs will desperately 
want to limit their market <grin> by directly messing 
with video memory, THOSE programs must be given their 
own screen, so they won't damage anyone else's window, ;- 

(A good example might be an X windows server...???) 

Ed Gow asks for some clarification: 

There is substantial state maintained 
between DWant() calls, who has it? 

The window manager creates a window description when the 
path is opened, and alters it as requested by the 
program. Once the window is actually created/displayed 
("mapped' in X parlance), then some of those parameters 
may become unalterable. 

Though I also feel that the window manager should be Ed Gow points out a simplification I've been making: 

November 1991 

Page 7 


It looks as though the window calls are 
making screens in the description above, 
but they lack suficient infomatioa to 
really specify a screen type (border/no 
border, interlace, etc.). 

be simplified because of the limited 
number of choices of screens, as opposed 
to the unlimited types of windows. Then 
the window can be made given the screen 

First, those Dtftfaat/DifSeed calls aren't creating screens 
or windows, but just specifying attributes that the 
window should have when it is created. Attributes for 
which the application doesn't express a preference will 

I've omitted some window properties that some programs 
will want to specify. By having each call specify a path 
number, a code specifying the parameter, and the 
parameter value, we gain the flexibility of being able to 
easily add more codes and hence more window options at a 
later date. Chaagable parameters might include: x- 
resohtion in pixels, y-res in pixels, x-res/y-res in 
chars, name/style/size of font, type of window border, 
number of colors, title of window, mouse pointer when in 
window, background color of window, etc. 

Also, one note: I don't think interlace is something that 
the application should ever know about, much less be able 
to request. I think that the user _should_ be able to 
configure the window manager to prefer interlaced or non- 
interlaced screens. I don't want some application 
constantly selecting an interlaced screen when I would 
rather have it select a non-interlaced one. Or vice- 

Mike Knudsen is concerned that 

I don't see this as a simplification. It seems simpler 
to me for the program author to simply think in terms of 
what that program needs in terms of resolution, colors, 
etc, and just ask for that. Pushing screen selection 
onto the application just seems redundant. ?hy should 
every application have to ask the window manager what 
kinds of screens are available and then have to search 
that list to figure out which type it prefers, when code 
to compare an application's requirements to a list of 
possible screen types could be written once and hidden 
away in the window manager? 

I do see one case where the application would need to 
specify a screen, and that is in the rare case where the 
application _needs_ a quick response from the user, where 
it might ask that a window be created on the currently 

visible screen, 


in order to get the user's immediate 

I can certainly see a case for screen creation being 
explicit. Unfortunately, I don't see a convenient way to 
do this that wouldn't make either the application or the 
window manager more complex. 

Suggestions, as always, are welcome. 

Ed Gow asks 

All this platform independence is 
slowing down Kevin Darling's development 
and even causing useful features to be 
omitted or implemented in complex, 
inefficient ways. 

For the most part", the CoCo windowing design is already 
pretty hardware independent. There are only a few real 
limitations in it, such as the method of specifying 
palettes, and the method of specifying a window or screen 
type, and some less-important restrictions on networking 
and use of remote terminals (mouse and get/put buffer 
mapping). Extensions such as overlapping windows, etc, 
only have minor impact on the overall design. As someone 
mentioned, a little work in getting the basic interface 
right could make a big difference later on. There really 
are only a couple of issues. 

Ed Gow comments that: 

I think that screen creation should be 
explicit. There can be some 
negotiation, but I think that it would 

Let tflNDOtf creation apply only to the 
current screen or a screen explicitly 
created by the application for the 
window. Host programs can run in all 
screen types. 

True, and if the window being requested will fit, it 
seems clear to me that the current screen is the obvious 
place to put that window. But what if it doesn't fit? 
tfhat you seem to be suggesting is that either the user 
must explicitly create a new screen, then select that 
screen, then somehow tell the application to open it's 
window there; or the application should ask the user for 
permission to create a new screen and do this (which 
seems to suggest that the application must be able to 
specify what screen to put a window on). ' As a user, the 
first one doesn't sound very simple. As a programmer, 
the second adds the burden of having to worry about 
screens and windows, rather than just windows. Perhaps 
you hav.e some proposed interface that would make it 
easier than it looks right now? Or maybe I'm missing 
something obvious? Bmmmm.... 

Page 8 

November 1991 


In order to help explain my proposal and viewpoint 
better, here's some random thoughts: 

I should briefly describe here ay personal 'vision" of a 
nice windowing environient. Soie of this comes from 
ideas which were actually implemented (?) in some version 
of the 0S9 L2 upgrade, so I'm certain that Kevin can 
implement much" of this in some future version of 
DWindows. Hy "vision* involves having separate screens, 
selectable via function keys or mouse. Each screen can 
have multiple overlapping windows, I've heard that this 
is actually available in at least one X window manager 
already (tvtwm?). 

For myself, I see using this to organize things by task, 
A screen where I've been working on an article might have 
a word processor with a separate preview window and an 
on-line dictionary- Another screen where I'm working on 
a program would have a couple of editor windows, a 
compiler, and a debugger window. A third screen is where 
I'm logged into Delphi, with a terminal program, an 
editor where I'm composing replies to forum messages, and 
a shell window where I'm trying to play with answers to 
someone's question. All the screens might have clocks on 
them, or maybe one clock program with a window on each 
screen? You get the idea. The question is how can the 
user |me ;-) easily access these capabilities? 

The idea I've been working with is that rather than 
setting this up by explicitly creating screens or 
designating certain screens, I would simply run the 

program I want, which would appear on the current screen 
unless it required something unavailable there (like too 
many colors). If I wanted it on a different screen, I 
drag it to another screen. One of the screens in the 
"drag cycle" would always be a blank screen (assuming 
available memory) so I can set up things however I wish. 
If I'm starting up a graphics editor which requires more 
palettes than the current screen has, then I find myself 
looking at that graphics editor on a new screen. Vhich 
gives me the option of either dragging other windows onto 
this screen, or flipping back and forth. As long as 
basic window manipulations are fast and easy, then the 
user has convenient flexibility to arrange things as they 

Everyone seems to agree that a mechanism to create a new 
window should specify the resolution, colors, and other 
attributes that window should have. My idea essentially 
boils down to a method for the application to specify the 
things it cares about and let the window manager choose 
"reasonable* defaults for the rest. Most applications 
would only specify the dimensions of the window and the 
number of colors and ignore the rest. If the idea of 
letting the window manager select a screen and screen 
type based on this information seems unwieldy (I'll admit 
it does have some drawbacks), and you think the 
application should be able to control/influence the 
creation of new screens, please tell me (and Kevin, I 
suppose) how to do it. ;-) 

- Tim Kientzle 


An index of Rainbow 0S9 articles 

compiled by Bob Devries 

August '85 - December 1986 

August 1985 page 236 

KISSable 0S9 - Cliffhangers in the micro soaps 

Dale L. Puckett - 

nSSable 0S9 - Confessions of an enlightened spreadsheet 


Dale L. Puckett 

August 1985 page 246 

MAIL09 - The remainder of HAIL09's listings 

Timothy A. Harris 

November 1985 page 241 
Learning 0S9 - The utility room 
Brian A. Lantz 

September 1985 page 238 

KISSable 0S9 - A getting-your-feet-wet course in 0S9 


Dale L. Puckett 

October 1985 page 242 

KISSable 0S9 - 0S9 gets good reception at National 

Computer Conference 

Dale L. Puckett 

November 1985 page 218 

December 1985 page 272 

KISSable 0S9 - A time for reflection 

Dale L. Puckett 

December 1985 page 258 

The Utility Room - Adding more features to the LIST 

command, part 2 

Brian A. Lantz 

January 1986 'page 134 

Getting Started with 0S9 - Boot up with a high level 

November 1991 

Page 9 


Bruce tfarner 

KISSable 0S9 - The Disk BASIC/0S9 coQQectioE 
Dale L. Puckett 

January 1986 page 236 

KISSable 0S9 - Four easy assembly language experiments 

Dale L. Puckett 

July 1986 page 212 

Accessible Applications - CoCo Wordprocessing 

Richard White 

February 1986 page 231 

Accessible Applications - Getting started with Basic09 

Richard White 

July 1986 page 224 

KISSable 0S9 - Choices: The reason for modularity 

Dale L, Puckett 

February 1986 page 236 

KISSable 0S9 - Granting requests for simple device 

drivers and descriptors 

Dale L. Puckett 

February 1986 page 224 

0S9 Tutorial - Creating 0S9 systesi disks 

Donald D. Dollberg 

March 1986 page 226 

Accessible Applications - Firing up Basic09 

Richard White 

March 1986 page 216 
The Utility Room 
Brian A. Lantz 

Errors, error messages and error 

April 1986 page 238 

KISSable 0S9 - Featuring a trig library in C 

Dale L. Puckett 

May 1986 page 219 

Accessible Applications - DeskKate: Good integrated 


Richard White 

May 1986 page 235 

KISSable 0S9 - Featuring a new text formatter 

Dale L. Puckett - 

June 1986 page 208 

August 1986 page 197 

KISSable 0S9 - Experimenting with SAM disks 

Dale L. Puckett 

September 1986 page 200 

KISSable 0S9 - Hard disk makes CoCo 0S9 fun 

Dale L. Puckett 

October 1986 page 196 

KISSable 0S9 - Revving up for fall fun 

Dale L. Puckett 

November 1986 page 188 

Bits and Bytes of BASIC - Basic09 on the CoCo 3 

Richard White 

November 1986 page 199 

KISSable 0S9 - Blue sky for 0S9 Level II 

Dale L. Puckett 

December 1986 page 195 

Bits and Bytes of BASIC - Ddealing with variables in 


Richard White 

December 1986 page 198 

KISSable 0S9 - A bundle of holiday goodies 

Dale L. Puckett 

December 1986 page 183 

0S9 Spooler - Print a file as a background task 

Stephen B. Goldberg 


HEWS Items 

The following are some examples of prices which are 
available to our USA collegues. It makes your mouth 
water, and your mind wonder as to whom is making what 
profits here in Australia. If you don't believe me, 
check for prices of similar items locally. Prices are in 
US dollars. 

lMx9 SIMMS (80ns| $49.77 

BRAHD NEW Sony 3.5' floppy drives 

720K, WITH a 5,25" Mounting Kit, $29-^ach!!! 

(525 each in quantities of 10 or more) 

1.44M, $49 each!!! 

($39 each in quantities of 10 or more) 

5.25" Mounting Kit, $3 additional) 

4Mx9 80ns SIMMS, $199.95!!! 

Page 10 

November 1991 


Break out those checkbooks! 

Toshiba 3.5' Floppy Drive Problem 

Well, last Eite I finally fouad the fix for the oagoiag 
saga of the Toshiba 3.5* floppy that insisted oa beiag 
/DI Qo natter what, Oa very close examiaatioa (glasses 
off, drive touchiag my aose) a surface-mouat chip 
capacitor uader the head-step Eotor showed printed 'T 
aad '0' oa opposite sides. Close probing with a 
jeweler's screwdriver revealed this 'capacitor" to be a 
micro slide switch with aa iavisible handle - tryiag to 
slide it towards the '0' side caused a satisfyiag click. 

Also satisfied the drive, which is aow quite happy as /DO 
aad can format hi-density clear out to all 80 tracks. If 
someone had just told me this 3 nites ago! 

Full Address Decoding Explained (???) 

Peripherals for the CoCo are all memory-mapped, meaning 
that they appear at some memory address (as opposed to 
Z80 or 8086, which has a separate set of TO' addresses). 
There are basically two ways for a hardware device to 
recognize when it's address is being accessed: 

1) 'full address decoding" means that it looks at all 16 
address lines on the expansion port to determine when it 
is being addressed. 

21 There is an extra line on the expansion port called 
SCS (Spare Cartridge Select) which is only active 
ically) when addresses SFF40-5FF5F are being 


accessed. By recognizing SCS, a device need only look at 
the bottom 5 lines to determine when it is being 

The advantage of I over 2 is that when using a MultiPak, 
SCS is oaly active for one slot, which creates problems 
if you have multiple devices, since SCS must be 
•manually' switched from slot to slot. 

A related issue concerns 'ghosting', where a device does 
not look at all the aecessary address lines, and so 
responds to more than oae address. The origiaal Taady 
disk controller, for instance, only 'needs' 4 addresses, 
but can actually be accessed at 32 different addresses. 

TOPS package,.. 

I did some work on the TOPS package THE VHOLE THING is in 
oae compressed tar file oa 
(iacomiag directory). It is 7.6 HEG in size and 
uncompresses to 15 meg. (The sum total from smilodon was 
7.9 meg aad would aot compress.) 

Quote of The Month 

Lawsuits, like assault rifles and nuke weapons, are great 
when you're going down and want to take a few of the 
bastards with you. If you want to go on living and 
working, they're a last resort. 

How's this for 'Vaporware' 

The very minute I saw the first ad for Solaris at 
Infoworld, I grabbed the phone and asked them if they in 
fact did have a shipping product, as their ad plainly 
proclaims, (Something like, 'Others talk about getting 
there, we're there now.') 

'Sir that product is not available yet." 

'Your ad says it is.' 

'I know that.' 

'Are you telling, me that SUN SOFT is advertising a 
product with the words 'here now', but it isn't 


'That's deceitful.' 

'Well, sir, really it isn't. The product will be 
available in July of 92," 

'Your ad plainly says it is here now.' 

•I know that.' 

'Are you taking steps to pull the ad, since it is aa 
obvious sham?' 

'We doa't see it that way sir." 

'Exactly how , would you describe an ad that contains an 
explicit lie?' 

•Sir I'd prefer not to answer that. Would you like me to 
send you literature?' 

'It seems clear that your ad campaign is trying to 
capitalize on the current confusion in the PC universe 
with respect to the fluzy tunes beiag suag by the various 
OS veadors. Is that in fact so?' 


•So then why 'oa earth would your first coatact (the ad) 
with your new desired user base contain specific wilful 

November 1991 

Page 11 


falsehood? How on earth do you expect to win customers 
if the first thing you say to thea is a lie?" 

'Sir the product will be available in about 11 months.' 

"And you call that 'Here Now"?' 


MM/1 Developers tfanted 

All 0S-9/0SK Prograffiiers: 

IMS is looking to expand the base of IDEA developers. 
IDEA stands for IMS Developers Association. IDEA offers 
several benefits for those that want to become registered 
developers vith IMS, including the assistance of the lost 
experience 0S-9/0SK people in the country to aid you in 
your programiing projects. In addition, IMS offers to 
buy up to $500 vorth of your product once it is finished, 
That is, of course, if it is vorth buying (grin). 

IMS also offers free advertising to IDEA developers. If 
developers send a flyer to IMS, it will be included in 
all IMS mailings and in the boxes when MM/ls are shipped. 
Since the software product usually sells the hardware, 
IMS is very interested in getting high quality software 
to show off at demos and shows. Your potential for sales 
will be greatly increased. 

What does one need to do to become an IDEA developer? 
Just send E-iail to me, or a letter to my address below. 
Include in your message what projects you have dreamed 
up, what you are currently working on, and what you would 
like to work on. You don't have to have an established 
reputation for excellent programming, nor do you even 
need to be an experienced hacker. All you need is a 
desire to develop applications for the future of OSK, "C" 
programmers, BASIC09 (Microware BASIC), PASCAL, 
Assembler... ..any language will do, 

We are looking to have a wide software base by the time 
the Chicago Fest rolls around in April so please be 
prompt in your reply. I am the IMS IDEA coordinator 
(slave driver is more like it) and will help in any way I 
can. Please remember that quite a few people have 
expressed an interest in porting UHIX utilities. These 
all already exist so if this is you intent, please try 
and think up something else. What we are looking for are 
new and innovative applications that make use of the 
MM/ls graphics and sound potential. Clones of existing 
IBM or MAC applications are OK, as long as a new "twist" 
can be put in to make it unique to the MH/1. 

Thanks for your attention. 

Mark Griffith 


CoCo-Link is an excellent magazine to help you with the ESDOS side of the Colour Computer. It is a bi-monthly magazine 
published by Mr. Robbie Dalzell. Send your subscriptions to: 


31 Hedlands Crescent 

Pt. fioarluaga Sth. 

South Australia 

Phone: (081 3861647 

Page 12 

November 1991