AUSTRALIAN OS9 NEWSLETTER
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
handle
TnimTiirT
Gordon Bentzen
Bob Devries
Usage
window
help to
@IDEN^
from OS
single lin
director}
@INKE
input a
the pro<
memory
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:
EDITOR
SUB-EDITOR
TREASURER
LIBRARIAN
SUPPORT
Merge <path>
@MFREE Svnt
@MODPATCH
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
JU.
1^=1.
M^i.
Editorial Material:
Gordon Bentzen
8 Odin Street
SUNNYBANK Qld 4102
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
[yy/m
Syntax:
num
@TMODE
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:
AUSTRALIAN OS 9 NEWSLETTER
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
AUSTRALIAN 0S9 NEWSLETTER
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.
Here
is the source.
'EOCEDUEI
I translate
OOOO
ON EEEOE GOTO 1000
0006
PAEAH file:STEI(iG[100l
0012
DIM token:BYTE
0019
DIM coiiiiaDd;STEIHG[20l
0025
DIM path:ISTEGEE
002C
DIM xiISTEGEE
0033
DIM flag,eriiuji:INTEGEE
003E
DIM lineilfiTEGEE
0045
flag=0
004C
OPES »path,file:EEAD
0058
FOE x^l TO 5
0068
GET Ipath, token
0072
SEXTx
007D
GET #patli, token
0087
line:token*256
0093
GET »path, token
009D
line=linenoken
00A9
PEIHT line; • ■;
00B3
iffllLE fiOTIEOFItpathl) 1
OOBE
GET Jfpath, token
00C8
IF flag:l THEN
00D4
line=tokeii*256
OOEO
GET #path, token
OOEA
line^line+token
00F6
IF line=0 THEN
0102
END
0104
ENDIF
0106
GET tpath, token
0110
Iine=token*256
one
GET »path, token
0126
line=linenoken
0132
PEINT line; ' •;
013C
flag:0
0143
GET Ipath, token
0140
ENDIF
014F
IF tokenOO THEN
015B
flag^O
0162
IF token>127 THEN
016E
tQken=token-127
0179
IF taken:128 THEN
0185
EESTOEE 1020
018A
GET Ipath, token
0194
tQken=token-127
019F
ELSE
01A3
EESTOEE 1010
01A3
ENDIF
OlAA
FOE x^l TO token
0I6B
EEAD coiiand
OICO
SEXTx
OICB
PEINT comand;
OlDl
ELSE
01D5
PEINT CHE$(token|;
OIDC
ENDIF
OlDE
ELSE
01E2
PEINT
01E4
flag:l
OlEB
ENDIF
OlED
EKDWHILE
OlFl
CLOSE Ipath
01F7
END
01F9 1000
ernui^EEE
0202
IF ernuin=56 THEN
020E
PEINT 'usagertranslate (filenaie)'
022C
PEINT • converts ESDos basic tokenized
prograime
to ASCII"
0267
END
0269
ENDIF
026B
PEINT "0S9 error '; ernun; ' has occured!'
028D
END -..-. --
028F 1010 DATA •FOR",«GO',"REH",*",'ELSE','IF',"DATA","PRIfiT',''Or,"INPUT«
02D3 DATA "END", "NEXT', 'DIM', 'READ', 'RUN", "RESTORE", "RETURN", "STOP"
0311 DATA "POKE"/CONT" /LIST", "CLEAR", "NEW", "CLOAD","CSAVE', "OPEN"
034F DATA «CLOSE","LLIST","SET«, "RESET", "CIS", "MOTOR", "SOUND", 'AUDIO"
November 1991
Page 3
AUSTRALIAN 0S9 NEWSLETTER
038F
03CE
03FD
041A
0454
048B
04C9
04E2
04F9
0538
056D
05A0
05BD
05F5
062A
0664
0683
069D 1020
06DC
071A
0735
0753
078E
07BE
07DE
0807
082D
084F
DATA "EXEC" /SKIPFV 'TAB! V 'TO", 'SUB', "THEN- /SOT' /STEP', 'OFF'
DATA ' + '/-'/*•//'/'• /AND'/OE" /)'/="/(•
(* coffiinaiids for ECB follow *)
DATA 'DEL'/EDIT'/TEON'/TROFF'/DEF'/LET'/LrNE'/PCLS'
DATA 'PSET"/PEESET'/SCEEEN'/PCLEAE"/COLOR'/CIRCLE'
DATA 'PAINT' /GET' /PUT" /DRAW /PCOPy/PKODE' /PLAY' /DLOAD"
DATA 'RENUM'/FN'/USr«G'
(^ coEMiids for DECB *)
DATA 'DIR'/DRIVE'/FIELD'/FILES' /KILL' /LOAD" /LSET'/MERGE"
DATA 'RENAME' /ESET' /SAVE' /tfSITE' /VERIFY' /UNLOAD"
DATA 'DSKINI' /BACKUP' /copy /DSKI$"/DSKO$'/DOS"
(* comnds for SECB (CC3) *)
DATA "VIDTH' /PALETTE" , 'ESCREEN" , "LPOKE' , "HCLS' , "HCOLOR"
DATA 'HPAINT' , 'HCIRCLE' , 'HLINE' , 'HGET' , "HPUT" , "HBUFF"
DATA 'HPRINT' , 'ERR' /BRK' , 'LOCATE" , "ESTAT" , 'HSET" , "ERESET"
DATA "EDRAV'/CMP'/EGB'/ATTR'
(* function coiiands CB *)
DATA 'SGN"/INT"/ABS'/USR"/R!iD"/SIN'/PEEK"/LEN'/STR$'
DATA •VAL'/ASC'/CER$"/EOF'/JOYSTK'/LEFT$"/RIGHT$"/MID$"
DATA "POIST'/INmS'/MEH'
(* function conand for ECB *)
DATA "ATH"/COS"/TAN"/EXP"/FIX"/LOG'/POS"/S(!R"/BEX$"
DATA "VARPTR"/I!JSTR"/TIMER'/PP0I(IT'/STEING5'
(* function coimands for DECB *)
DATA 'CVN'/FEEE'/L0C'/L0F'/MO$'/AS'
(* function cosiEands for SECB (CC3) *)
DATA " \(* empty one for CC3 bug M
DATA 'LPEEK" /BUTTON' /HPOIST"/ERNO'/ERLIN"
ooooooooooOOOOOOOOOOoooooooooo
A C Tutorial
Chapter 4 - Assignaent k Logical
Continued..,
coEpares
MORE COMPARES
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
AUSTRALIAN OS 9 NEWSLETTER
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
identical,
ADDITIONAL COMPARE COBCEPTS
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.
LOGICAL EVALUATION
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.
PRECEDENCE OF OPERATORS
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".
THIS IS A TRICK, BE CAREFUL
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.
POTENTIAL PROBLEM AREAS
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,— ^ -
THE CRYPTIC PART OF C
There are three constructs used in C that make no
sense at all when first encountered because they are not
November 1991
Page 5
AUSTRALIAN 0S9 NEWSLETTER
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.
THE CRYPTIC ARITHMETIC OPERATOR
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
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.
TO BE CRYPTIC OR NOT TO BE CRYPTIC
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.
PROGRAMMING EXERCISES
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
number.
1 IJOOOO
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
line.
Page 6
November 1991
AUSTRALIAN OS 9 NEWSLETTER
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
acceptable.
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
anyway.
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
AUSTRALIAN 0S9 NEWSLETTER
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
constraints.
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
default.
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-
versa.
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,
attention.
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
AUSTRALIAN OS 9 NEWSLETTER
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
wish.
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
ooooooooooOOOOOOOOOOoooooooooo
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
user
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
Pascal
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
AUSTRALIAN 0S9 NEWSLETTER
language
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
conditions
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
software
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
Basic09
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
ooooooooooOOOOOOOOOOoooooooooo
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
AUSTRALIAN OS 9 NEWSLETTER
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
typi
accessed. By recognizing SCS, a device need only look at
the bottom 5 lines to determine when it is being
addressed.
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.
(sigh)
TOPS package,..
I did some work on the TOPS package THE VHOLE THING is in
oae compressed tar file oa garfield.catt.ncsu.edu
(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
available?'
'Yes'
'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?'
7es.
•So then why 'oa earth would your first coatact (the ad)
with your new desired user base contain specific wilful
November 1991
Page 11
AUSTRALIAN OS 9 NEWSLETTER
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"?'
"Yes."
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
ooooooooooOOOOOOOOOOooooooooGO
CoCo-Liak
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:
CoCo-Link
31 Hedlands Crescent
Pt. fioarluaga Sth.
South Australia
Phone: (081 3861647
Page 12
November 1991
