HDTenEightyP/NetNews huggingface dataset:
From: peter@citr.uq.oz.au (Peter Klavins)
Subject: Re: Booting dos from ROM
Keywords: DOS ROM BOOT
Organization: Prentice Centre, University of Queensland
Date: Thu, 3 Sep 1992 06:37:23 GMT

cole@noao.edu (Lonnie Cole) writes:

>I am posting this here because I intend to use a PC/XT board in a
>realtime data acquisition project.

>Does anyone know of instructions and or source in the public domain to
>allow booting dos from a battery backed RAM disk or ROM disk. Any
>pointers to code or docs would be greatly appreciated.

Microsoft's MS-DOS OEM kit (you have to become an OEM) includes
information on how to put DOS 5.0 into ROM so that you can have a
completely diskless system boot up DOS.  Of course, you ultimately have
to have a file system somewhere from where to obtain the programs that
you want to run once DOS is booted.  A file system skeleton that works
out of ROM is also included.  (By skeleton I mean that you probably will
need to add code to page bits if ROM in and out, or go off into above 1
Mbyte memory space in order to get enough ROM to hold anything of useful
size in.)

Anyway, the kit worked very well, and systems based on it are now being
sold commercially.  But, the price is that you must become a Microsoft
OEM.
--
------------------------------------------------------------------------
 Peter Klavins    Internet: peter@citr.uq.oz.au   Fidonet:    3:640/821
 Centre for Information Technology Research       Phone: +61 7 365 4321
 University of Queensland QLD 4072 Australia      Fax:   +61 7 365 4399
From: dcb0@gte.com (Daniel Bazinet)
Newsgroups: comp.realtime
Subject: real-time info desired
Keywords: fuel injection automotive
Date: 31 Aug 92 21:02:35 GMT
Organization: GTE Laboratories Incorporated, Waltham MA


Hi,
	Does anybody know of a good source/book of info on
	real-time implementations ( both hardware and software )
	such as automotive fuel injection systems, turbo waste-
	gate operations etc, etc.  I'm getting into embedded systems
	and feel that detailed examination will help my understanding
	further.

				Thanks,
					Dan Bazinet
From: chonoles@acc.vf.ge.com (Chonoles Michael Jesse)
Newsgroups: comp.realtime
Subject: Object-Oriented Real-Time
Keywords: object
Date: 31 Aug 92 15:28:13 GMT
Organization: GE ACC

I'd be very interested in any reference material (books, articles, etc.)
that would cover the application of object-oriented techniques to real-time 
problems.

Please send me your favorites. If I get enough I will post a summary.

Thanks

-- 
Michael Jesse Chonoles
Newsgroups: comp.realtime
From: muts@fysap.fys.ruu.nl (Peter Mutsaers)
Subject: LynxOS diskless client possible?
Organization: Rijks Universiteit Utrecht
Distribution: comp
Date: Fri, 28 Aug 1992 09:54:06 GMT

Hello,

for our RT applications in VME environment we don't want to put SCSI
interfaces and disks in all our racks. Therefore I wonder if it is
possible to have LynxOS boot as a diskless client from a server, like
diskless workstations do. Any help appreciated,
--
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@fys.ruu.nl         |              Memento Mori
Newsgroups: comp.realtime
From: smb@genrad.com (Steve M. Blumenau)
Subject: used vme and/or vxi equipment
Keywords: vme vxi
Organization: GenRad, Inc.
Date: Thu, 27 Aug 1992 15:08:49 GMT

Does anyone know of the best publications to look at to find
used vme and vxi equipment for sale.

Steve Blumenau
{decvax,linus,wjh12,mit-eddie,cbosgd,masscomp}!genrad!panda!smb
smb@bassun
From: hansen@deci.cs.umn.edu (David M. Hansen)
Newsgroups: comp.realtime
Subject: Re: Booting dos from ROM
Keywords: DOS ROM BOOT
Date: 4 Sep 92 14:16:56 GMT
Organization: University of Minnesota

