os9@cbosgd.att.com (09/15/86)
OS-9 Discussions Monday, September 15th 1986 Volume 2 : Issue 2
Today's Topics:
Corrections, confusing documentation & pipes
Ports to OS-9
Atari ST Port Ready
OS-9 vs. Unix: sharing entities
OS9/68K F$STrap System Call
--------------------------------------------------------------------------
Date: Sun, 31 Aug 86 19:43:52 pdt
From: Bob Larson <sdcrdcf!usc-oberon!blarson>
Subject: Corrections, confusing documentation & pipes
[The following applies to OSK 1.2 with the 2.0 C compiler.]
A couple of corrections to a previous article of mine:
l68 does try and fix pc-relitive pea instructions. It just
does them wrong.
The "make" tab bug is in version 1.2, not 1.3. (Is there a 1.3 yet?)
One more minor bug: The sources distributed with the OSK C compiler
(2.0) have \l characters where \n's belong. This is easy to fix with tr.
Confusing documentation:
The getstat code 1 is documententations states: "The return value is
the number of bytes available or -1 if an an error occured." This
means to me that 0 will be returned if no characters are availble,
when in fact -1 is returned in this case. (Since the action is
compatable with os9/6809, I consider this a documentation rather than
impliminatation bug.)
The _julian documentation, and the F$Julian system call, suposedly
can return errors. However, in actual practice, no error is returned
for non-existant dates. (February 31, etc.) This should at least be
documented as a caveat in the documentation.
There was a question about pipes on os9/6809 posted. Since I havn't
used that for about a year, and never did play with pipes much on it,
I'll answer for osk and hope that some of it applies. (I know the
6809 version does not have named pipes.)
Under osk, there are two types of pipes: named and unnamed. Unnamed
pipes are what are familiar to unix users, and what is created by
using the ! operator to the shell. They are used for communication
between a process and a parent/desenant process, or sibling processes
if the pipe was set up by the parent. Creating one is simple: just
open the device /pipe. Each open of /pipe will create a separate
unnamed pipe, to communicate through one the open path should be
dup'ed. To pass one to another process, it must be one of the open
files passed. (0, 1, or 2 (stdin, stdout, stderr) using os9fork or
os9chain, any of the open files passed with os9forkc or os9chainc.)
The unix popen and pipe routines are fairly easy to duplicate. (I
don't know why they arn't in the standard library.) One difference
between OSK pipes and unix pipes that may be significant is OSK
usually uses much smaller buffers on its pipes. Programs that expect
to be able to do non-blocking output to a pipe beware.
Named pipes are useful for comunication between processes where the
inherited file descriptor aproach is inapropriate. Rather than
opening /pipe, you open /pipe/NAME where NAME is the name of the pipe
desired. All processes opening the same named pipe will share it.
Normally, a pipe should only have one reader and one writer. By
opening an unnamed pipe in the directory mode, you may read the list
of all open named pipes.
For more information on pipes, read chapter 9 in "the os9/68000
operating system technical manual" and experiment.
--
Bob Larson
Arpa: Blarson@Usc-Eclb.Arpa or blarson@usc-oberon.arpa
Uucp: (ihnp4,hplabs,tektronix)!sdcrdcf!usc-oberon!blarson
------------------------------
From: Peter C. Dibble <seismo!rochester!dibble>
Subject: Ports to OS-9
Date: Fri, 29 Aug 86 16:57:24 edt
> What is the statusof porting micro emacs over to os9? The last I saw,
> Bob Larson had ported an early, maybe around 3.1, version to OSK on
> his QT, and there was support for the CoCo with the standard 32x16
> screen along with his source code.
>
> Does anyone have any news on A) Porting a newer veresion, or B) A port
> for Tandy Color Computer with the PBJ Word-Pak?
>
Software ported to OS-9/68K:
I ported MicroEmacs 3.6 to OS-9/68K. I sent it (with a port of Hack) to
Microware. My suggestion was that they note how nice MicroEmacs was, bless
it, and support it as some kind of second-tier product. I think they will do
exactly that.
I don't know what the fate of Hack should be. It's not public domain so
I can't give the source to the Users Group. The copyright holder has given
me permission to hand out the executable form, but I ported it to my system
(ANSI terminal and all). When termcap support comes out (soon I hope) I
may be able to do something useful with what I have.
I hesitate to put my port of MEmacs 3.6 on the net because it's big. If
there's a great deal of interest in it, I would be willing to upload it
to this machine and think about diff'ing it with the unmodified version
or something. (It'll have to be "something." I just checked. All I have
in unmodified form is 3.7.)
::: I just ported the XLISP that came over the net. It compiled and ran
almost without change. I added a random number generator to the unix_
environment file and called it OS9...
and I fixed the VARARGS function that deals with the stack. It seems
to work fine.
Peter Dibble
------------------------------
From: fluke!mcrware!kim (Kim Kempf)
Subject: Atari ST Port Ready
Date: 1 Sep 1986 2105-CDT (Monday)
>About a month ago I sent Kim Kempf mail requesting information about
>Microware products, specifically OS-9 and the Commodore Amiga.
>Can anyone there help me?
I don't know about the Amiga but the Atari ST port is ready to go. The company
doing the port and distribution/support is TLM Systems. As of Friday, Aug 29,
their port checked out and was approved by Microware. I imagine they should
be shipping this next week. For any further information, contact TLM Systems
or Microware.
------------------------------
From: fluke!mcrware!jejones (James Jones)
Date: 2 Sep 1986 1636-CDT (Tuesday)
Subject: OS-9 vs. Unix: sharing entities
As far back as the Unix version described in the 1974 Ritchie and Thompson
paper, Unix could share programs. It is only extremely recently that Unix
could share anything smaller than a program (latest release of V: the System,
as you note). Unix, however, is still very much based on static linking, so
you must make your decision at compile time.
OS-9, on the other hand, supports dynamic linking, so the switch from a soft-
ware math library to hardware could occur in the dead of night without the
programmer's knowledge (save puzzled comments on the order of "Gee, things
seem to be going faster" :-) and with no modification to the executables.
OS-9 needs software that takes full advantage of dynamic linking, rather
than Unix castoffs. Examples:
1. There should be exactly one editor module, that handles loading, saving,
searching, and modifying hunks of text. Whether it looks like vi, emacs,
ed, TECO (yecch :-), or some mouse-driven construct is a matter for
some user-interface module to determine. Ditto for mailers, Kermit, and
so forth.
2. OS-9 could trivially provide the capabilities I understand that "streams"
provide--what one would have to do is allow multiple modules to live
in the "Great Chain of Being" of IOMAN->file manager->device driver.
Examples: terminal-specific modules that are inserted between SCF and
the device driver to take GET/SETSTAT calls to support what is done on
Unix via the horrid termcap/terminfo package, that runs interpretively
to puzzle out stuff for every terminal known to man and would collapse
under the weight of /etc/termcap if entries couldn't be loaded into the
environment; modem-specific modules to interpret GET/SETSTAT calls for
dialing, hangup, and so forth; a module that a determined user could
write that would do caching for disk transfers that he/she could slide
between RBF and the current device drivers.
If these sorts of things were done, one could have a very much nicer
environment under OS-9 than Unix--OS-9 could support such programming
languages as Modula-2, CLU, Ada, and so forth far better than Unix can,
too. One could truly share code in a reasonable fashion, and customize
one's environment to one's heart's content, even for proprietary packages
for which one did not have source, as long as one knew the interface. (As
the caching example above shows, OS-9 itself is an example of this.)
Quick--is it ? or . to match an arbitrary character? Why should you have
to think about it, I ask. It's the moral equivalent of all those IBM
360/370oids knowing whether continuation cards can start anywhere up to
column 16 or have to start exactly on column 16. What a thing to build
one's career on.
James Jones,
speaking only for myself
------------------------------
From: ihnp4!seismo!mcvax!cernvax!angela
Date: Wed, 10 Sep 86 16:29:40 +0200
Subject: OS9/68K F$STrap System Call
I'd like to pose several questions concerning F$STrap to the os-9
experts. I'm currently using OS-9/68K, version 1.2.
I'm writing several real-time processes which need to communicate with
MC68008-based boards via dual port memory. It is conceivable (heaven-
forbid) that somebody could come along and pull out one of these boards,
causing a bus error the next time the cards dual-port memory is addressed.
I would like to use the F$STrap system call to catch the bus error and
do some other processing. It would be nice to know which process and
which external I/O address caused the bus error (ie. tells me which board
shouldn't be addressed).
1. Can anybody give me a clearer example than the documentation gives
on how to use F$STrap when dealing with a bus error?
2. Is it feasible to find out the process and external I/O address
causing the bus error? I can imagine a way of doing this by
using the PC against the module directory information to identify
the process and presumably, the address can be got from one of the
address registers in the stack image. This, however, sounds long-
winded and complicated to me.
3. How can I find out a suitable position to restart the erring process
so that it can, at least, deal with other boards correctly, and
ignore the faulty one? (the process is written in C). I don't
really want to terminate the process and then restart it, as it has
an initialisation phase I don't want repeating.
I would greatly appreciate any suggestions that may push me in the right
direction. Please reply by e-mail.
Angela Smith
CERN, Geneva
angela@cernvax.UUCP
------------------------------
From: ihnp4!ihwpt!knudsen
Date: Thu, 11 Sep 86 14:46:36 edt
Subject: Level II CCDISK in the Coco-III
About Level II for the new Coco-III: does anyone know
whether the floppy disk driver (CCDISK) has been restored to
use the device descriptor?
Or is it still "Shacked up" with hardwired constants for
SS 35-track, 30-ms steprate drives?
mike knudsen
-------------------------------------
The views expressed in OS-9 Discussions are those of the individual authors
only.
------
Moderator: John Daleske cbosgd!cbdkc1!daleske daleske@cbdkc1.ATT.COM
Submissions should go to cbosgd!os9 os9@cbosgd.ATT.COM
Comments to the moderator
or to join the mailing cbosgd!os9-request os9-request@cbosgd.ATT.COM
list.
*********************
End of OS-9 Discussions
*********************