HDTenEightyP/NetNews huggingface dataset:
From: tr@samadams.princeton.edu (Tom Reingold)
Subject: Re: BASICA programming bugs
Organization: Noo Joizy, USA
Date:  3 Sep 92 13:55:59 GMT

anash@uhunix.uhcc.hawaii.edu (Dana Uehara c/o Andrew Nash) writes:

$ (If this article is not in the proper newsgroup, please forward it to the
$ proper newsgroup -- thanks!)

$ Does anyone have any suggestions as to how to debug BASIC/BASICA programs
$ so the graphics commands don't lock up the computer?

$ I have an IBM-compatible computer with a CGA screen.  Most DOS and BASIC
$ programs are compatible with the computer (I think the DOS version is 2.0).

$ However, with a few computer programs written in BASIC the commands "GET"
$ and "PUT" seem to be the culprits in locking up the computer.  When deleted,
$ the programs appear to run normally.  But when kept, the commands either
$ produce strange graphics on the screen or completely lock up the computer
$ so I have to reboot the system to do any further work.

$ Is there a way to redo the statements (instead of using GET/PUT) so the
$ computer (hopefully) won't lock up?  A couple of other programs that use
$ similar statements have worked, but most haven't.

$ DEBUG.COM hasn't really been much help because I'm not familiar with machine/
$ assembly language (I'm more familiar with BASIC).  One of the commands I
$ encountered, however, when using DEBUG had a statement "LOCK".

The BASICA.COM that comes with IBM PC-DOS is intended for PC's made by
the IBM corporation.  This is one place where so-called compatibles are
not so compatible with IBM's.  If you are using IBM's BASICA, I would
things not to work.

The reason for this is that IBM's interpreter calls routines in the IBM
ROM.  These routines are not in ROMs of compatible PC's for copyright
reasons.  So the BASIC interpreter must have all the calls in software
since there is no ROM helping out.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.bugs.misc
Subject: Re: BASICA programming bugs
Date: 28 Aug 92 16:08:50 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)

In article <1992Aug28.092454.1412@news.Hawaii.Edu> anash@uhunix.uhcc.hawaii.edu (Dana Uehara c/o Andrew Nash) writes:
>However, with a few computer programs written in BASIC the commands "GET"
>and "PUT" seem to be the culprits in locking up the computer.  When deleted,
>the programs appear to run normally.  But when kept, the commands either
>produce strange graphics on the screen or completely lock up the computer
>so I have to reboot the system to do any further work.

This is usually caused by passing very strange parameters to the GET and
PUT functions.

If many programs by different authors fail on your computer, it is possible
that you have a hardware problem.