In article <peter.715502243@citr.uq.oz.au>, peter@citr.uq.oz.au (Peter Klavins) writes:
|> cole@noao.edu (Lonnie Cole) writes:
|> 
|> >I am posting this here because I intend to use a PC/XT board in a
|> >realtime data acquisition project.
|> 
|> >Does anyone know of instructions and or source in the public domain to
|> >allow booting dos from a battery backed RAM disk or ROM disk. Any
|> >pointers to code or docs would be greatly appreciated.
|> 
|> Microsoft's MS-DOS OEM kit (you have to become an OEM) includes
|> information on how to put DOS 5.0 into ROM so that you can have a
|> completely diskless system boot up DOS.  Of course, you ultimately have
|> to have a file system somewhere from where to obtain the programs that
|> you want to run once DOS is booted.  A file system skeleton that works
|> out of ROM is also included.  (By skeleton I mean that you probably will
|> need to add code to page bits if ROM in and out, or go off into above 1
|> Mbyte memory space in order to get enough ROM to hold anything of useful
|> size in.)
|> 
|> Anyway, the kit worked very well, and systems based on it are now being
|> sold commercially.  But, the price is that you must become a Microsoft
|> OEM.
|> --
|> ------------------------------------------------------------------------
|>  Peter Klavins    Internet: peter@citr.uq.oz.au   Fidonet:    3:640/821
|>  Centre for Information Technology Research       Phone: +61 7 365 4321
|>  University of Queensland QLD 4072 Australia      Fax:   +61 7 365 4399

A couple of other suggestions...

I know of two companies which provide customizable BIOS's which could be
used in embedded systems.  Unfortunately, I don't have their addresses or
phone numbers handy.

One source is Annabooks.  Their phone number was posted in this group a couple
weeks ago.

The other is General Software (I think... I hope...).  The latest issue of
Embedded Systems Programming plugs their new BIOS.  This same company also 
sells a re-entrant embeddable DOS clone.

Disclaimer: I haven't used any of this stuff, so I don't really know how good
it is, let alone features and limitations.

Hope this helps.

						-=Dave
Newsgroups: comp.realtime
From: piotr@electro.electro.com (Piotr Pytlik)
Subject: Re: real-time info desired
Keywords: real-time and embedded systems
Organization: Electrohome Ltd., Kitchener, ON, Canada
Date: Tue, 1 Sep 1992 17:08:14 GMT

In article <18757@bunny.GTE.COM> dcb0@gte.com (Daniel Bazinet) writes:
>
>Hi,
>	Does anybody know of a good source/book of info on
>	real-time implementations ( both hardware and software )
>	such as automotive fuel injection systems, turbo waste-
>	gate operations etc, etc.  I'm getting into embedded systems
>	and feel that detailed examination will help my understanding
>	further.
>
>				Thanks,
>					Dan Bazinet

My question is more general. I'm trying to follow articles in this group, and
don't quite know much about real-time or embedded systems. Could somebody post
or reply to my address some information about what are those systems, where to
get more detailed information about any of them, what sort of hardware is
necessary for them... I appreciate anything that may be relevant.
   Thanx to anybody that can explain it to me.  Peter.

No signature yet. There is still plenty of time to design one.
In a meantime reply to piotr@electro.com
Newsgroups: comp.realtime
Subject: Re: Where to stick the watchdog? 
From: pjm@nutmeg.cs.ntu.edu.au (Phil Maker)
Date: 4 Sep 92 08:50:16 +0900
Distribution: world
Organization: Computer Science, Northern Territory University, Australia
Keywords: Watchdogs
Originator: pjm@nutmegLines: 67

> Recently I had an argument (discussion) with some co-workers regarding where
> is an appropriate place to kick a watchdog timer inside an application program.
> 
> Their side was 'stick it in the lowest level routine in a non-kernal based
> application, or stick it in the null task in a real-time kernal.'
> 
> I have problems with either solution. 
> [ Lots of reasonable problems deleted ]

My suggestion for kicking watchdogs would be a little more complicated.
(And I don't like watchdogs anyway but ...(And I don't like complicated 
solutions but ..)).

First lets determine what errors we would like to catch in the best of
all possible worlds.

* Processor interrupts disabled or kernel crashed so that some
  processes cannot be executed. 

	Use a low priority timer interrupt to start a low priority
	process which actually kicks the dog. (This provides a better
	test of the kernel and general health of the system).
	Of course timing deadlines come in to this but they are
	easy to solve aren't they. (:-))

* Code or data store trashed by cosmic rays, software errors and hardware
  features.

	Have a self test process that checksums the code every whatever
	pico seconds. The data space can have its integrity checked by
	having a data OK function provided by each module (or class). 
	This is very useful for testing and debugging and if you have
	the space in the product you could actually check some 
	of the data structures out on the fly to see that they
	meet the designers beliefs. 

* Checking that the system is actually working, i.e. making progress 
  towards the goals of the system.

	For example every hard real time event put a counter in the
	system. If these do NOT increase at the appropriate
	frequency then something is wrong. The test for these
	increases would done in the watchdog process.
	Intermittent events require the use of flags etc to
	determine if progress should be increasing but the method
	still applies. 

