Path: utzoo!yunexus!stpl!peter
From: peter@stpl.UUCP (Peter CAMILLERI)
Newsgroups: comp.sys.nsc.32k
Subject: real time op sys for the 32k. repost.
Message-ID: <175@stpl.UUCP>
Date: 6 Dec 88 23:10:25 GMT
Article-I.D.: stpl.175
Reply-To: peter@stpl.UUCP (Peter CAMILLERI)
Organization: ISTS/Solar Terrestrial Physics Lab
Lines: 82

I first posted this note a few weeks ago, and have been puzzled by the
lack of response. Then I remembered the bad case of HIV (Huge Internet Virus)
that caused so much trouble and figured it had clobbered my message. So
heres a repost. If you read the original and did'nt like it, tough! Flame
away, it's cold in the winter around here!

=========================================================================

Let me start of by saying that I am most pleased to note the larger volumes
of postings in this group. Many times I have felt that my technical questions,
all of which were answered very well, were about the only traffic. Keep the 
flow going!!!

I have been designing an application with the 32k for some time now, and I
can't help but feel that software options are limited to the following:

    Un*x - big, slow, expensive, monolithic.
    RTKs - tiny, fast, expensive, no local dev't tools.

I see the need for a 32k equivalent of the Motorola encouraged, OS/9 and
OS/K products. Its notable features are quick real time response, modular
construction ( modules, drivers and even file systems can be added on the
fly ), and small (128k RAM min, 256k or more recomended). 

The reason I mentioned this is that on several occasions I have noticed
similar pleas for such an OS in this newsgroup, and felt that I should
get off my duff and contribute to this fine idea!

So some brass tax :-)
  a modular approach would more readily facilitate a diverse genesis of
  our fledgling. The work could be divided on a module by module basis.

  each module could exist in several incarnations, and with some work, one
  could mix and match modules to create the desired whole.

Several approaches could be utilized to create the above nirvana. A few come
to mind:
1) a small message passing kernel, with modules implented as server tasks
      minix uses this approach, I think.
2) a small kernel is used to direct subroutine call via a network of indirect
   pointers. This is basically the OS/9 way, and it is quite fast, but not
   very portable.
3) and many more but this posting is getting too long :-)

I have acces to a 32k assembler, limited access to an ICM16 running BSD4.2,
and access to other Un*x based machines of less noble birth (ie: this one).
My message is simple. We need action! If a mailing list has been created,
please put me on it, else lets create one!

-- 
Peter Camilleri                              peter@ists.UUCP
Elan Data Technology Inc.                    peter@ists.yorku.ca
836 Yonge St., Toronto, Ontario,             uunet!mnetor!yunexus!ists!peter
CANADA M4W 2H1                               (416) 968-6668

=========================================================================

P.S I lied. I did get one response from nsc, suggesting that we consider
    looking into a nsc product called "Exec". There are a few problems
    with this.

    1) It is crucial that the op. sys. have NATIVE development tools. That
       is its own compilers, assemblers, edtiors etc. The "Exec" product
       has none of this, but could be a starting point...

    2) Perhaps this did'nt come through in the original posting, but as this
       system would be generated by community effort, it should be generally
       available in a manner not unlike GNU software. The "Exec" product is
       the property of nsc. Now if nsc would consider such a usage of a 
       pruduct that even it says:
                                                               Ray Curry

       I'm not certain in any event of the dispostion of nsc toward that
       sort of thing and the kernal of a properly designed system should
       be a small amount of albeit very finely crafted code.


-- 
Peter Camilleri                              peter@stpl.UUCP
Elan Data Technology Inc.                    
836 Yonge St., Toronto, Ontario,             uunet!mnetor!yunexus!stpl!peter
CANADA M4W 2H1                               (416) 968-6668