Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wivax.UUCP
Path: utzoo!linus!wivax!dyer
From: dyer@wivax.UUCP (Stephen Dyer)
Newsgroups: net.micro.6809
Subject: Re: CoCo Food for Thought
Message-ID: <19644@wivax.UUCP>
Date: Thu, 21-Jun-84 21:46:56 EDT
Article-I.D.: wivax.19644
Posted: Thu Jun 21 21:46:56 1984
Date-Received: Fri, 22-Jun-84 01:13:06 EDT
References: <312@hlhop.UUCP>
Organization: Wang Institute, Tyngsboro, Ma.  01879
Lines: 87

    I ran the OS-9 drive test and found that the rpm's on the RS were
    about 300.1; the shugart was around 297.5  Disks written on one can
    be read by the other, so I don't see any problem, right now.  But is
    this a problem for the future?  Might I have trouble reading other
    people's disks?  Is 1% rpm difference acceptable?

I believe that 297.5 is perfectly acceptable.  However, when I purchased
an after-market disk drive and found it slighly slow, much as yours is,
I took it back to the place I bought it and they adjusted the speed so that
it was on the nose.  Most every drive has such an adjustment, though I
wouldn't trust the job to myself.

    With OS-9, I haven't picked up a C compiler yet.  What are the 
    recomended ones?  And, how close are they to K&R?  

I have the Radio Shack/Microware C compiler.  It is pretty much standard
K&R, save for structure assignment and passing, bit-fields and enums.
It works just fine, except that any multi-pass compiler is excruciatingly
slow on a floppy disk based system.  I would also recommend that you
get double sided 40tk drives to make this bearable; otherwise one is
always swapping /d0/cmds disks, etc.

    How about other language compilers for OS-9?  Pascal?  Ada? 

I have Microware's BASIC09 which is rather like a cross between
PASCAL and BASIC.  Nice, fast, interpreted compiled language (interpreted
I-code.)  Unfortunately, due to the orthodoxy of the developers at
Microware, it has two severe deficiencies:

	no user-supplied functions (all are procedures, and value returning
	is simulated with call-by-reference.)

	no global variables--all variables must be local or passed by
	reference to procedures.

I don't doubt that one could adopt a programming style appropriate to
this, and it is by far better and faster than any BASIC I have seen, but
these two misfeatures have prevented me from using this as much as I
thought I would.

    How about a good editor that runs under OS-9? Maybe a vi or emacs
    clone.

After struggling with the OS9 line editor (which makes UNIX "ed" look
like a gem) I finally purchased Dynastar from Frank Hogg Labs in Syracuse.
This particular version runs with the FHL O-Pak which steals 8K to create
a 24 x 51 (or so) bit-mapped screen.  It's not quite VI or EMACS, but it's
not bad at all for a full screen editor.  I found myself getting used to
it very quickly.

    Anyone port any other UNIX commands to OS-9?  Maybe a package of
    routines?

There are several companies doing just this.  I purchased "Utilix" from
FHL for $49, which is quite a steal: "grep", "sort", "cat", "pr" and a bunch
of others.  Unfortunately, "grep" works best with wild card expansion,
which the OS9 shell lacks.  My next pet project is to produce an analogue
to /etc/glob, the pre-V7 UNIX wildcard expansion program.

    Since files are timestamped, I am contemplating writing an incremental
    backup utility.  Do any of the C's support getting the timestamp on files?

Microware C provides interfaces to all the OS9 system calls, so I would
assume that you would have access to this.

    Why did OS-9 developers not use the actual UNIX command names?
    Were they trying to make it user-friendly?

Pure perversity.  Actually, I have always thought that they got much of
the sound of UNIX down pat, but little of the sense.  Witness "build",
a program which reads the standard input and creats a file
under the name of its argument.  What the hell is the matter with
"cat > filename"?

    What is the difference between t1 and p? Don't they use the same port?

Yes they do.  The serial bit-banger driver is a complete crock, and /t1
is practically useless at speeds greater than 300 baud.  The
different devices interpret the 4 serial wires differently--/p uses
carrier detect (I think) for flow control and is unidirectional, /t1
attempts valiantly to be a full-duplex device.  Obviously you wouldn't
want to use both at once (it MUST be obvious because Radio Shack surely
neglected to mention this in its manuals!)
-- 
/Steve Dyer
decvax!bbncca!sdyer
sdyer@bbncca.ARPA