Final note: any rational engineer would of course implement a small 
	subset of the above. Error detection and correction is
	one of the most difficult areas of real time systems. 
	The best approach is to avoid the errors in the first place
	and have outside safety systems. (Not reliablity).,


				Phil Maker

				N.T. University
				Darwin, Australia.
From: griest@ajpo.sei.cmu.edu (Tom Griest)
Subject: Re: Where to stick the watchdog ?
Keywords: kernals watchdog 
Organization: Software Engineering Institute
Date: Thu, 3 Sep 1992 16:45:54 GMT

In article <1992Sep03.034229.13095@crs-sys.uucp> crs@crs-sys.UUCP (Chris Gregors) writes:
>Recently I had an argument (discussion) with some co-workers regarding where
>is an appropriate place to kick a watchdog timer inside an application program.
>

The answer to this depends on the type of "Watchdog" you have, and the
Fail-Stop/Fail-Operational characteristics of your system.  A technique
that I have used is to design the watchdog hardware to allow a very small
synchronized window for "kicking", and drive the watchdog off of a separate
oscillator.  This will pick up subtle problems like large drifts in
your clock rate, and will also detect bogus kicking of the watchdog.
The software uses a high priority periodic interrupt to "kick" the watchdog,
based on one or more "completion flags".  This provides great flexibility
to program the proper safeguards in how the completion flags are set.

  Tom Griest

Newsgroups: comp.realtime
From: egiannou@ntb.ch (Vangelis Giannoulas)
Subject: QNX experiences ?
Reply-To: egiannou@ntb.ch
Organization: Neu-Technikum Buchs, Switzerland
Date: Fri, 4 Sep 1992 14:26:31 GMT


Hi,

a friend of mine just told me about a job opening in his company. Since I'm about to graduate and 
looking for a job, I'm very glad about it. The thing is that the people at this company use QNX.
I don't know much about this system, since I'm using "normal" Unix (SunOS).

My question: Does anyone work with QNX ? Is it Unix or Unix-like ? Are the usual Unix
development tools available ? What about networking capabilities ?

Every comment is welcome.

Thanks a lot,

Vangelis

Newsgroups: comp.realtime
From: tomm@bnr.ca (Tom Mackenzie)
Subject: Specification and Description Language (SDL) Courses
Reply-To: tomm@bnr.ca (Tom Mackenzie)
Organization: Bell-Northern Research Ltd.
Date: Wed, 2 Sep 1992 15:19:21 GMT


I apologize if this has been asked before.

Does anyone know of courses available that teach SDL and its applications?

I will post a list of responses.

Thanks

Tomm
From: kron@ueshiba.Corp.Sun.COM (Kenneth Kron)
Newsgroups: comp.realtime
Subject: Re: uCOS by e-mail?
Date: 25 Aug 1992 20:34:29 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: kron@ueshiba.Corp.Sun.COM
NNTP-Posting-Host: ueshiba.corp.sun.com

First:
	I used DEC's mail server within the last few months and got
	fine overnight service from it.

Second:
	So what's your problem? Are you trying to convince me you can't
	complete the instructions?  I did say  COMPLETE not understand or read or
	whatever.   If you ARE just say so and I'll go fetch the stuff and email it to you.

In article U2NIBN7@taronga.com, peter@taronga.com (Peter da Silva) writes:
>In article <l9i6u1INNdj1@jethro.Corp.Sun.COM> kron@ueshiba.Corp.Sun.COM (Kenneth Kron) writes:
>>Dec has a mail server that will do ftp for you and email you the
>>results.
>
>Unless they've done something really amazing with it in the past 6 months, it's
>from all appearances totally snowed under by the volume of requests it's
>getting. Over a period of several months I made a number of requests for
>code from FTPMAIL, and only once did I get a complete response, probably
>because only two parts were needed.
>
>-- 
>                                                                `-_-'
>                         Have you hugged your wolf today?        'U`
>Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032



---
kron@mentor.sun.com
Stolen sig of the month ---
'Whatever you can do, or dream you can, begin it.  Boldness
has genius, power and magic in it.'  -  Goethe

Newsgroups: comp.realtime
From: john@iti.org (John Sauter)
Subject: Re: MOSI standard (IEEE 855)
Reply-To: john@iti.org
Organization: Industrial Technology Institute
X-Newsreader: Tin 1.1 PL4
Date: Wed, 26 Aug 1992 18:33:02 GMT

srm@matrix.com (Steve Morris) writes:
: 
: There exists an IEEE API standard: MOSI (Microprocessor Operating
: System Interfaces) which is apparently language independent.
: 
: Is this standard utilized/followed by any products?
: 
: Thanks,
: 
: -- 
: Steve Morris  ||  MATRIX Corp.  ||  919-231-8000 (8001 FAX) ||  srm@matrix.com