>DEBUG.COM hasn't really been much help because I'm not familiar with machine/
>assembly language (I'm more familiar with BASIC).  One of the commands I
>encountered, however, when using DEBUG had a statement "LOCK".

No one would intentionally design an instruction to lock up a computer
into an assembly language and call it that.  (They'd give it a better
name, like "HALT".)  The "LOCK" you saw is a prefix to another instruction;
it tells the CPU that the instruction is to be run without interruption.
This sort of thing is useful when dealing with interrupt handlers or
task switching.

>Any advice would be appreciated.

First, don't use DEBUG to debug a BASIC program.  BASICA is an interpreter,
not a compiler, so you are NOT going to get very far.

Second, I suggest that you look at the TRON, TROFF, STOP, GET, and PUT
entries in your BASIC manual.  TRON and TROFF let you trace the progress
of a BASIC program.  STOP lets you set a breakpoint in the middle of the
program so that you can take a look at the program's current state.  The
GET and PUT entries are important for obvious reasons.  Check out the
space requirements outlined under GET, because those are probably being
being violated.

Good luck!

   Stephen

-- 
"Beware of programmers who     Stephen Trier
 carry screwdrivers."          Network Services Engineering, IRIS/INS/Telecom
       Leonard Brandwein       Case Western Reserve University
                               trier@ins.cwru.edu
Newsgroups: comp.bugs.2bsd
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: telnet netdata dump misformatted, workaround for _doprnt (#70)
Organization: GTE Government Systems
Date: Wed, 26 Aug 92 04:24:27 GMT

Subject: telnet netdata dump misformatted, workaround for _doprnt (#70)
Index:	ucb/telnet.c 2.11BSD

Description:
	Using "toggle netdata" results in a misformatted hex display.

Repeat-By:
	Issue a "toggle netdata" command and observe the hex dump produced
	by telnet.  There are extra 0 characters present because of the
	way _doprnt processes format specs such as "%.2x".

	The 4.3BSD _doprnt generates the expected two digit display for
	each byte.  The 2.11BSD _doprnt does not, instead a leading 0
	is produced!

	The following test program will show how the 2.11BSD _doprnt
	handles the various attempts at producing a 2 hex digit output
	for a byte of data:

	-------------------------cut here----------------------------
	char	*p;

main()
	{
	printf("2.2|%2.2x\n", 0xff);
	printf(".2|%.2x\n", 0xff);
	printf("2|%2x\n", 0xff);
	printf("02|%02x\n", 0xff);
	putchar('\n');
	printf("2.2|%2.2x\n", 0x05);
	printf(".2|%.2x\n", 0x05);
	printf("2|%2x\n", 0x05);
	printf("02|%02x\n", 0x05);
	}
	-------------------------cut here------------------------
	Results:
 2.2|0ff
 .2|0ff
 2|ff
 02|ff
 
 2.2|05
 .2|05
 2| 5
 02|05

Fix:
	Rewriting _doprnt is not something i really want to do at the
	moment (volunteers?).  The 4.3BSD assembly language version makes 
	use of Vax instructions such as "editpc", etc - not pleasant things to
	emulate.  The 4.3Reno version is written in C but appears to
	be insistent/dependent on having an "unsigned long" data type which
	is not currently available in the 2.11BSD C compiler.

	Rather than rewriting/fixing doprnt.s the format spec was changed
	in telnet.c to produce the desired output.

	Apply the (very small) change to telnet.c and reinstall 'telnet'.
	You'll first want to install patch #69 which fixes the %c bug
	in _doprnt.

-----------------------cut here-------------------------------
*** /usr/src/ucb/telnet.c.old	Tue Jul 31 13:39:39 1990
--- /usr/src/ucb/telnet.c	Tue Aug 25 13:33:00 1992
***************
*** 551,557 ****
  	pThis = buffer;
  	buffer = buffer+min(length, BYTES_PER_LINE);
  	while (pThis < buffer) {
! 	    fprintf(NetTrace, "%.2x", (*pThis)&0xff);
  	    pThis++;
  	}
  	fprintf(NetTrace, "\n");
--- 551,557 ----
  	pThis = buffer;
  	buffer = buffer+min(length, BYTES_PER_LINE);
  	while (pThis < buffer) {
! 	    fprintf(NetTrace, "%02x", (*pThis)&0xff);
  	    pThis++;
  	}
  	fprintf(NetTrace, "\n");
Newsgroups: comp.bugs.2bsd
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: overlooked filename trunctations (#75)
Organization: GTE Government Systems
Date: Mon, 31 Aug 92 05:28:59 GMT

Subject: overlooked filename trunctations (#75)
Index:	usr.lib/sendmail/cf.named 2.11BSD

Description:
	A few file names were overlooked in the "liberation from the 14
	character limit".

Repeat-By:
	
	ls -l /usr/src/usr.lib/sendmail/cf.named

	Observe the names ending in "." or ".m" - they should really
	be ending in ".m4".

Fix:

	Run the shell script below, it will rename the errant files.
=================================cut here=================================
#! /bin/sh
cd /usr/src/usr.lib/sendmail/cf.named
mv nicregistered. nicregistered.m4
mv postwriterule. /usr/src/usr.lib/sendmail/cf.named/postwriterule.m4
mv prewriterule.m prewriterule.m4
Newsgroups: comp.bugs.2bsd
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: _doprnt %c bug  (#69)
Organization: GTE Government Systems
Date: Wed, 26 Aug 92 04:22:20 GMT

Subject: _doprnt %c bug  (#69)
Index:	lib/libc/pdp/stdio 2.11BSD

Description:
	There is a serious bug in _doprnt's handling of %c.  Null characters
	are ignored!  This causes a problem in 'telnet's terminal type
	negotiations which need a null byte after the suboption byte.

	The %r command was also removed since it was undocumented and not
	present in 4.3BSD (or later).  A side benefit is the saving of a few 
	bytes of space.

Repeat-By:
	Run the test program below.  If the output is not 3 then the bug
	is present.

	---------------------------cut here------------------------
	char	buf[32];

main()
	{
	sprintf(buf, "%c%c%c%c%s%c%c", 0xff, 0xfa, 0x18, 0x00,
		"VT100", 0xff, 0xf0);
	printf("strlen = %d\n", strlen(buf));
	}
	------------------------cut here-------------------------

Fix:
	Apply the patch below and replace doprnt.o in /lib/libc.a and
	/usr/lib/libc_p.a.  Save the patch below into /tmp/foo and:

		cd /usr/src/lib/libc/pdp/stdio
		patch < /tmp/foo
		make
		ar /lib/libc.a doprnt.o
		cd profiled
		ar /usr/lib/libc.a doprnt.o
		cd ..
		ranlib /lib/libc.a /usr/lib/libc_p.a
		make clean
--------------------------cut here-------------------------------
*** /usr/src/lib/libc/pdp/stdio/doprnt.s.old	Thu Dec 31 16:10:52 1987
--- /usr/src/lib/libc/pdp/stdio/doprnt.s	Tue Aug 25 19:42:46 1992
***************
*** 5,11 ****
   */
  
  #ifdef LIBC_SCCS
! 	<@(#)doprnt.s	5.4 (Berkeley) 1/25/87\0>
  	.even
  #endif LIBC_SCCS
  
--- 5,12 ----
   */
  
  #ifdef LIBC_SCCS
! /*	<@(#)doprnt.s	5.4 (Berkeley) 1/25/87\0> */
! 	<@(#)doprnt.s	5.5 (GTE) 8/25/92\0>
  	.even
  #endif LIBC_SCCS
  
***************
*** 34,40 ****
  	longorunsg;	'l
  	longorunsg;	'L
  	unsigned;	'u
- 	remote;		'r
  	long;		'D
  	loct;		'O
  	lhex;		'X
--- 35,40 ----
***************
*** 244,251 ****
  charac:
  	mov	$' ,zfill(r5)
  	mov	(r4)+,r0
- 	bic	$!377,r0
- 	beq	prbuf
  	movb	r0,(r3)+
  	br	prbuf
  
--- 244,249 ----
***************
*** 282,293 ****
  1:
  	mov	pc,r2
  	jsr	pc,pscien
- 	br	prbuf
- 
- remote:
- 	mov	(r4)+,r4
- 	mov	(r4)+,formp(r5)
- 	jmp	loop
  
  prbuf:
  	mov	sp,r2
--- 280,285 ----
Newsgroups: comp.bugs.2bsd
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: nslookup thinks sri-nic.arpa exists - oops! (#76)
Organization: GTE Government Systems
Date: Mon, 31 Aug 92 05:32:01 GMT

Subject: nslookup thinks sri-nic.arpa exists - oops! (#76)
Index:	etc/named/tools/nslookup/main.c 2.11BSD

Description:

	'nslookup' still thought 'sri-nic.arpa' was the "root" nameserver.
	(no sense of tradition these days i guess).

Repeat-By:
	Run 'nslookup'.

Fix:
	Apply the trivial patch below.

=================================cut here================================
*** /usr/src/etc/named/tools/nslookup/main.c.old	Thu Sep  8 02:17:37 1988
--- /usr/src/etc/named/tools/nslookup/main.c	Sun Aug 23 21:31:12 1992
***************
*** 67,73 ****
   * the "set root" command.
   */
  
! #define 	ROOT_SERVER "sri-nic.arpa."
  char 		rootServerName[NAME_LEN];
  
  
--- 67,73 ----
   * the "set root" command.
   */
  
! #define 	ROOT_SERVER "ns.nic.ddn.mil."
  char 		rootServerName[NAME_LEN];
  
  
Newsgroups: comp.bugs.2bsd
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: C compiler (/lib/c1) u_char improvement    (#77)
Organization: GTE Government Systems
Date: Wed, 2 Sep 92 20:52:46 GMT

Subject: C compiler (/lib/c1) u_char improvement   (#77)
Index:	lib/ccom/optable 2.11BSD

Description:
	The C compiler doesn't know it can use the same 'bitb' instructions
	for u_char as it can for char.  This results in extra instructions
	being generated to promote the u_char to int before doing a 'bit'.

	This type of construct occurs fairly frequently in the networking
	code because various flag fields are u_char in type.

Repeat-By:

	Compile the test program (using "cc -O -S"):

		char	*b;
		unsigned char *c;
	main()
		{
		if	((b[1] & 4) == 0)
			exit(2);
		if	((c[1] & 4) == 0)
			exit(1);
		}

	Note that the code reads:

	.comm	_b,2
	.comm	_c,2
	.globl	_main
	.text
_main:
~~main:
	jsr	r5,csv
	mov	_b,r0
	bitb	$4,1(r0)
	jne	L4
	mov	$2,(sp)
	jsr	pc,*$_exit
L4:	mov	_c,r0
	movb	1(r0),r0	/* XXX */
	bic	$!377,r0	/* XXX */
	bit	$4,r0
	jne	L3
	mov	$1,(sp)
	jsr	pc,*$_exit
L3:	jmp	cret
	.globl
	.data

  Instead of:

	.comm	_b,2
	.comm	_c,2
	.globl	_main
	.text
_main:
~~main:
	jsr	r5,csv
	mov	_b,r0
	bitb	$4,1(r0)
	jne	L4
	mov	$2,(sp)
	jsr	pc,*$_exit
L4:	mov	_c,r0
	bitb	$4,1(r0)
	jne	L3
	mov	$1,(sp)
	jsr	pc,*$_exit
L3:	jmp	cret
	.globl
	.data

Fix:
	Apply the patch below and reinstall 'c1'.
==============================cut here==============================
*** /usr/src/lib/ccom/optable.old	Wed Oct 23 07:02:57 1991
--- /usr/src/lib/ccom/optable	Tue Jul 28 09:35:00 1992
***************
*** 1839,1844 ****
--- 1839,1846 ----
  	IBE	R,A1
  
  %n*,a
+ %nu*,a
+ %nub*,a
  %	[move6]
  
  %n,a
From: bostic@VANGOGH.CS.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.98 (4.4BSD Contributed Software)
Date: 3 Sep 92 23:40:01 GMT
Distribution: world
Organization: University of California at Berkeley

Subject: 4.4BSD Contributed Software

As part of preparation for the final release of 4.4BSD, we are assembling
the user contributed software portions of the release.  If you have
previously contributed a software package for distribution with the 4BSD
releases, or you have a software package that you are willing to
contribute and that you believe would benefit the community of Berkeley
UNIX users, please contact me by email.

	Keith Bostic
	uunet!bostic
	bostic@vangogh.cs.berkeley.edu
From: loverso@osf.org (John Robert LoVerso)
Subject: -me macros: bug with chapter type
Organization: OSF Research Institute, Cambridge MA
Date: Mon, 31 Aug 1992 03:13:30 GMT

Index: misc net2

Description:
	If a paper has a ".++ P" section (numbered in roman numerals)
	followed by a ".++ C" section (numbered in digits, from 1),
	the page numbers will go "i, 2, 1, 2, ...".  This is because
	a ".pn 1" is used after the .++ macro ends the page.  This exists
	in all copies of tmac.e I've seen.  I'm working with the one
	from bnr2:
		tmac.e	2.35 (Berkeley) 4/17/91

Repeat-By:
	Use a paper like:
		.he ''%''
		.++ P
		(page i)
		.++ C
		(should be page 1, but is page 2)
		.bp
		(should be page 2, but is page 1)
		.bp
		(should be page 3, but is page 2)

Fix:
	Move the reset-of-page-number for when leaving a .++ P section
	to before the ".ep".

*** tmac.e.bnr2	Sun Aug 30 23:00:38 1992
--- tmac.e	Sun Aug 30 23:01:02 1992
***************
*** 997,1002 ****
--- 997,1004 ----
  .nr ch 0 1
  .if (\\n(_0=3):(\\n(_0=5) \
  .	pn 1			\" must do before .ep
+ .if !\\n(_0=\\n(_M .if \\n(_M=3 \
+ .	pn 1			\" must do before .ep
  .ep				\" end page for correct page number types
  .if \\n(_0=1 \
  \{\
***************
*** 1016,1023 ****
  .	af % 1
  .if \\n(.$>1 \
  .	he \\$2
- .if !\\n(_0=\\n(_M .if \\n(_M=3 \
- .	pn 1
  .nr _M \\n(_0
  .rr _0
  ..
--- 1018,1023 ----
Newsgroups: comp.bugs.4bsd
From: hart@cp4.cp.bell-atl.com (Rod Hart - Director Minicomputer Techn. Support)
Subject: need 386bsd on qic-80 tape
Organization: C & P Tel. Co. - Minicomputer Techn. Support Dist.
X-Newsreader: Tin 1.1 PL5
Date: Wed, 26 Aug 1992 00:02:19 GMT


Newsgroups: comp.realtime
From: dbander@netcom.com (David B. Andersen)
Subject: Re: VxWorks vs. pSOS
Date: Tue, 01 Sep 92 07:47:24 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Distribution: na

I have extensive experience using both pSOS and VxWorks, however not on the
same archetectures.  I have used pSOS on Intel X86 based systems, and VxWorks
on Moto 680X0 systems.

For me, there is no comparison.  VxWorks is way better, if your target has
enough resources (speed and memory mainly) to make its use feasible. The
development environment for VxWorks is very familiar to Unix developers,
whereas pSOS seems to have an MS-DOS based development heritage.

Networking works really well, both over Ethernets, serial links and back planes.

But the think I like best of all about VxWorks is the shell!  This is so useful
for testing and debugging that you will wonder how you ever got along
without it.  It puts pROBE (the pSOS debugger) to shame.

As far as tech support, Wind River is a pretty busy place.  It can take a few
days sometimes to get a question answered. When they do get back to you, they
are pretty thorough. The pSOS folks, Software Components Group, were also
helpful, but I really haven't had that many questions for them.

That's my two cents.

-- 
/------------------------------------------------------------------\
|     David B. Andersen             (dbander@netcom.com)           |
\------------------------------------------------------------------/
Newsgroups: comp.realtime
From: comore@arcetri.astro.it (Giovanni Comoretto)
Subject: Real time references required
Keywords: Realtime 0S, Posix
Organization: Arcetri Observatory, Florence, Italy
Date: Tue, 1 Sep 1992 15:59:48 GMT

(Probably it is a FAQ, but anyway)
Could anyone send me references about
1) the Posix standard, as it is now
2) general books about real time programming?
I have experience in standard programming, but I am just facing the
problems of controlling instruments in real time.
Thank you
Newsgroups: comp.realtime
From: faught@redfox.ssc.gov (Ed Faught)
Subject: Re: LynxOS diskless client possible?
Reply-To: faught@redfox.ssc.gov
Organization: Superconducting Super Collider Laboratory
Distribution: comp
Date: Fri, 28 Aug 1992 16:26:18 GMT

In article <MUTS.92Aug28115404@ruunfs.fys.ruu.nl> muts@fysap.fys.ruu.nl (Peter  
Mutsaers) writes:
>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,

Lynx has available a kit for ROMable kernel and diskless systems.
--
Ed Faught  WA9WDM  faught@psychosis.ssc.gov
 Superconducting Super Collider Laboratory
Newsgroups: comp.realtime
From: antonson@software.org (Todd S. Antonson)
Subject: Realtime OS
Followup-To: antonson@software.org
Summary: Realtime OS, Time measurement.
Keywords: Realtime OS, Sun, Ada
Organization: Software Productivity Consortium, Herndon, Virginia
Date: Mon, 31 Aug 1992 15:09:21 GMT


To The Net:

I have a user who is interested in the following:

He would like to perform experiments in realtime and would
like to have a realtime OS on a Sun workstation.  He is
going to be measuring timing and needs accurate results.

Does anybody have any suggestions for realtime OS on Sun?

Along with this requirement, he would like to hang multiple
interrupt driven devices off this machine and he would like
to be able to vary the interrupts.  He really only needs ports
on the machine, the actual devices are not know at this time.

If there is some realtime OS available, what Ada would be
used on that OS?

Along with all that info, what it the approximate cost of
this equipment?  We already have a sun workstation running
SunOS 4.1.1.

Thanks for any help you may offer.

--
=======================================================================
Todd S. Antonson                    |
Software Productivity Consortium    |UUCP : ..!uunet!software!antonson
SPC Building -- 2214 Rock Hill Road |CSNET: antonson@software.org
Herndon, Virginia 22070             |
=======================================================================
From: owensa@vnet.ibm.com (Alan B. Owens)
Date: Wed, 2 Sep 92 12:58:47 EDT
Newsgroups: comp.realtime
Subject: Re: Real time references required
Organization: IBM Federal Systems Company
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.0

In <1992Sep1.155948.2374@arcetri.astro.it> Giovanni Comoretto writes:
>(Probably it is a FAQ, but anyway)
>Could anyone send me references about
>1) the Posix standard, as it is now
POSIX_Programmer's_Guide
Donald Lewine
O'Reilly & Associates, Inc.
ISBN 0-937175-73-0
>2) general books about real time programming?
Real-Time_Systems_Design_and_Analysis
Phillip A. Laplante
IEEE Press/IEEE Computer Society Press
ISBN 0-7803-0402-0/ISBN 0-8186-3107-4

Alan B. Owens                                          Building 182, Room 3M101
Staff Programmer                                        800 N. Frederick Avenue
IBM Federal Systems Company                         Gaithersburg, Md 20879-3395
owensa@vnet.ibm.com                                                301-240-7191
Newsgroups: comp.realtime
From: loew1@seas.gwu.edu (Murray Loew)
Subject: Re: Where to stick the watchdog ?
Keywords: kernals watchdog 
Organization: George Washington University
Date: Thu, 3 Sep 1992 18:05:49 GMT

**** I AM NOT MURRY LOEW, DESPITE THE HEADER ***

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.
...
>
>Thoughts ? Observations ?
>
We had a long discussion about this a few weeks ago.  Our system is
kind of message based -- i.e. a bunch of tasks sit around on queues
waiting for either messages or timeouts. 

The kernel was priority based, so a task stuck in a loop would
block all the other tasks with lower priority.

Our conclusion was that you would have to have some code in place
to make sure that EVERY task got a chance to run within some
reasonable length of time.  I.E. there is some sort of flag that
each task sets when it goes through it's outermost q_receive() loop,
either because of a message or because the q_receive() timed out.
If any task stops updating this flag for a while, then something
is wrong and you might want to hit the panic buttom.

In our case, we may even extend this to multiple processor cards --
each card makes sure that each task is running, and some higher
entity makes sure that each card is ok.

-- cary o'brien
-- gte spacenet
-- c.obrien@gte.sprint.com

Newsgroups: comp.realtime
From: holtt@OCE.ORST.EDU (Tim Holt)
Subject: Is anyone using UCOS???
Organization: College of Oceanography, Oregon State Univ
Distribution: na
Date: Thu, 3 Sep 1992 16:49:02 GMT

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.

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

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
From: larry@socs.uts.edu.au (Larry Wilson )
Newsgroups: comp.realtime
Subject: Access to material on "Circuit Cellar" BBS
Date: 2 Sep 92 12:50:11 GMT
Organization: Computing Sciences, Uni of Technology, Sydney.

I am wanting to get material on the BBS for the "Computer Applications Journal"
the Circuit Cellar BBS. Can anyone advise of any way to get access to any of 
this material via the Net.
The only other way for me to access is to make an international phone call. 
This is expensive.

Any comments and help greatly appreciated.
Thank You in advance


Larry Wilson
larry@socs.uts.edu.au
Newsgroups: comp.realtime
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Token Ring
Organization: National University of Singapore
Date: Wed, 2 Sep 1992 08:19:36 GMT

Is a Token Ring very suitable for Real Time needs?

I have in mind something like 16 nodes each generating 9000 to 30000bits
per sec of realtime traffic (the data logging is very regular for each
node) and about  0 (minimum) to 500000 (peak) bits per sec of bursty non
realtime traffic.

What is your experience? In terms of fault tolerance, delay, general all
round performance.

What are the things I'd be able to tune in order to optimise the
network?

Thanks

jin meng
Newsgroups: comp.realtime