I have a copy of the standard published in 1985 sitting on my desk.  It
was an attempt to develop a standard OS interface for microcomputers
back in the days of 8-bit micros.  I have only seen one reference to it
in the literature (IEEE Computer, several years ago).  From what I have
seen, no one has ever implemented this standard.  It is now outdated.
All the real-time OS standards have converged on the 1003.4
activities.
-- 

John A. Sauter                         Industrial Technology Institute
e-mail: john@iti.org                   PO Box 1485
313-769-4171                           Ann Arbor, MI 48106
Newsgroups: comp.realtime
From: gratclif@magnus.acs.ohio-state.edu (Gregory W Ratcliff)
Subject: Re: Is anyone using UCOS???
Organization: The Ohio State University
Distribution: na
Date: Fri, 4 Sep 1992 02:00:56 GMT

In article <Bu0HDt.GCr@news.orst.edu> holtt@OCE.ORST.EDU (Tim Holt) writes:
>Hi...
>Is anyone actually using the PD UCOS package?  I downloaded it, and
>looked at the code a bit, but when I saw that it had no documentation
>and only refered to a (semi) obscure journal article, I recompressed it
>and left it on the scratch disk.
>
Sure its GREAT!  Less filling too.  Compiles to 4900 bytes with
archimedes on a z80/64180.  

After getting it to run with microsoft c, the z80 port has taken 
about 10 hours.  I think I'm about half way.

>Is there any other documentation?  Does anyone have an on-line copy of
>the article referenced (May, June 1992 Embedded System Programming Magazine).
You will have to get this.

>
>Looks neat source code wise -- at least there are lots of variables with
>fancy names.  But what will it do for me?
>
>Tim Holt	Marine Tech group	Oregon State Oceanography

Watch for Labrosse's book its due out soon.  Subject: uCOS.


Greg Ratcliff

-- 
Gregory W. Ratcliff  Ratcliff.8@osu.edu  on the internet   
Columbus, Ohio     ICBM
nz8r@w8cqk 	 on the air
N1697X     	 in the air
From: crs@crs-sys.uucp (Chris Gregors)
Newsgroups: comp.realtime
Subject: Where to stick the watchdog ?
Summary: Kick the dog and make him bark! 
Keywords: kernals watchdog 
Date: Thu, 03 Sep 1992 03:42:29 GMT
Reply-To: crs@crs-sys.UUCP (Chris Gregors)
Organization: Confusion Control

Recently I had an argument (discussion) with some co-workers regarding where
is an appropriate place to kick a watchdog timer inside an application program.

Their side was 'stick it in the lowest level routine in a non-kernal based
application, or stick it in the null task in a real-time kernal.'

I have problems with either solution. Assuming that a real-time kernal is
rom'ed, and fully pre-emptive (don't ask about some of our other home brews),
that the context switch would occur on some interrupt event. Quite possibly,
even in a runaway situation, the null task could be executed. The dog gets
kicked and life continues.

In a non-realtime application, the suggestion of sticking the kick in a low
level i/o function has problems. You need a function that is very periodic.
But what if your application doesn't have such a function ? Stick it inside
something like printf() ? Not periodic enough. Inside the main command loop or
in the state-machine ? which state ? what about using a state-machine dispatch
function and stick it there ? and ... and ...

It seems to me that there is no generic, works every time place to put the
kick for a watchdog.

Thoughts ? Observations ?

-- 
| Chris Gregors aka General Mayhem                                           |
| The secrets of the universe are very simple, I just can't figure them out! |
Newsgroups: comp.realtime
From: cole@noao.edu (Lonnie Cole)
Subject: Booting dos from ROM
Keywords: DOS ROM BOOT
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Mon, 31 Aug 1992 23:25:54 GMT

I am posting this here because I intend to use a PC/XT board in a
realtime data acquisition project.

Does anyone know of instructions and or source in the public domain to
allow booting dos from a battery backed RAM disk or ROM disk. Any
pointers to code or docs would be greatly appreciated.

Thanks in advance.
Lonnie

-- 
Lonnie R. Cole                             Voice:    (602) 323-4162
National Optical Astronomy Observatories   Fax:      (602) 325-9278
P.O. Box 26732                             Internet: cole@noao.edu  
Tucson, AZ 85726                           Usenet:   ...!uunet!noao.edu!cole
Newsgroups: comp.realtime
From: ljg@space.physics.uiowa.edu (Larry Granroth)
Subject: realtime os for 8085
Summary: want realtime os for 8085
Keywords: realtime os 8085
Organization: The University of Iowa, Department of Physics and Astronomy
X-Newsreader: Tin 1.1 PL5
Date: Thu, 3 Sep 1992 14:25:43 GMT

Can anyone out there provide info on the availability of realtime os
software for an Intel 8085?  (Something like iRMX, maybe?)

Please respond directly to me and I'll summarize in the (extremely
unlikely) event that I receive any requests for a summary.

Thanks.

larry-granroth@uiowa.edu
From: salerno@ast.dsd.northrop.com (Peter Salerno)
Newsgroups: comp.realtime
Subject: Re: Porting Unix applications to PSOS (looking for off-shelf libraries)
Keywords: unix psos realtime libraries greenhill compiler
Date: 24 Aug 92 14:21:34 GMT
Organization: Northrop Corp - ESD, Rolling Meadows, IL

In article <1108@trane.UUCP> sean@trane.UUCP (Sean Gallagher) writes:
>Things I am trying to find:
>	Motorolla 68XXX cross compiler which will run on silicon graphics
>	workstations. 
>	Unix C libraries (standard, math) for PSOS.
  pREPC from ISI (SCG) will provide the standard i/o, and the string
handling libraries.
  For a math lib we extracted the math functions from our Microtec
Resaerch Inc. C cross compiler.  They make compilers that run on a
variety of machines. I am not sure if they have one for your
workstation.
Organization: Valencia University (Universitat de Valencia)   SPAIN
Date: Thursday, 3 Sep 1992 12:26:16 EST
From: <CERVERON@EVALUN11.BITNET>
Newsgroups: comp.realtime
Subject: real-time device drivers?

Hi,
   does anybody know of papers/books on device drivers designed and
implemeted for real-time systems? I'm mainly interested in device drivers
written in user-level, i.e, out of the kernel.
   I'm also interested in benchmarks for I/O under non-real-time operating
systems.

Thanks in advance

email to: cerveron@vm.ci.uv.es        ______/..._ ^France-Europe
smile to: Vicente Cerveron           |..Spain  /
                                     | :     */ Valencia
                 , _ ,               |_:_  __/
spanish products   n    from Spain       \/
Newsgroups: comp.realtime,comp.robotics
From: apollo@ecf.toronto.edu (Vince Pugliese)
Subject: high-performance PC data acquisition system
Organization: University of Toronto, Engineering Computing Facility
Date: Wed, 2 Sep 1992 19:17:12 GMT

one of the researchers in our group is trying to set up 
an experiment that involves a fair bit of computational
effort as well as the obvious d/a and a/d tasks. one of the suggestions
that we are looking into is to add an i860 board into a
386 AT-type machine and put in some data acquisition cards.

we were wondering if others on the net are doing anything like this
or if anyone has any suggestions for data acquisition systems that
require a considerable computational effort.

any and all suggestions would be greatly appreciated!!!!!!!!!!!

apollo@ecf.utoronto.ca
-- 
apollo@ecf.utoronto.ca
Newsgroups: comp.realtime
From: uemura@isl.melco.co.jp (Joe Uemura)
Subject: realtime benchmarks
Organization: Mitsubishi Electric, Ofuna, Kanagawa, Japan
Distribution: comp
Date: Fri, 28 Aug 1992 02:43:26 GMT


I am looking for realtime benchmarks which:

1. measure the regular things such as context switch time, 
preemption time, interrupt latency, etc.,
2. run entirely in user-state, ie. do not require kernel modifications, 
3. run on various flavors of Unix

I would appreciate any pointers to either sources or descriptions of such
benchmarks. Also, I was wondering how much of (1) can be accomplished given
(2). This might explain the apparent dearth of benchmarks which possess the 
characteristics given above, specially when compared to the numerous general
processor performance benchmarks.

Thanks in advance,

Joe
Newsgroups: comp.realtime
From: peter@taronga.com (Peter da Silva)
Subject: Re: uCOS by e-mail?
Organization: Taronga Park BBS
Date: Wed, 26 Aug 1992 02:56:18 GMT

In article <l9l6alINNfop@jethro.Corp.Sun.COM> kron@ueshiba.Corp.Sun.COM writes:
>	I used DEC's mail server within the last few months and got
>	fine overnight service from it.

That's nice.

>	So what's your problem? Are you trying to convince me you can't
>	complete the instructions?

I'm not even interested in the product. I'm just getting tired of folks
pointing to FTPMAIL or (when it was alive) BITFTP and assuming that they're
a replacement for source groups. PLUS if the product is even mildly
popular, they're FAR less efficient than posting.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: comp.admin.policy,alt.comp.acad-freedom.talk