From daemon@vxw.ee.lbl.gov  Wed Sep  1 04:01:30 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep  1 04:01:40 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep  1 04:01:21 PDT 1993

        Subject: Re: I need a DMA driver for the MVME-167
        Subject: linked-list library (lstLib)
        Subject: Re: Using Lex/YACC in VxWorks
        Subject: rpcgen for vxWorks
        Subject: svcudp_create

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: I need a DMA driver for the MVME-167
Date: Tue, 31 Aug 1993 15:20:36 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Message-ID: <georg.746810436@sgl.ists.ca>
References: <9308302047.AA08591@igate1.hac.com>
Sender: news@newshub.ists.ca (News Subsystem)

strenn@igate1.hac.com (Stephen P. Strenn) writes:
> I'd like to find a DMA driver for the MVME-167.

I have a small set of routines to make DMA easy, but there's no actual
VxWorks "driver". Let me know if you (or anyone) are interested.

Attached are the prototypes.

Georg.

- ----------------------------------------------------------------

/* Initiate DMA */
int dma(long int src_addr, long int dest_addr, long int count, 
         bool tovme, bool incvme, bool noblock);

/* Initiate DMA & wait for it to finish */
int dma_wait(long int src_addr, long int dest_addr, long int count, 
             bool tovme, bool incvme, bool noblock);

/* Test if DMA is finished following dma() */
int dma_done(void);

/* Initiate DMA, call interrupt handler 'isr()' when done */
int dma_int(long int src_addr, long int dest_addr, long int count, 
            bool tovme, bool incvme, bool noblock, FUNCPTR isr);

/* clear interrupt request, to be called from isr() */
void dma_int_clear(void);
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: linked-list library (lstLib)
Date: Tue, 31 Aug 1993 14:35:17 GMT
From: curry@tc.fluke.COM (John Curry)
Organization: Fluke Corporation, Everett, WA
Message-ID: <CCMoIy.KM7@tc.fluke.COM>

Has anyone out there used the VxWorks linked-list library? And if so, would it
be possible to get some example code fragments on how to use the various calls?
The VxWorks manuals are rather skimp on how to use the library.

Thanks,

- ----------------------------------------------------------------------------
 John Curry                                       Fluke Corporation
 curry@tc.fluke.com                               6920 Seaway Blvd  m/s 178D
 206-356-5708                                     Everett, Wa. 98206 
- ----------------------------------------------------------------------------

- -- 
- ----------------------------------------------------------------------------
 John Curry                                       Fluke Corporation
 curry@tc.fluke.com                               6920 Seaway Blvd  m/s 178D
 206-356-5708                                     Everett, Wa. 98206 
- ----------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Using Lex/YACC in VxWorks
Date: Tue, 31 Aug 1993 21:48:32 GMT
From: winans@xray.aps.anl.gov (John R. Winans)
Organization: Argonne National Laboratory, Chicago Illinois
Message-ID: <CCn8Kx.9u@mcs.anl.gov>
References: <BRADLEY.93Aug19112407@gaia.den.mmc.com>
Sender: usenet@mcs.anl.gov

In article <BRADLEY.93Aug19112407@gaia.den.mmc.com> bradley@gaia.den.mmc.com (Jami Bradley) writes:
>We have been using Lex/YACC (actually FLex/Bison) to build a parser for our
>MV167 board.  We have run into a problem and any suggestions would be
>appreciated.
>
>These code generators depend on globals with initialization (done at *load*
>time).  When the parser is called, it works just fine, but if it is called a
>second time, those globals are not reset.  We could re-load, but that seems
>like a waste of time and memory, so how do you folks get around this cleanly?

I use the following function to do my bison parsing under vxWorks with 
bison 1.18 and it seems to to the trick:

int
#ifdef __STDC__
hctReadFile(char *fname)
#else
hctReadFile(fname)
char *fname;
#endif  /* __STDC__ */
{
  static int    firstTime = 1;
 
  if ((yyin = fopen(fname, "r")) == NULL)
  {
    printf("HCT: Can't open file %s\n", fname);
    return(0);
  }
  if (firstTime)
    firstTime = 0;
  else
    yyrestart(yyin);
 
  yyparse();
  fclose(yyin);
  return(0);
}

It does not concern me, but you might want to read the GNU license on bison.
It is s little different that the rest of the GNU stuff in that it very
clearly states that any and all components of a system that includes a "bison
grammar" must be placed into the public domain.

My little HCT project has hit the bit bucket about a year ago, but I doubt 
that the snipit above could have suffered from bit rot by now.  Good luck.

- --John

P.S.  You might also run into future problems with your code because vxWorks
      has a bunch of its parser's "yy" variables in global scope.  No biggie if
      you load in the right order, or pre-bind your .o files.
- -- 
! John Winans                     Advanced Photon Source  (Controls)    !
! winans@mcs.anl.gov              Argonne National Laboratory, Illinois !
!                                                                       !
!"The large print giveth, and the small print taketh away." - Tom Waits !

---------------------------

Newsgroups: comp.os.vxworks
Subject: rpcgen for vxWorks
Date: Wed, 1 Sep 93 02:02:58 GMT
From: mef@cs.washington.edu (Marc Fiuczynski)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Message-ID: <1993Sep1.020258.2527@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)

OK! RPCGEN on the sun is quite annoying. Where is the latest rpcgen
that people like to use for vxWorks.  I would like to go into the
source code and put in the proper stuff.  I guess the one thing that I
fixed an older version of rpcgen is the TIMEOUT to &TIMEOUT.

No biggy, since this could be fixed with a good sed scripts.  If
someone could send me a good sed script then I will abandon my effort
of building a vx_rpcgen.  

Sincerely,

Marc E. Fiuczynski

- -- 
/Marc...
mef@cs.washington.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: svcudp_create
Date: Wed, 1 Sep 93 01:58:37 GMT
From: mef@cs.washington.edu (Marc Fiuczynski)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Message-ID: <1993Sep1.015837.2374@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)

Is there a mistake with the prototype of svcudp_create() in rpc/svc.h?
Glancing at the sun rpc source code svcudp_create calls
svcudp_bufcreate() with a default buffer size.  However, the vxWorks
header files force me to pass something in. 

Is its behavior similar to the sun svcudp_create() or must I pass in
proper values.  If the latter is the case then what is the difference
between it and svcudp_bufcreate.

Thanks for the help.

Marc

- -- 
/Marc...
mef@cs.washington.edu

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Wed Sep  1 07:23:55 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Wed Sep  1 07:24:07 PDT 1993
Subject: DMA for NCR53C710
Greetings!

  Does anyone out there in netland have an example of SCSI DMA using
the on-board DMA controllers of the NCR53C710 such as used on the
Motorola 167 board?  Any samples and/or pointers would be most
appreciated.

Thanks,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                         Voice: (703) 448-0210 ext. 235
Director, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@mclean.sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

From sdarensb@milton.viasat.com  Wed Sep  1 09:05:49 1993
From: sdarensb@milton.viasat.com
Date: Wed Sep  1 09:05:59 PDT 1993
Subject: Building GNU C for Solaris 2.1

     I have the source for GNU C version 2.4.3, I am trying to install
it on a SPARC 2 running Solaris 2.1. When I try to install it, I get
an unknown assembler option error "y" and "x". The GNU manual says
not to use the linking and other tools in /usr/ucb. Instead, use
the tools in /usr/ccs/bin. There is no /usr/ccs/bin directory on 
my SPARC. I am using the cc compiler that came with our distribution
of Solaris. Is there any place where I can get an executable for GCC and
the libraries on the net. Any insight or help would be greatly 
appreciated. Thanks in advance, Shelton. 

From OWENS@lodtm.llnl.gov  Wed Sep  1 09:06:54 1993
From: OWENS@lodtm.llnl.gov
Date: Wed Sep  1 09:07:09 PDT 1993
Subject: ISR on MV167 solved!! (sort of)
Just in case anyone has an interest (no response to my previous post)
the problem with ISR's, vxWorks 5.1 and the 68040 has been found.
The details will follow, but the basic reason for the difficulties I
encountered is that the statement in the vxWorks Programmer's Guide

"Any C subroutine can be connected to an interrupt, a watchdog timer,
or an auxiliary timer."

is NOT true.

  This appears to be due to a feature in the version 2.2.3 GNU compiler
which I received with vxWorks 5.1.  Under certain conditions the code
generated is not compatible with use as an ISR which requires the
floating point processor.  For functions that use floating point the new
compiler generates instructions that the old compiler did not.

At the entry point the previous compiler generated:

   LINK.W   A6,#0
   ...
.....
......
   UNLK    A6

The new compiler generates:

   LINK.W    A6,#0
   FMOVEM.X  F2,-(A7)
   MOVE.L    D3,-(A7)
   MOVE.L    D2,-(A7)
   ....
   ....
   ....
   MOVE.L  (0xffec,A6),D2
   MOVE.L  (0xfff0,A6),D3
   FMOVEM.X (0xfff4,A6),F2
   UNLK    A6
   RTS

If this code is connected to an interrupt, it violates the rule that
the first FPU operation should be an FSAVE and this appears to be the
cause of my crashes.  Fortunately, if a function does not use floating
point math these extra instructions are not generated by the compiler
so the obvious workaround is.

void dummy()
  {
  fppSave(&saveArea);
  realroutine();
  fppRestore(&saveArea);
  return;
  }

void realroutine()
  {
  double x,y, z:
  z = x + y;
  ..
  ..
..

 return;
 }

Where dummy() is the routine connected to an interrupt and realroutine()
is the 'actual' ISR.  If there are people more knowledgable on the
compiler who know a more elegant approach I would love to hear it.

Doug Owens
Lawrence Livermore National Lab

From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com  Wed Sep  1 18:16:12 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Wed Sep  1 18:16:32 PDT 1993
Subject: Moving to 5.1 application note

                      APPLICATION NOTE
            Moving Applications onto VxWorks 5.1

                      Leonid Rosenboim

            RST Software Industries Ltd. Israel.

                          ABSTRACT

          This memo summarizes our experience  of  sup-
     porting  users  to  port  their  applications from
     VxWorks 5.0.x to 5.1. Common problems  are  listed
     and  their recommended solution. This memo will be
     updated with additional problems we encounter.

Compiler issues

One of the most significant changes in VxWorks  5.1  is  the
use  of  a  new compiler which is completely ANSI compliant,
and modification of all include files for  ANSI  compatibil-
ity.  It is recommended that with this new compiler the code
should be compiled in ANSI  mode.  That  however  may  cause
great difficulties - the application may require significant
modifications if it has not been written to be ANSI  compli-
ant.

We strongly recommend to invest  that  effort  in  order  to
obtain  a  cleaner  code  and avoid certain run-times errors
which are detected by the compiler.  On the other  hand,  if
time  is critical, use of the -traditional flag under 5.1 is
the short-term solution.

If the code was already written according to ANSI specifica-
tions,  the  compilation  errors  under 5.1 will be few, and
should be examined carefully, since some functions under 5.1
have  new interfaces.  Some of these functions are discussed
below.

VMEbus and the MMU

From the functional stand-point, probably the  most  radical
change in 5.1 is the use of the MMU on some processors. Even
without the optional VxVMI module, VxWorks 5.1 makes use  of
the  Memory  Management  Unit  to define Virtual-to-Physical
address translation maps.  The BSP file sysLib.c defines the
initial  translation  map,  and the option INCLUDE_MMU_BASIC
enables its use by the MMU support library.

Mostly the MMU does not cause any trouble, with  the  excep-
tion  of  applications  that use VMEbus extended space (e.g.
A32). In 5.1, if INCLUDE_MMU_BASIC is defined, only  a  part
of that A32 VME space is available to the processor.

If a BUS ERROR is experienced when attempting  access  to  a
VME  A32 device after moving to 5.1, the MMU is probably the
cause, and there are three possible solutions to this  prob-
lem, which are:

(1)  Comment out the line which defines INCLUDE_MMU_BASIC in
     the file config.h in the BSP directory, thus completely
     disabling the MMU and restoring  5.0.x  behavior.  This
     has  a  significant  drawback,  without this option the
     application will not be able to use Data Cache.  Still,
     this  is  worth  a try just to figure the source of the
     problem.

(2)  Examine the initialization of sysPhysMemDesc  array  in
     sysLib.c  to figure how much VME A32 space was actually
     mapped, and where are its boundaries. This  space  will
     usually  start  at  sysMemTop(),  and  will be 16 or 32
     MBytes in size.  If at all possible, the VME board base
     address  should  be  changed  so  it  will fit into the
     defined mapping, while not overlapping with  any  other
     card  installed.   If  that is not possible because the
     card's address space is just too large, or if there are
     many cards, the last option should be considered.

(3)  Modify the initialization of sysPhysMemDesc is sysLib.c
     to  enlarge  the  mapped  space size. It is practically
     safe to have each entry in  the  table  map  up  to  32
     MBytes  of space. If more space is still required, more
     entries may be added. The practical limit on the number
     of entries depends on the particular processor and MMU.

VxWorks backward compatibility options

VxWorks 5.1 is not completely, but is "mostly" compatible to
the  previous  versions 5.0.x.  There are a number of confi-
guration options that may be defined in configAll.h  to  add
some  code  to  VxWorks  to make 5.1 more compatible.  These
options are:

INCLUDE_DELETE_5_0
     The  5.0.x  delete()  function  has  been  renamed   to
     remove()  and unlink() in 5.1 for the sake of POSIX and
     ANSI compatibility.  Defining  this  options  adds  the
     delete()  function  as  an  alias. This can not be used
     with C++ support.

INCLUDE_ANSI_5_0
     This option makes sure that the  same  ANSI  C  library
     functions  that  where available on 5.0.x are included.
     defining INCLUDE_ANSI_ALL brings in much more of  these
     functions,  and  makes  INCLUDE_ANSI_5_0 obsolete. Thus
     where memory is limited, this option brings in  only  a
     subset  of  ANSI  library that was in the previous ver-
     sion.

INCLUDE_BP_5_0
     VxWOrks 5.1 offers a completely new mechanism  of  com-
     munication  across  the VME backplane. The new stuff is
     included using INCLUDE_SM_NET, but if old boot ROMs are
     still  in use, or if you have a SunOS Back-Plane driver
     running on one of the boards, you're stock with the old
     driver which is enabled using this option.

Source Compatibility

However unfortunate it may seem, few functions have  changed
their  calling  prototype  in  5.1,  while keeping their old
names.  If the "-ansi" and "-pedantic" compiler options  are
used, these differences will come out clear by the compiler.
For those stock with "-traditional", these may pose  serious
problems.   In  some  cases adding a simple type cast should
suffice, or the difference may be ignored  altogether,  e.g.
when  an  argument  that  used  to be "int" is now "unsigned
int", and similar differences.

Here are a few functions that we feel require special atten-
tion:

-    The ld() function if  used  programmatically  has  com-
     pletely  changed  its  return  value,  now  instead  of
     returning 0 when OK, it returns a pointer, and  a  zero
     (NULL)  is  returned  on  error.   Usage  of  ld() from
     scripts is not affected by that.

-    Functions logMsg() and taskSpawn()  now  have  a  fixed
     number of arguments instead of variable number of argu-
     ments, namely, logMsg() is now limited to 6  arguments,
     and taskSpawn() to 10. Any call to either function with
     more arguments than allowed  will  get  you  unexpected
     results.

Please refer to VxWOrks 5.1 Release  Notes  document  for  a
complete list of changed functions.

Binary compatibility

For reasons too many to mention it is recommended  that  the
entire  application be recompiled with the compiler supplied
with 5.1, and using the new include files. However, that may
be  not possible in some cases, hence are some tips on where
this might not work.

Modules using macros from ctype.h (e.g. isalpha(), isdigit()
etc.)  will  fail  to  load  on  5.1. Such modules should be
recompiled.

Modules using the macros defined in stdioLib.h of the previ-
ous  version must be recompiled with the 5.1 version of this
include file.  So are any modules that depend on the  inter-
nal  structure  or  size  of  typedef FILE. It has been com-
pletely changed.   Luckily  stdioLib  has  only  two  macros
getc() and putc()defined, and are used rarely.

In light of the previous section, modules that use ld(),  or
have  more  than  the maximum allowed number of arguments to
logMsg() or taskSpawn() will also fail binary compatibility.
It is also worth noting that in many occasions binary compa-
tibility does work.

Development Environment

The most important of the development environment  that  has
changed  is  the  way the on-line manual pages are used, now
instead of using the vwman script, the manual is designed to
use  the  standard  UNIX "man" utility. This is definitely a
change for good, however if you just can't live without  the
good  old  "vwman",  the following statement can be added to
your .cshrc to fix it:

        alias vwman "man -P $VX_VW_BASE/man"

-----------------------------------------------------------------------
Leonid Rosenboim                           Voice/Fax: +972-3-72-44-98
R S T  Software Industries Ltd.            E-Mail: leonid@RST.HellNet.Org
P.O.Box 8077, Ramat-Gan 52180, Israel      WRS Distributor

From daemon@vxw.ee.lbl.gov  Thu Sep  2 04:01:31 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep  2 04:01:45 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep  2 04:01:21 PDT 1993

        Subject: Re: Building GNU C for Solaris 2.1
        Subject: Re: ISR on MV167 solved!! (sort of)
        Subject: enpattach on vx5.1
        Subject: Speaking of DMA... 

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Building GNU C for Solaris 2.1
Date: Wed, 1 Sep 93 16:49:02 GMT
From: young@mars.dgrc.doc.ca (Norm Young)
Organization: Communication Research Centre
Message-ID: <1993Sep1.164902.28897@clark.dgim.doc.ca>
References: <9308017468.AA746897002@milton.viasat.com>
Reply-To: young@mars.dgrc.doc.ca
Sender: news@clark.dgim.doc.ca (#Usenet News)

In article AA746897002@milton.viasat.com, sdarensb@milton.viasat.com writes:
> 
>      I have the source for GNU C version 2.4.3, I am trying to install
> it on a SPARC 2 running Solaris 2.1. When I try to install it, I get
> an unknown assembler option error "y" and "x". The GNU manual says
> not to use the linking and other tools in /usr/ucb. Instead, use
> the tools in /usr/ccs/bin. There is no /usr/ccs/bin directory on 
> my SPARC. I am using the cc compiler that came with our distribution
> of Solaris. Is there any place where I can get an executable for GCC and
> the libraries on the net. Any insight or help would be greatly 
> appreciated. Thanks in advance, Shelton. 

We would also be interested in gcc executables for SPARC 2 or SPARC 10
and Solaris 2.1.

- ---
Norm Young       |  DoD #0770            |  E-Mail: norm.young@crc.doc.ca    
Communications   |  Tel: 1-613-990-8779  |  Fax: 1-613-990-7987
Research Centre  | 
Ottawa, Ontario  |                 Ignore this .sig

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: ISR on MV167 solved!! (sort of)
Date: 1 Sep 1993 20:06:26 GMT
From: billr@saab.CNA.TEK.COM (Bill Randle;923-4422)
Organization: Tektronix, Inc., Redmond, OR
Message-ID: <262vc2$hu@ying.cna.tek.com>
References: <01H2FF053LB6AW4LCZ@icdc.llnl.gov>
Reply-To: billr@saab.CNA.TEK.COM

In article <01H2FF053LB6AW4LCZ@icdc.llnl.gov>, OWENS@lodtm.llnl.gov writes:
|> ...the problem with ISR's, vxWorks 5.1 and the 68040 has been found.
|> The details will follow, but the basic reason for the difficulties I
|> encountered is that the statement in the vxWorks Programmer's Guide
|> 
|> "Any C subroutine can be connected to an interrupt, a watchdog timer,
|> or an auxiliary timer."
|> 
|> is NOT true.

In fact, later in that same section of the Programmer's Manual (sec 3.4.3
to be exact), they explicity state that "ISRs must not include floating-
point instructions". They then go on to say, however, that if your ISR
requires floating point, then you must do the fppSave()/fppRestore()
explicitly.

- -- 
	-Bill Randle
	Tektronix, Inc.
	billr@saab.CNA.TEK.COM

---------------------------

Newsgroups: comp.os.vxworks
Subject: enpattach on vx5.1
Date: Wed, 1 Sep 1993 23:22:50 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <1993Sep1.232250.10320@ncar.ucar.edu>
Sender: news@ncar.ucar.edu (USENET Maintenance)

I've sent this as a bug report to Wind River, but I thought I'd ask on the net as
well:

I'm trying to use 2 CMC Ethernet ENP-10 cards under VxWorks 5.1 (using an MVME133)

Under vx5.02, I could initialize a 2nd ethernet card using the following:
    if (sysBusToLocalAdrs(VME_AM_STD_SUP_DATA , IO_ADRS_ENP1,
        &lclAddr) == ERROR)
    {
        logMsg("can't get address for ENP1\n");
        return(ERROR);
    }

    status = enpattach (1, lclAddr, INT_VEC_ENP1, INT_LVL_ENP1);
    if (status != OK)
        {
        logMsg ("failed: status = 0x%x.\n", errnoGet ());
        return (ERROR);
        }

Under Vx5.1, enpattach returns ERROR, with errnoGet returning 0xe.
With the same hardware configuration, I can run with vx5.02, and enpattach
suceeeds.  Under Vx5.1, it fails.

Is anyone else using 2 Ethernet cards, and does anyone know if the
parameters to enpattach() have changed? there aren't any prototypes for the
function that I could find.

Thanks much.

- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	National Center for Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: Speaking of DMA... 
Date: Wed, 1 Sep 93 16:45:43 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1993Sep1.164543.2777@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --
Anyone have any examples of DMA on the VIC chip?

- -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Fri Sep  3 04:01:31 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Sep  3 04:01:46 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Sep  3 04:01:21 PDT 1993

        Subject: Re: Moving to 5.1 application note
        Subject: VME "easy DMA" routines for 167
        Subject: Re: Moving to 5.1 application note
        Subject: Help needed
        Subject: FAQ monthly reminder
        Subject: Porting CLIPS to vxWorks5.0.2b

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Moving to 5.1 application note
Date: Thu, 2 Sep 1993 11:57:03 GMT
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1993Sep2.115703.25057@bnlux1.bnl.gov>
References: <9309011413.AA00624@RST.HellNet.org>

In article <9309011413.AA00624@RST.HellNet.org> leonid@rst.hellnet.org (Leonid Rosenboim) writes:
>                          ABSTRACT
>
>          This memo summarizes our experience  of  sup-
>     porting  users  to  port  their  applications from
>     VxWorks 5.0.x to 5.1. Common problems  are  listed
>     and  their recommended solution. This memo will be
>     updated with additional problems we encounter.

>VMEbus and the MMU
>
>From the functional stand-point, probably the  most  radical
>change in 5.1 is the use of the MMU on some processors. Even
>without the optional VxVMI module, VxWorks 5.1 makes use  of
>the  Memory  Management  Unit  to define Virtual-to-Physical
>address translation maps.  The BSP file sysLib.c defines the
>initial  translation  map,  and the option INCLUDE_MMU_BASIC
>enables its use by the MMU support library.
>

	We found an additional 'problem' with the MMU support
on a MVME162. The BSP designates the FLASH as non-writeable.
That's fine, except when you want to re-program it!

	IMHO, the BASIC MMU support for A32 VMEbus is a little
weak. The whole addressable space *should* be available. Can
this be done (in general) (by WRS)? 
- -- 

     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_   

---------------------------

Newsgroups: comp.os.vxworks
Subject: VME "easy DMA" routines for 167
Date: Thu, 2 Sep 1993 15:42:48 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Keywords: 167 DMA
Message-ID: <georg.746984568@sgl.ists.ca>
Sender: news@newshub.ists.ca (News Subsystem)

After receiving a number of requests for my DMA routines I decided to
post them here instead of mailing to each person who requested.
I'll probably put them in the archives after some time for user feedback
has gone by.

These routines are for DMA between local bus memory and VME memory or
devices on the MVME167. 

Good luck,

Georg.

- ----------------------------------------
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  dma.c dma.h mem.h
# Wrapped by georg@sgl.ists.ca on Thu Sep  2 11:47:22 1993
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'dma.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'dma.c'\"
else
echo shar: Extracting \"'dma.c'\" \(10218 characters\)
sed "s/^X//" >'dma.c' <<'END_OF_FILE'
X/*
X * dma.c
X *
X * Written by Georg Feil.
X *
X * Routines to perform DMA transfers using VMECHIP2.
X * You may need to change things such as bus access types and interrupt 
X * priorities to conform to your environment. Currently set up to give
X * single-transfer bus accesses priority, i.e. "background" DMA.
X */
X
X#include <vxWorks.h>
X#include <stdio.h>
X#include <taskLib.h>
X#include <intLib.h>
X#include <iv.h>        /* for interrupt vector macros INUM_TO_IVEC etc. */
X/** the following is CPU-dependent (needed for VMECHIP2_BASE_ADRS) **/
X#include <../config/mv167/mv167.h>
X#include <drv/vme/vmechip2.h>
X#include <vme.h>
X
X#include "mem.h"
X#include "dma.h"
X
X/*
X * Global variables local to this module (static).
X */
XLOCAL int never_dma = TRUE;   /* TRUE if never performed DMA, 0 otherwise. Used
X                                   by dma_done(). */
X
Xvoid dma_init(void)
X/*
X * Configure those DMAC registers which only need to be set once.
X */
X{
X   /* set DMAC on and off times (not currently used since we use DMACR1_BRX
X        to release only on other bus requests) */
X   M_L(VMECHIP2_TIMEOUTCR) = (M_L(VMECHIP2_TIMEOUTCR) & 0xff03ffff)
X                               | TIMEOUTCR_ON_DONE | TIMEOUTCR_OFF_0US;
X
X   /* set DMA controller done interrupt level to 6. Already configured to
X        use base vector 0x50 (actual vector 0x56) by VxWorks init. */
X   M_L(VMECHIP2_ILR2) = (M_L(VMECHIP2_ILR2) & 0xf8ffffff)
X                          | ILR2_DMA_LEVEL6;
X}
X
Xint dma(long int src_addr, long int dest_addr, long int count, 
X         bool tovme, bool incvme, bool noblock)
X/*
X * Initiate a DMA transfer between the local bus and the VME bus, in either
X * direction. Returns immediately, use dma_status() to test completion.
X * 'src_addr' is the start address to copy from. It should be a VME 
X *            address if 'tovme' is FALSE, otherwise it must be a local bus
X *            address that does not map to the VME bus. VME addresses in the
X *            range 0xf0000000 to 0xf0ffffff are mapped to the A24 address 
X *            space, else uses A32. All addresses must be long-word aligned.
X * 'dest_addr' is the destination address to copy to. It should be a VME
X *             address if 'tovme' is TRUE, otherwise it must be a local bus
X *             address that does not map to the VME bus. VME addresses in the
X *             range 0xf0000000 to 0xf0ffffff are mapped to the A24 address 
X *             space, else uses A32. All addresses must be long-word aligned.
X * 'count' is the number of bytes to copy. Must be a multiple of 4.
X * 'tovme' TRUE means copy from local bus to VME bus, else copy from VME bus
X *         to local bus.
X * 'incvme' TRUE means increment the VME address, else don't.
X * 'noblock' TRUE means don't use block transfer mode (normally does).
X * Return value is error code.
X */
X{
X   int am;               /* address modifier code to use */
X   long int vmeaddr;     /* VME start address */
X
X   if (dma_done()==0)
X      return(ERROR);    /* vmechip2 DMA operation already in progress */
X
X   /* do some munging on the VME bus address, 0xf0000000 - 0xf0ffffff indicates
X        A24 (STD) address space, else A32 (EXT) */
X   vmeaddr = (tovme ? dest_addr : src_addr);
X   if (vmeaddr>=0xf0000000 && vmeaddr<=0xf0ffffff)  {
X      am=DMACR2_AM_STD_USR_DATA;
X      vmeaddr &= 0x00ffffff;
X   }
X   else  {
X      am=DMACR2_AM_EXT_USR_DATA;
X   }
X   /* initialize VME bus address counter */
X   M_L(VMECHIP2_DMACVAC) = vmeaddr;
X   
X   /* initialize local bus address counter */
X   M_L(VMECHIP2_DMACLBAC) = (tovme ? src_addr : dest_addr);
X   
X   /* initialize VME bus byte counter */
X   M_L(VMECHIP2_DMACBC) = count;
X   
X   /* DMA CR2: Use A24 or A32 usr data addr mod, D32 block xfer, always 
X        increment local bus address, optionally increment VME bus address */
X   M_L(VMECHIP2_DMACR2) = (M_L(VMECHIP2_DMACR2) & 0xffff0000)
X                            | am | (noblock ? 0 : DMACR2_D32_BLOCK)
X                            | DMACR2_D32 | (tovme ? DMACR2_TO_VME : 0)
X                            | DMACR2_LINC | (incvme ? DMACR2_VINC : 0);
X
X   /* DMA CR1: Use VMEbus request level 1, release on BR, non-fair, direct mode,
X        and start (enable) DMA transfer. Note: the single-transfer bus requester
X        is programmed for request level 3, and we release the DMAC requester on
X        other bus requests so that single-transfer bus requests can get on the
X        VME bus quickly. */
X   M_L(VMECHIP2_DMACR1) = (M_L(VMECHIP2_DMACR1) & 0xffffff00)
X                            | DMACR1_DREQ_L1 | DMACR1_BRX | DMACR1_DEN;
X
X   never_dma=FALSE;
X
X   return(OK);
X}
X
Xint dma_done(void)
X/* 
X * Tests for completion of DMA transfer started by dma().
X * This uses the 'never_dma' flag to make the return value valid even
X * before the first DMA, i.e. otherwise would show 0 (DMA in progress).
X * Return value of 0 indicates DMA not done (in progress).
X * Return value of 1 indicates DMA completed without errors.
X * Any other return value indicates error code as per bits 1 through 6 of
X * DMAC status register VMECHIP2_ICR (e.g. bus error).
X */
X{
X   if (never_dma)
X      return(1);
X
X   return(M_L(VMECHIP2_ICR) & 0x7f);
X}
X
Xint dma_wait(long int src_addr, long int dest_addr, long int count, 
X             bool tovme, bool incvme, bool noblock)
X/*
X * Like dma() but waits until completion.
X * Return value is OK if DMA completed OK, or >1 to indicate error as
X * per bits 1 through 6 of DMAC status register VMECHIP2_ICR (e.g. bus error),
X * or ERROR to indicate internal error code.
X */
X{
X   int err;
X
X   err=dma(src_addr,dest_addr,count,tovme,incvme,noblock);
X   if (err!=OK)
X      return(err);
X
X   while ((err=dma_done())==0)  {
X      taskDelay(1);
X   }
X
X   if (err!=1)
X      return(err);
X
X   return(OK);
X}
X
Xint dma_int(long int src_addr, long int dest_addr, long int count, 
X         bool tovme, bool incvme, bool noblock, FUNCPTR isr)
X/*
X * Initiate a DMA transfer between the local bus and the VME bus, in either
X * direction. This function returns immediately -- when the DMA is complete
X * an interrupt will be generated to the service routine 'isr'. That
X * routine must call dma_int_clear() to clear the interrupt request.
X * The function pointer passed for 'isr' should be the result of an
X * intHandlerCreate() call, i.e. we don't call intHandlerCreate() in this
X * routine because it would cause a memory leak (also doesn't seem to work
X * at interrupt level).
X * 
X * 'src_addr' is the start address to copy from. It should be a VME 
X *            address if 'tovme' is FALSE, otherwise it must be a local bus
X *            address that does not map to the VME bus. VME addresses in the
X *            range 0xf0000000 to 0xf0ffffff are mapped to the A24 address 
X *            space, else uses A32. All addresses must be long-word aligned.
X * 'dest_addr' is the destination address to copy to. It should be a VME
X *             address if 'tovme' is TRUE, otherwise it must be a local bus
X *             address that does not map to the VME bus. VME addresses in the
X *             range 0xf0000000 to 0xf0ffffff are mapped to the A24 address 
X *             space, else uses A32. All addresses must be long-word aligned.
X * 'count' is the number of bytes to copy. Must be a multiple of 4.
X * 'tovme' TRUE means copy from local bus to VME bus, else copy from VME bus
X *         to local bus.
X * 'incvme' TRUE means increment the VME address, else don't.
X * 'noblock' TRUE means don't use block transfer mode (normally does).
X * 'isr' is the interrupt service routine to call when the DMA is complete.
X *       This should be the result of a previous intHandlerCreate() call.
X * Return value is error code.
X */
X{
X   int am;               /* address modifier code to use */
X   long int vmeaddr;     /* VME start address */
X   static long int cmdtbl[5];   /* command table for DMAC */
X
X
X   if (dma_done()==0)
X      return(ERROR);    /* vmechip2 DMA operation already in progress */
X
X   /* do some munging on the VME bus address, 0xf0000000 - 0xf0ffffff indicates
X        A24 (STD) address space, else A32 (EXT) */
X   vmeaddr = (tovme ? dest_addr : src_addr);
X   if (vmeaddr>=0xf0000000 && vmeaddr<=0xf0ffffff)  {
X      am=DMACR2_AM_STD_USR_DATA;
X      vmeaddr &= 0x00ffffff;
X   }
X   else  {
X      am=DMACR2_AM_EXT_USR_DATA;
X   }
X   /* initialize VME bus address counter */
X   cmdtbl[2] = vmeaddr;
X   
X   /* initialize local bus address counter */
X   cmdtbl[1] = (tovme ? src_addr : dest_addr);
X   
X   /* initialize VME bus byte counter */
X   cmdtbl[3] = count;
X   
X   /* DMA CR2: Use A24 or A32 usr data addr mod, D32 block xfer, always 
X        increment local bus address, optionally increment VME bus address,
X        interrupt when DMA command done */
X   cmdtbl[0] = am | (noblock ? 0 : DMACR2_D32_BLOCK)
X                  | DMACR2_D32 | (tovme ? DMACR2_TO_VME : 0)
X                  | DMACR2_LINC | (incvme ? DMACR2_VINC : 0)
X                  | DMACR2_INTE;
X
X   /* fill 'next' table address with stop flag (only one entry in chain) */
X   cmdtbl[4] = 0x03;
X
X   /* initialize table address counter */ 
X   M_L(VMECHIP2_TAC) = (long int)cmdtbl;
X
X   /* set interrupt vector to point at service routine (must already be set up
X        as ISR, i.e. 'isr' should be the result of a intHandlerCreate() call. */
X   intVecSet((FUNCPTR*)INUM_TO_IVEC(UTIL_INT_VEC_BASE0+0x06),isr);
X
X   /* clear & enable the DMA-done interrupt */
X   M_L(VMECHIP2_ICLR) = ICLR_CDMA;
X   M_L(VMECHIP2_LBIER) |= LBIER_EDMA;
X
X   /* DMA CR1: Use VMEbus request level 1, release on BR, non-fair, command
X        chaining mode (TBL), and start (enable) DMA transfer.
X        Note: the single-transfer bus requester is programmed for request level
X        3, and we release the DMAC requester on other bus requests so that
X        single-transfer bus requests can get on the VME bus quickly. */
X   M_L(VMECHIP2_DMACR1) = (M_L(VMECHIP2_DMACR1) & 0xffffff00)
X                            | DMACR1_DREQ_L1 | DMACR1_BRX
X                            | DMACR1_DTBL | DMACR1_DEN;
X
X   never_dma=FALSE;
X
X   return(OK);
X}
X
Xvoid dma_int_clear(void)
X/*
X * Clear the DMA-done interrupt request, must be called by interrupt handler
X * (function passed as last parameter to dma_int(), above). 
X */
X{
X   M_L(VMECHIP2_ICLR) = ICLR_CDMA;
X}
END_OF_FILE
if test 10218 -ne `wc -c <'dma.c'`; then
    echo shar: \"'dma.c'\" unpacked with wrong size!
fi
# end of 'dma.c'
fi
if test -f 'dma.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'dma.h'\"
else
echo shar: Extracting \"'dma.h'\" \(597 characters\)
sed "s/^X//" >'dma.h' <<'END_OF_FILE'
X/*
X * dma.h
X *
X * Written by Georg Feil.
X * Header file for dma.c.
X */
X
X#ifndef DMA_DEFH
X#define DMA_DEFH
X
X
X/*
X * Function prototypes
X */
X
Xvoid dma_init(void);
X
X
Xint dma(long int src_addr, long int dest_addr, long int count, 
X         bool tovme, bool incvme, bool noblock);
X
Xint dma_wait(long int src_addr, long int dest_addr, long int count, 
X             bool tovme, bool incvme, bool noblock);
X
Xint dma_done(void);
X
X
Xint dma_int(long int src_addr, long int dest_addr, long int count, 
X         bool tovme, bool incvme, bool noblock, FUNCPTR isr);
X
Xvoid dma_int_clear(void);
X
X
X#endif !DMA_DEFH
END_OF_FILE
if test 597 -ne `wc -c <'dma.h'`; then
    echo shar: \"'dma.h'\" unpacked with wrong size!
fi
# end of 'dma.h'
fi
if test -f 'mem.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'mem.h'\"
else
echo shar: Extracting \"'mem.h'\" \(603 characters\)
sed "s/^X//" >'mem.h' <<'END_OF_FILE'
X#ifndef MEM_DEFD
X#define MEM_DEFD
X
X/*
X * Macros for direct access to memory addresses, in units of bytes, words, 
X * or long words.
X */
X
X#define M_B(n) (*(volatile unsigned char*)(n))
X#define M_UB(n) (*(volatile unsigned char*)(n))
X#define M_SB(n) (*(volatile signed char*)(n))
X
X#define M_W(n) (*(volatile signed short int*)(n))
X#define M_UW(n) (*(volatile unsigned short int*)(n))
X#define M_SW(n) (*(volatile signed short int*)(n))
X
X#define M_L(n) (*(volatile signed long int*)(n))
X#define M_UL(n) (*(volatile unsigned long int*)(n))
X#define M_SL(n) (*(volatile signed long int*)(n))
X
X
X#endif MEM_DEFD
END_OF_FILE
if test 603 -ne `wc -c <'mem.h'`; then
    echo shar: \"'mem.h'\" unpacked with wrong size!
fi
# end of 'mem.h'
fi
echo shar: End of shell archive.
exit 0
- -- 
Georg Feil
Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Moving to 5.1 application note
Date: Thu, 2 Sep 93 18:57:58 GMT
From: mcdowell@exlog.com (Steve McDowell)
Organization: Baker Hughes INTEQ, Inc.
Message-ID: <1993Sep2.185758.15983@exlog.com>
References: <9309011413.AA00624@RST.HellNet.org> <1993Sep2.115703.25057@bnlux1.bnl.gov>

In message <1993Sep2.115703.25057@bnlux1.bnl.gov>hoff@bnlux1.bnl.gov (Lawrence T. Hoff) writes:
>
> We found an additional 'problem' with the MMU support
> on a MVME162. The BSP designates the FLASH as non-writeable.
> That's fine, except when you want to re-program it!
> 
>	IMHO, the BASIC MMU support for A32 VMEbus is a little
> weak. The whole addressable space *should* be available. Can
> this be done (in general) (by WRS)? 

Since we're talking about the MV162, don't forget that the BSP
has all of the pages that map A32/D32 VME space marked as 
cachable, which wreaks havoc when doing simple things like 
looking for a change in a shared semaphore with another VME
processor. 

- -- 
Opinions are mine, not my employers

---------------------------

Newsgroups: comp.os.vxworks
Subject: Help needed
Date: 2 Sep 1993 19:02:01 GMT
From: dhkim@helios.ece.arizona.edu (Doo-Hwan Kim)
Organization: U of Arizona Electrical and Computer Engineeering
Message-ID: <265fv9$m16@zippy.Telcom.Arizona.EDU>

Dear netters;

I am new to VxWorks and interested in getting information about 
its functionalities and charateristics. 
I would appreciate any pointer to literature work or ftp site.
Please, send me e-mail. 

Best Regards, 

Doo-Hwan Kim
e-mail : dhkim@helios.ece.arizona.edu                  ph #: (602) 621-6184
Dept of Electrical and Computer Engineering           fax #: (602) 621-8076
University of Arizona
Tucson,     AZ   85721

---------------------------

Newsgroups: comp.os.vxworks
Subject: FAQ monthly reminder
Date: Thu, 2 Sep 1993 20:53:28 GMT
From: hjb@netcom.com (hwajin bae)
Organization: peaceful star, oakland, ca - vox: 510.536.7607 page: 510.466.9166
Message-ID: <hjbCCqvD5.FI0@netcom.com>

you can find a copy of unofficial FAQ for VxWorks in,

	netcom.com:~ftp/pub/hjb/vxfaq

there's a README file there that tells you what's available.
if you dont have access to anonymous ftp drop me a note and i'll email
you a copy.

love
hwajin
- -- 
Hwajin Bae (hjb@netcom.com)
Peaceful Star Consulting, Oakland, CA	(vox) 510.536.7607  (page) 510.466.9166

---------------------------

Newsgroups: comp.os.vxworks
Subject: Porting CLIPS to vxWorks5.0.2b
Date: Thu, 2 Sep 1993 21:34:38 GMT
From: juiyao@rvl2.ecn.purdue.edu (Juiyao Pan)
Organization: Purdue University Engineering Computer Network
Message-ID: <CCqx9s.70t@noose.ecn.purdue.edu>
Sender: news@noose.ecn.purdue.edu (USENET news)

    In our lab, we are trying to port CLIPS5.1 to vxWorks5.0.2b . Our target 
board is MVME167 with 32M byte memory. CLIPS (C Language Integrated with 
Production System) was developed by NASA. Does anyone have this experience
or have any sense about how to do it. Please give us some message if you can
help us in some way, we will greatly appreciate it. Thanks.

- -- Juiyao 

- ----------------------------------------------------------------------------
Juiyao Pan                      Robot Vision Laboratory
juiyao@ecn.purdue.edu           Room 180  EE Building
Tel: (317) 49-43456             W. Lafayette IN 47906

---------------------------

End of New-News digest
**********************

From mclark@sadira.gb.nrao.edu  Fri Sep  3 06:08:41 1993
From: mclark@sadira.gb.nrao.edu (MARK H. CLARK)
Date: Fri Sep  3 06:08:50 PDT 1993
Subject: Re: comp.os.vxworks newsdigest

Please remove me from the exploder.

		Thank you,

				Mark H. Clark
				mclark@nrao.edu
				National Radio Astronomy Observatory
				P.O. Box 2
				Green Bank, WV 24944-0002
				(304) 456-2206

From ulf@digitailor.se  Fri Sep  3 06:26:12 1993
From: ulf@digitailor.se (Ulf Tennander)
Date: Fri Sep  3 06:26:21 PDT 1993
Subject: MVME-162 IP-modules
Greetings,

I'm looking for VxWorks drivers (supported or unsupported) for two IP-modules
from Green Springs for the MVME-162, namely Octal Serial I/O and GPIB. Also, 
if you know of drivers for other IP-modules, plesae let me know.

  Thanks,

  Ulf

  o==================================================================o
  |  Ulf Tennander                           ulf@digitailor.se       |
  o==================================================================o
  |  Digitailor AB                           phone: +46-8 744 53 00  |
  |  A Microtec Research Company             fax:   +46-8 645 53 36  |
  o==================================================================o

From daemon@vxw.ee.lbl.gov  Sat Sep  4 04:01:33 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep  4 04:01:43 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep  4 04:01:21 PDT 1993

        Subject: Re: BSD File System
        Subject: Re: I need a DMA driver for the MVME-167
        Subject: Resumption of equal priority tasks after an ISR

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: BSD File System
Date: 3 Sep 1993 14:44:53 GMT
From: gwr@mc.com (Gordon W. Ross)
Organization: Mercury Computer Systems, Inc.
Message-ID: <GWR.93Sep3104457@walnut.mc.com>
References: <1993Aug26.201222.9581@exlog.com>
Reply-To: gwr@mc.com

A BSD "fast file system" implementation for VxWorks would be
convenient if it allowed you to swap SCSI disks between your
VxWorks box and your Sun (presuming both big-endian, etc.).

If all you want is reasonable file names, VxWorks 5.1 dosFsLib
will let you enable "unix style" file names which can have:
up to 40 characters, mixed case, any characters allowed.

Gordon W. Ross  		Mercury Computer Systems
gwr@mc.com      		199 Riverneck Road
508-256-1300			Chelmsford, MA 01824-2820

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: I need a DMA driver for the MVME-167
Date: Fri, 3 Sep 1993 17:50:35 GMT
From: zal@bnlux1.bnl.gov (gonzalo maldonado)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1993Sep3.175035.11555@bnlux1.bnl.gov>
References: <9308302047.AA08591@igate1.hac.com>

In article <9308302047.AA08591@igate1.hac.com> strenn@igate1.hac.com (Stephen P. Strenn) writes:
>
>sb07970@msgate.emis.hac.com
>
>I'm working on DMA transfers on a real-time data acquisition system consisting
>of a MVME-167 (Motorola 68040 based) and MicroMemory 128MB ram cards.  I'd like
>to find a DMA driver for the MVME-167.

I have written a set of routines for just this purpose:

bcopyDMA(3)            C LIBRARY FUNCTIONS            bcopyDMA(3)

NAME
     bcopyDMA - Routines for Direct Memory Access block  transfer
     over VMEbus.

SYNOPSIS
         bcopyDMA_Init - Initialize parameters and set interrupt vectors
                         for DMA block transfers.
         bcopyDMA - Routine to perform DMA block transfers over VMEbus.

         int bcopyDMA_Init(void)
         int bcopyDMA( *source, *destination, blockSize, addressModifier,
                       directionFlag, printFlag, intFlag)

              INT32 *source        - start address of block to transfer.
              INT32 *destination   - start address of destination.
              INT32 blockSize      - Size in bytes of block to transfer.
              char addressModifier - VME address modifier code.
              char printFlag       - print flag
              ( 1 = display diagnostic info, 0 = no display).
              char interruptFlag   - interrupt flag
              ( 1 = don't wait for completion of transfer. Enable interrupt.
                0 = wait for completion of transfer. No interrupts ).

They are simple to use and have been tested. Contact me for more info.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Resumption of equal priority tasks after an ISR
Date:  3 Sep 93 18:29:22 GMT
From: dwellbor@drao.nrc.ca (Dale Wellborn)
Organization: National Research Council, Ottawa, Canada
Keywords: tasks ISR
Message-ID: <dwellbor.747080962@sol>
Sender: root@nrcnet0.nrc.ca (Operator)

Hello.

Here is a questions from a VxWorks newby:

Situation:
- ---------

Task t1 is running at priority N

Task t2 is pending on semaphore Z at priority N

Task t3 is an ISR which semGives semaphore Z

And the scheduling algorithm is priority based preempive (i.e., there is no
round-robin scheduling at a given priority level).

Question:
- --------

Which task runs after t3 gives semaphore Z and exits (RTIs)?

Is it t1 since t1 is simply resumed after the ISR (and t1 is not pending)?

Or is it t2 since t2 is now READY (since it's needed Z semaphore resource is
now available)?

Thank you.

Dale Wellborn

Internet  :   dwellbor@sol.drao.nrc.ca
Snailnet  :   Dominion Radio Astrophysical Observatory
              P.O. Box 248, Penticton, BC, Canada V2A 6K3
BC Tel net:   (604) 490-4357
Faxnet    :   (604) 493-7767
Sneakernet:   RadioAstron building

Programmer 1: When I started programming, we didn't have any of these sissy
	      "icons" and "windows".

	      All we had were zeros and ones - and sometimes we didn't have
	      ones.

	      I wrote an entire database program using only zeros.

Programmer 2: You had zeros? We had to use the letter "O".

 From "Dilbert".

---------------------------

End of New-News digest
**********************

From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com  Sun Sep  5 01:33:30 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Sep  5 01:33:47 PDT 1993
Subject: Re: enpattach on vx5.1
First, the documentation does not mention how many ENP interfaces the
driver would support. Nor does the if_enp.h include file.
I think this must be mentioned in the manual pages.

However, it is obvious that Joe Van Andel didn't RTFM, cause if he
would, he would see that he's missing an argument, here is the full
protorype of enpattach:

     STATUS enpattach
         (
         int   unit,      /* unit number                    */
         char  *addr,     /* address of enp's shared memory */
         int   ivec,      /* interrupt vector to connect to */
         int   ilevel,    /* interrupt level                */
         int   enpAddrAm  /* address VMEbus address modifie */
         )

If you miss one argument, the value will be arbitrary, and it could
have been just the right value in the old version, and now it's not.

-----------------------------------------------------------------------
Leonid Rosenboim                           Voice/Fax: +972-3-72-44-98
R S T  Software Industries Ltd.            E-Mail: leonid@RST.HellNet.Org
P.O.Box 8077, Ramat-Gan 52180, Israel      WRS Distributor

From daemon@vxw.ee.lbl.gov  Mon Sep  6 04:01:12 1993
From: daemon@vxw.ee.lbl.gov
Date: Mon Sep  6 04:01:22 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Sep  6 04:01:03 PDT 1993

        Subject: vxWorks rpc clnt/svc problem.
        Subject: Re: vxWorks rpc clnt/svc problem.
        Subject: local static variables. (remote function call facility broken).

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: vxWorks rpc clnt/svc problem.
Date: 4 Sep 93 22:07:03 GMT
From: mef@cs.washington.edu (Marc Fiuczynski)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Message-ID: <1993Sep4.220703.15377@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)

I am using RPC to build a distributed service on rpc.  It is possible
that I will have both a rpc client and rpc server on the same vxWorks
CPU board.  To use RPC on vxWorks 5.x I modified rpcgen slightly to
produce the correct code. Since vxWorks is a single address space
operating system duplicate function name are replaced by the newer
ones with dynamic ld.  This creates a serious problem for me when both
a client and a service is on the same board.  I want my clients to
continue calling the functions in xxxxx_clnt.c and the server to call
the functions in xxxxx_svc.c.  

Can anyone suggest a way (with some sort of linking trick or so) to
get around this problem? The only thing that I can think of is to
alter rpcgen to "c_" to the client calls and "s_" to the server calls.

All ideas on this are highly appreciated.

Sincerely,

Marc E. Fiucznski

- -- 
/Marc...
mef@cs.washington.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxWorks rpc clnt/svc problem.
Date: 4 Sep 93 20:30:59
From: mef@willow.cs.washington.edu (Marc Fiuczynski)
Organization: /homes/rivers/mef/.organization
Message-ID: <MEF.93Sep4203059@willow.cs.washington.edu>
References: <1993Sep4.220703.15377@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)

OK!  I've now made some change to rpcgen that creates the server side
rpccalls with _S_foo_1() and the client side with _C_foo_1().  This
allows one to have both a server and a client on the same machine,
without name conflicts.

I am using the rpcgen from the vxWorks distribution, which is rpc4.0.
I've noticed that there is at least one newer rpcgen that produces
C++/ANSI-C compatible headers and supports RPC dispatch tables.
Anyone know where I could get that one???

Marc E. Fiuczynski
mef@cs.washington.edu

- --
/Marc...
mef@cs.washington.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: local static variables. (remote function call facility broken).
Date: 5 Sep 93 23:50:42 GMT
From: mef@cs.washington.edu (Marc Fiuczynski)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Keywords: rpc, rpcgen, vxworks, single address space OS.
Message-ID: <1993Sep5.235042.17154@beaver.cs.washington.edu>
Sender: news@beaver.cs.washington.edu (USENET News System)

The following simple test shows me that a the static local variables
used in the rpccode produced by rpcgen for remote-function-calls will
not work if there are multiple tasks using that rpc function call.

int *
foo_1(int i){
	static int j;

	j = i;

	logMsg("static variable = %d\n",j);
	taskDelay(120);
	logMsg("static variable now is %d\n",j);
	return(&j);
}

test(){
	taskspawn("foo1",100,0x10,1024,foo,1);
	taskspawn("foo2",100,0x10,1024,foo,2);
}

Why is it that the above code will print out :

- -> ld < static.o
value = 0 = 0x0
- -> test
value = 1994344 = 0x1e6e68
- -> 0x1e7434 (foo1): static variable = 1
0x1e6e68 (foo2): static variable = 2
0x1e7434 (foo1): static variable now is 2
0x1e6e68 (foo2): static variable now is 2

This is a major problem if one tries to build a basic rpc service that
is to be shared by multiple tasks.  The client code for rpcgen uses
static variables to function return results, which will get destroyed
if there are multiple tasks using it.

The only thing that I can think is not to use the remote function call
semantics and stick CLOSELY to remote-procedure-calls.  Thus, avoiding
the problem of static return results altogether.  Of course this is
only necessary for rpc facilities that might be called/shared by
multiple tasks, otherwise you can do whatever you please.

Any thoughts on this?  Did I start the tasks improperly?  Is there
some simple trick that will allow me to treat the static local
variable seperately for each seperate task?

Sincerely,

Marc E. Fiuczynski
mef@cs.washington.edu

- -- 
/Marc...
mef@cs.washington.edu

---------------------------

End of New-News digest
**********************

From fbh@shakespeare.gsfc.nasa.gov  Tue Sep  7 10:37:11 1993
From: fbh@shakespeare.gsfc.nasa.gov (Francis B. Hallahan)
Date: Tue Sep  7 10:37:21 PDT 1993
Subject: RE: local static variables
>mef@cs.washington.edu writes:
>Any thoughts on this?  Did I start the tasks improperly?  Is there
>some simple trick that will allow me to treat the static local
>variable seperately for each seperate task?

Marc,

I faced a similar problem developing a window server (not yet complete)
for VxWorks Tasks.  To answer your questions:

1.  Everything you did in testing the tasks is proper!  When used inside
a function, "static" ends up having the same effect as global.

2.  As for the "Trick",  look at taskVarLib.  It will allow you to 
treat global variables separately for each task; BUT read the manual
carefully!  This feature increases the task switching time.  The manual
recommends "An efficient use of task variables is to have a single task
variable that is a pointer to a dynamically allocated structure containing
the task's private data.

I am including a segment of my code to show how I used Task variables.
It is one of the demo programs, modified for our needs.  I have marked 
the appropriate lines with "%%%%%%%%..."

Please let me know what you end up with. Thanks :-)

Have Fun,
Frank

-----------------------------------------------------------------------------
/*	#define	SERVER_NUM	1100	 port number for socket communication */

/* Global Variables			 */
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
int             sock, snew;	/* socket fd's */
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
WIND_TCB        *Active_tcb;	/* Task using Window	 */
int		         Active_tid;	/* Task id using Window	 */

int				SERVER_NUM = 1100;	/* port number for socket communication */

#define ErrExit( c ) {errExit(c); return;}

errExit (int code)
{
    printf ("windowServer Error - %d\n", code);
    return;
}

/*******************************************************************************
*
* windowServer - server process
*
* This is a simple server program which communicates with a client
* through a socket.  It reads (recv's) characters, one at a time,
* from the client and echos them to standard output.  When the client
* goes away, the server also goes away (the server reads 0 characters
* from the socket).
*
* The server runs on VxWorks,and initiatesthe client on UNIX.
*
* See the manual page on sockets for more information.
*/

windowServer (WIND_TCB * tcb)
{
    struct sockaddr_in serverAddr;	/* server's address */
    struct sockaddr_in clientAddr;	/* client's address */
    int             client_len;	/* length of clientAddr */
    char            c;
	char			cmd_str[80] = "/usr/bin/X11/xterm -display vlsi8:0 -e  telnet vx1 ";

	STATUS			stat;

    extern int      errno;	/* for UNIX error referencing */

    if (Active_tcb != NULL)
	return;
    Active_tcb = tcb;
    Active_tid = (int) tcb;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
	stat = taskVarAdd (Active_tid, &sock);
	stat = taskVarAdd (Active_tid, &snew);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-----------------------------------------------------------------------
| Frank Hallahan                        |  fbh@vlsi.gsfc.nasa.gov     |
| Computer Sciences Corporation         |  Phone (301) 286 6844       |
| at Nasa Goddard Space Flight Center   |                             |
-----------------------------------------------------------------------

From mea@mclean.sparta.com  Tue Sep  7 14:42:29 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Tue Sep  7 14:42:38 PDT 1993
Subject: Centronics Parallel Ports
Greetings!

  Does anyone have a line on a VME-based I/O board that supports a Centronics
parallel port?  Ones with VxWorks drivers would be a real plus ;-).

Thanks,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                         Voice: (703) 448-0210 ext. 235
Director, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@mclean.sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

From ddowning@well.sf.ca.us  Tue Sep  7 14:57:03 1993
From: "Daniel D. Downing" <ddowning@well.sf.ca.us>
Date: Tue Sep  7 14:57:15 PDT 1993
Subject: Re: Real Time Experts Wanted
I'm intereste in possible new employment, so please send me a list
of companies and contacts that you might know of.

thanks

dan

From mclark@sadira.gb.nrao.edu  Tue Sep  7 16:26:11 1993
From: mclark@sadira.gb.nrao.edu (MARK H. CLARK)
Date: Tue Sep  7 16:26:20 PDT 1993
Subject: Re: Real Time Experts Wanted

Please remove me from the VxWorks exploder.  (2nd request)

				mclark@nrao.edu

From daemon@vxw.ee.lbl.gov  Wed Sep  8 04:01:31 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep  8 04:01:40 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep  8 04:01:20 PDT 1993

        Subject: re: enpattach on vx5.1
        Subject: Re: local static variables. (remote function call facility broken).
        Subject: VxWorks and Tcl
        Subject: Curses and termcap
        Subject: DAT driver availability

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: re: enpattach on vx5.1
Date: Tue, 7 Sep 1993 13:39:36 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <1993Sep7.133936.22662@ncar.ucar.edu>
References:  <9309050712.AA00314@RST.HellNet.org>
Sender: news@ncar.ucar.edu (USENET Maintenance)

Leonid Rosenboim writes:
>However, it is obvious that Joe Van Andel didn't RTFM, cause if he
>would, he would see that he's missing an argument, here is the full
>prototype of enpattach:

Unfortunately, since another user at our site receives the manuals that come
with the new release, I didn't RTFM, because I didn't even know that
particular manual (driver supplement) existed.  I've read it now, thanks.

WRS added an argument to the enpattach() call for this release, which is why my
code broke.  Had WRS provided a function prototype in the header file, I could
have found the error at compile time, rather than run-time!

- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	National Center for Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: local static variables. (remote function call facility broken).
Date: Tue, 7 Sep 1993 13:42:43 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Keywords: rpc, rpcgen, vxworks, single address space OS. 
Message-ID: <1993Sep7.134243.22903@ncar.ucar.edu>
References:  <1993Sep5.235042.17154@beaver.cs.washington.edu>
Sender: news@ncar.ucar.edu (USENET Maintenance)

>Any thoughts on this?  Did I start the tasks improperly?  Is there
>some simple trick that will allow me to treat the static local
>variable seperately for each seperate task?

Well, you could make the variables global, rather than static,
and use the "taskVarAdd" routine() to make sure that each task gets its own copy
of the variable.
- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	National Center for Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks and Tcl
Date: Tue, 7 Sep 1993 15:41:53 GMT
From: mistry@waterloo.hp.com (Mohan Mistry)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <CCzq9v.LEo@waterloo.hp.com>
Sender: news@waterloo.hp.com (NetNews)

Has anyone ported or selling Tcl on VxWorks.?

mohan 
mistry@waterloo.hp.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Curses and termcap
Date: Tue, 7 Sep 1993 21:15:29 GMT
From: beppe@edy (Giuseppe Surace)
Organization: Superconducting Super Collider Laboratory
Message-ID: <CD05pt.1uM@cfnews.ssc.gov>
Sender: usenet@cfnews.ssc.gov

  Hi Folks, 

  Does anyone know of source (hopefully public domain) for a 
  Curses and Termcap implementation for VXworks?

  Any help would be appreciated.

  Thanks,

	Giuseppe Surace

- --
          
          |---------------------------------------------------------|
          | Name.........: Giuseppe Surace                          |
          | Organization.: Superconducting Super Collider Laboratory| 
          | Division.....: ASD - Beam Instrumentation Department    |
          | Group........: Signal Processing and Electronics        |
          | Address......: 2550 Beckleymeade Ave Dallas Texas 75237 |
          |                Mail Stop 4005                           |
          | e-mail.......: beppe@edy.ssc.gov                        |
          | Telephone....: ++1 214 708 1149                         |
          |---------------------------------------------------------|

---------------------------

Newsgroups: comp.os.vxworks
Subject: DAT driver availability
Date: Wed, 8 Sep 1993 04:08:35 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1993Sep8.040835.15220@afterlife.ncsc.mil>

Anyone have a SCSI DAT driver available for 5.0.2b or 5.1?

Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

---------------------------

End of New-News digest
**********************

From mickel@digitailor.se  Wed Sep  8 07:42:22 1993
From: mickel@digitailor.se (Mikael Liden)
Date: Wed Sep  8 07:42:31 PDT 1993
Subject: Re: Centronics Parallel Ports
Mike Anderson/SPARTA writes:

>>   Does anyone have a line on a VME-based I/O board that supports a Centronics
>> parallel port?  Ones with VxWorks drivers would be a real plus ;-).

I know that VMIC has at least one board that is Centronics compatible:
the VMIVME-2511, 48-bit Universal TTL PIO Board with Handshake.
VMIC have VxWorks drivers for some of their boards, but I don't
know the status for this one.

VMIC - VME Microsystems International Corporation

Headquarters:	Huntsville, Alabama
		Phone: 205-880-0444
		Fax:   205-882-0859

VA Sales Rep:	Scott Data
		Newington, phone: 703-550-1300
		Richmond, phone:  804-270-5881

  Best regards,

        Mikael

  o==================================================================o
  |  Mikael Liden                            mickel@digitailor.se    |
  o==================================================================o
  |  Digitailor AB                           phone: +46-8 744 53 00  |
  |  A Microtec Research Company             fax:   +46-8 645 53 36  |
  o==================================================================o

From stan@rti.com  Wed Sep  8 08:45:20 1993
From: stan@rti.com (Stan Schneider)
Date: Wed Sep  8 08:45:28 PDT 1993
Subject: ev80960sx board

Hi all,

Is anyone running the Intel ev80960sx (sb flavor) board under VxWorks 5.1 out
there?  I'd like to talk to someone about it.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From visicom!VisiCom.COM!trest@nosc.mil  Wed Sep  8 14:16:10 1993
From: Mike Trest <trest@visicom.com>
Date: Wed Sep  8 14:16:26 PDT 1993
Subject: Real Time Experts Wanted
To All:

About a month ago I posted my message on this net suggesting that
we may not really know the true state of employment prospects for
the RTOS professional.  At that time, I invited any firms who have
positions available for "Experienced Real Time Professionals" to
send me an EMAIL message.  Likewise, I offered to mail this list
of positions to any individual who request it by a private EMAIL.

To date, I have sent a list of 7 firms with 15+ open positions to
approximately 60 individual requesters.  This is not a large
number, but it is significant given the limited distribution of
this news group and the restriction to experienced real time
professionals.

I am renewing this offer for until the end of September.  After 
then, I will be away until December.  At that time I will 
consider renewing the offer again.

I know that there are several firms still looking for people.
There is an expanding demand for experienced RTOS talent in 
several areas of the world.

THEREFORE, if you or you employer are searching for experienced
real time software and hardware talent, please send me an EMAIL
message.  Please include a few words about your firm, the kinds
of things you do, the kind of talent you are looking for, and
the method by with interested individuals may contact you.

If you, as an individual, are interested in receiving a copy of
EMAIL from any firms who have positions open, send me a EMAIL
note.  I will not send your name to anyone, including my own
employer.  When you receive a copy of the EMAIL messages from
firms with positions, the firms will not be notified either.

PLEASE REMEMBER TO USE trest@visicom.com  NOT THE EXPLODER
OR NET NEWS ADDRESS!

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From daemon@vxw.ee.lbl.gov  Thu Sep  9 04:01:36 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep  9 04:01:46 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep  9 04:01:20 PDT 1993

        Subject: Re: Centronics Parallel Ports
        Subject: NFS Server
        Subject: Re: DAT driver availability

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Centronics Parallel Ports
Date: Wed, 8 Sep 1993 16:29:25 GMT
From: anj@mail.ast.cam.ac.uk (Andrew Johnson)
Organization: Royal Greenwich Observatory, Cambridge (UK)
Message-ID: <1993Sep8.162925.7789@infodev.cam.ac.uk>
References: <9309072141.AA00803@helios>
Reply-To: anj@mail.ast.cam.ac.uk
Sender: news@infodev.cam.ac.uk (USENET news)

In article AA00803@helios, mea@mclean.sparta.com (Mike Anderson) writes:

||  Does anyone have a line on a VME-based I/O board that supports a Centronics
||parallel port?  Ones with VxWorks drivers would be a real plus ;-).

If you're just looking for standard I/O, the Motorola MVME335 has a Centronics
port on it, plus 4 RS232 ports.  Not sure about the drivers, but it uses the
68230 chip (68681 DUARTs) which is just about as vanilla as you can get so it
ought to be available somewhere.

- ---
   .  ____
  /|ndrew/
 /-|    /
/  |\__/ohnson

---------------------------

Newsgroups: comp.os.vxworks
Subject: NFS Server
Date: Wed, 8 Sep 93 15:09:59 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1993Sep8.150959.9715@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --

I just about done with the first pass at porting SOS to vxWorks.  I'm looking
for volunteers to find where it breaks... Please respond via email if
you'd like to point out where I've totally *&^%'ed up...

- -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: DAT driver availability
Date: Wed, 8 Sep 1993 15:36:46 GMT
From: browen@lyapunov.aoc.nrao.edu (Bruce Rowen)
Organization: National Radio Astronomy Observatory, Socorro NM
Message-ID: <BROWEN.93Sep8093646@lyapunov.aoc.nrao.edu>
References: <1993Sep8.040835.15220@afterlife.ncsc.mil>
Sender: news@nrao.edu

   Anyone have a SCSI DAT driver available for 5.0.2b or 5.1?

   Thanks.
   -- 

   Steve M. Burinsky
   smb@afterlife.ncsc.mil

we've been using the AP-Labs Interphase 4210 Jaguar SCSI driver (rev
3.0) with some Wangtek 6130 DAT's.

The driver is braindamaged and buggy, but works well enough to read
and write DAT tapes.

- --
- -------------------------------------------------------------------------------
Bruce Rowen 				National Radio Astronomy Observatory
Scientific Programmer				Array Operations Center
browen@aoc.nrao.edu			  P.O. Box O  Socorro, NM   87801
(505)385-7329					     (505)385-7000
- -------------------------------------------------------------------------------

---------------------------

End of New-News digest
**********************

From visicom!VisiCom.COM!pete@nosc.mil  Thu Sep  9 12:37:03 1993
From: Pete Heffron <pete@visicom.com>
Date: Thu Sep  9 12:37:17 PDT 1993
Subject: Mbus Device Drivers
A couple of questions concerning vxWorks 5.1...

Can anyone tell me what Mbus device drivers are supplied with the
Sparc vxWorks 5.1 environment? Please mail responses directly
to me.

thanks,

 Douglas Hanau 
 Software Engineer            Voice: (619) 457-2111 
 VisiCom Labortories          Fax:   (619) 457-0888 
 10052 Mesa Ridge Court       Inet:  hanau@VisiCom.COM 
 San Diego, CA. 92121

From markett@lams.msd.lmsc.lockheed.com  Thu Sep  9 17:30:58 1993
From: markett@lams.msd.lmsc.lockheed.com (Ray Markett)
Date: Thu Sep  9 17:31:07 PDT 1993
Subject: VME board with Centronics
In article AA00803@helios, mea@mclean.sparta.com (Mike Anderson) writes:

>  Does anyone have a line on a VME-based I/O board that supports a Centronics
>  parallel port?  Ones with VxWorks drivers would be a real plus ;-).

Two boards that I know of that have Centronics ports are the Motorola MVME147
and MVME167. VxWorks is available for both boards. I've used the serial line
drivers (tyCo/drv) for a 68030 board, but have not used the Centronics port.
These boards may have more features than you need/want, but they seem to be
well supported.

Good Luck,
Ray Markett

markett@lams.msd.lmsc.lockheed.com

From daemon@vxw.ee.lbl.gov  Fri Sep 10 04:01:20 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Sep 10 04:01:29 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Sep 10 04:01:11 PDT 1993

        Subject: Radio SLIP or serial Link
        Subject: Caution in buying WIND RIVERS / HEURIKON products !!!
        Subject: Re: Caution in buying WIND RIVERS / HEURIKON products !!!
        Subject: Re: Mbus Device Drivers

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Radio SLIP or serial Link
Date: Thu, 9 Sep 1993 15:17:51 GMT
From: markm@ee.ubc.ca (mark milligan)
Organization: University of BC, Electrical Engineering
Keywords: Radio,SLIP,serial 
Message-ID: <1993Sep9.151751.5379@ee.ubc.ca>
Sender: news@ee.ubc.ca (Usenet News)

Hi:

Someone mentioned a few months ago that they had setup a radio link 
between their vxworks target and their host using the SLIP interface.

I would like to do the same and would like to get more info on how
they acheived this and what equipment they used ( cost$ ???).

Anybody remember this?

- -- 
- -------
Mark R. Milligan					markm@ee.ubc.ca
University of British Columbia
Department of Electrical Engineering
Telerobotics and Control Lab.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Caution in buying WIND RIVERS / HEURIKON products !!!
Date: 9 Sep 1993 19:47:13 GMT
From: mwette@csi.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <26o181$ju7@csi.jpl.nasa.gov>

We bought some Heurikon HKV4F's and Wind Rivers' VxWorks to run on
them.  We are paying (many $K/year) to Wind Rivers for VxWorks
maintenance, as we have in the past for many projects.  We did get the
5.1 distribution, but it seems that neither company wants to provide
5.1BSP for the HKV4F.  Heurikon want us to pay maintenance to them as
well.  This is ridiculous.

We're pretty committed to VxWorks.  I just wish I had $40k to be able
to buy Motorola boards and through those HEURIKON boards in the trash.

	Matt
	A dissatisfied customer.

P.S.	We've been calling both companies about this problem and they
	seem to just point fingers at each other.
- -- 
mwette@csi.jpl.nasa.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Caution in buying WIND RIVERS / HEURIKON products !!!
Date: Fri, 10 Sep 1993 02:02:20 GMT
From: dat@noao.edu (D'Anne Thompson)
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Message-ID: <1993Sep10.020220.24263@noao.edu>
References: <26o181$ju7@csi.jpl.nasa.gov>
Sender: news@noao.edu

From article <26o181$ju7@csi.jpl.nasa.gov>, by mwette@csi.jpl.nasa.gov (Matt Wette):
> We bought some Heurikon HKV4F's and Wind Rivers' VxWorks to run on
> them.  We are paying (many $K/year) to Wind Rivers for VxWorks
> maintenance, as we have in the past for many projects.  We did get the
> 5.1 distribution, but it seems that neither company wants to provide
> 5.1BSP for the HKV4F.  Heurikon want us to pay maintenance to them as
> well.  This is ridiculous.
> 
> We're pretty committed to VxWorks.  I just wish I had $40k to be able
> to buy Motorola boards and through those HEURIKON boards in the trash.
> 
> ...

Matt is obviously upset and I agree with him that things are not as they
should.  We use VxWorks and Heurikon products and are happy but there
are a lot of gotchas.

1) Heurikon sells and distributes its own verion of VxWorks.  It is NOT
the same VxWorks product that is delivered by Wind River.  This applies
to both the core VxWorks system and the BSP for each CPU board.

2) You cannot mix a BSP product from Heurikon with VxWorks delivered by
Wind River, or vice-versa.  If you get your BSP from wind river you must
use a VxWorks from wind river.  If it comes from Heurikon then you must
use VxWorks from Heurikon.

The VxWorks and BSP delivered by Heurikon have been altered in the header
files and a number of the source modules.

To anyone who wants to challenge these statements I have BSPs and VxWorks
from both Wind River and Heurikon at this location and they are very
much different even for the same 'versions'.

It is my personal opinion that there is an ego at Heurikon
who feels that Wind River has missed the boat somewhere and can't leave
things well enough alone.  It is my view that the market place has
already adopted Wind River and that Heurikon is only shooting themselves
in the foot.

D'Anne Thompson
dat@noao.edu  {...}!uunet!noao.edu!dat
- -- 
D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732, Tucson, AZ 85726    (602) 325-9335
dat@noao.edu  {...}!uunet!noao.edu!dat

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Mbus Device Drivers
Date: Fri, 10 Sep 93 02:25:07 GMT
From: mcdowell@exlogcorp.exlog.com (Steve McDowell)
Organization: Baker Hughes INTEQ, Inc.
Message-ID: <1993Sep10.022507.23157@exlog.com>
References:  <9309091803.AA20787@stu.VisiCom.COM>
Sender: mcdowell@exlog.com (Steve McDowell)

In message <9309091803.AA20787@stu.VisiCom.COM>Pete Heffron <pete@visicom.com> asks:
>
> Can anyone tell me what Mbus device drivers are supplied with the
> Sparc vxWorks 5.1 environment? Please mail responses directly
> to me.

None. 

Just out of curiosity, what SPARC board are you using that has both
spare Mbus slots and a vxWorks BSP? 

- -- 
Steve McDowell				/* set things right...	*/
Baker Hughes INTEQ, Inc.		bzero(brain_buffer, sizeof(brain));
Houston, Texas USA		 		
	

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Fri Sep 10 04:43:50 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Sep 10 04:44:01 PDT 1993
Subject: RE: Radio SLIP or serial link
Greetings!

> From: markm@ee.ubc.ca (mark milligan)
> 
> Someone mentioned a few months ago that they had setup a radio link 
> between their vxworks target and their host using the SLIP interface.
> 

  We have done it using the LAWN boxes from O'Neill Communications
(Princeton, NJ (800) OCI-LAWN)).  Make sure that you get the version
that can handle Internet protocols.  They can run up to about 38.4KB
and cost around $350.  Their range is roughly 500-750ft.  Otherwise,
go with 14.4KB cellular modems with V.42bis (about 56KB).  A little
more expensive, but the range goes up to several miles.

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                         Voice: (703) 448-0210 ext. 235
Director, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@mclean.sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

 

From mea@mclean.sparta.com  Fri Sep 10 07:09:10 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Sep 10 07:09:21 PDT 1993
Subject: Re: Heurikon, WRS, etc. (long)
Greetings!

Matt Wette writes:

> 
> We bought some Heurikon HKV4F's and Wind Rivers' VxWorks to run on
> them.  We are paying (many $K/year) to Wind Rivers for VxWorks
> maintenance, as we have in the past for many projects.  We did get the
> 5.1 distribution, but it seems that neither company wants to provide
> 5.1BSP for the HKV4F.  Heurikon want us to pay maintenance to them as
> well.  This is ridiculous.
> 
> We're pretty committed to VxWorks.  I just wish I had $40k to be able
> to buy Motorola boards and through those HEURIKON boards in the trash.
> 
> 	Matt
> 	A dissatisfied customer.
> 
> 
> P.S.	We've been calling both companies about this problem and they
> 	seem to just point fingers at each other.
> - -- 
> mwette@csi.jpl.nasa.gov
> 

  Matt points out some serious problems with the entire VxWorks 5.1 distribution
approach as now implemented.  Companies like Heurikon who have been willing
to make the investment in a VxWorks source license ($120K to us mere mortals
plus $24K/yr for maintenance, clearly they get a discount) to better support 
their boards are most assuredly not trying to confuse the buying public
by deliberately distributing incompatible code.  I've worked with Heurikon
and others over the last several years and have found that, while they have
the best intentions for providing timely support, the actual implementation
sometimes falls short of the mark.  There are several reasons for this that
must be addressed.

1)  Wind River is clearly committed to supporting their largest selling
    BSPs first for 5.1.  This has been highlighted time and again over the
    last few months by people asking for 5.1 BSPs for Force, GMS and
    others because either these BSPs are either way down the list for
    WRS to port or that WRS has determined that there wasn't sufficient
    market for them to do the BSP and they have punted it back to the
    manufacturers (or to the customers) to try and figure out.
    Motorola is the largest selling VMEbus board manufacturer.
    Therefore, since WRS is now a publicly-held company and they have
    stock holders to answer to, WRS will work the most profitable piece
    of their market first (i.e., Motorola BSPs) and get to the others
    *later*.  This means that manufacturers such as Heurikon must now
    be more responsible for meeting their customers needs than ever
    before especially when it comes to 5.1.

2)  Any time that you have several different groups of programmers working on 
    the same source code separated by 1000s of miles, there will be
    problems dealing with configuration control.  Nobody's perfect
    (except maybe moi ;-).  As the manufacturers find and eliminate
    bugs in the WRS code (and vice versa), they send these change
    deltas back to WRS.  It takes time for WRS to look at and validate
    that the changes are correct and then incorporate those changes
    into their distribution source trees.  This time lag means that at
    any given point in time, there will be differences in the code that
    WRS is distributing versus code that is coming directly from the
    manufacturers.  This was further complicated in the 5.0.X days
    because there were different source trees for different processor
    architectures.  Those of us that had heterogeneous architectures
    saw that we were at 5.0.2 for 68K, 5.0.3 for i960 and 5.0.6 for
    MIPS.  Therefore, you're not just looking at one set of sources
    when you find a bug in a driver such as the 82596 Ethernet.  In
    fact, you're looking at at least 4 DIFFERENT sets of sources if you
    include SPARC (and even more with TRON and others).  5.1 is a
    significant step forward for all of us because it is the first
    version of VxWorks that *FINALLY* uses a unified source tree.  This
    is both painful and confusing to the support programmers at first,
    but will result in better support in the long run.

3)  In fact, I know that the Heurikon V4F BSP for 5.1 isn't even finished 
    yet (expected late Sept or early Oct).  Most manufacturers (Heurikon
    included) are scrambling to get all of their boards supported, and since
    VxWorks is not the *only* O/S that many of these manufacturers support,
    their staffs are stretched to the limit when a new release of an O/S
    comes out that is so considerably different from the previous one.  For
    those customers whose manufacturers are source code licensees, they can
    rest assured that the BSP will come out ASAP.  But, for those 
    manufacturers who relied of WRS's scarce resources for BSPs, then their
    customers are in a holding pattern until WRS can get around to them.

4)  Also, it has been my experience that WRS simply doesn't have the
    resources to support many of the features that are supported by a 
    particular board.  For example, why is the SCSI performance of the
    MVME167 boards so absolutely dismal?  Because WRS doesn't support 
    the DMA core facilities provided on-chip by the NCR 53C710 SCSI 
    controller.  If you want faster SCSI performance, you either WIY
    (write it yourself) or you go to the board manufacturers and have them
    modify their BSP to provide it (which Heurikon has done for me several
    times in the past for various boards).  As soon as they figure out
    how it's done, then the manufacturer makes the mods to VxWorks libraries
    and their BSPs and then sends the mods to WRS for incorporation into 
    the main distribution.  And wham, the versions are out of sync again.
    So, I'm not so convinced that its a matter of ego so much as it is 
    an attempt to be responsive to customer requests coupled with a long
    review pipeline of product commercialization at the WRS end.

5)  As far as the support issues are concerned, now we move into the morass
    of licensing hassles that has long plagued WRS.  We pay $23.5K for a 
    VxWorks license that can support 10 users on a single server.  I would
    argue that this is major overkill for the vast majority of projects that
    we work on.  I believe that most projects are typically a lot less in terms
    of simultaneous users (typically 1-5 people).  We get so incensed about
    support because we pay so much for a license that most of us never actually
    use.  So, why not change the licensing policy to have a "single seat"
    license at say $10K plus $1,500 per additional seat (a 10 user license
    at $23,500 would be a bargain then).  This would enable the 1-2 man
    projects and consulting firms to be able to afford VxWorks rather than
    having to go to OS-9, LynxOS or try to make do with Unix.  *I believe*
    that this would increase revenues to WRS because the high cost of entry
    to VxWorks would be significantly reduced and people would be more
    willing to experiment with a new O/S-approach at $10K rather than $23.5K.
    At least *I* would.
    
6)  When you buy VxWorks, $1.5K of your license fee is the BSP.  If you buy
    maintenance from WRS, then they can only ship BSPs that they have
    working at the time (for the most part, that means Motorola for the
    time being).  They'll send you the new libraries, but the BSP has
    got to come from somewhere.  If Matt purchased his VxWorks (and
    BSP) from Heurikon along with the WRS maintenance, then Heurikon
    has an obligation to supply him with a working BSP for 5.1 as soon
    as its available.  Heurikon got some of the profit from the sale to
    support their internal development people, therefore, he would have
    *paid* for their immediate support.  If, on the other hand, he
    purchased the license, BSP, etc. from WRS, then I don't see that
    Heurikon has any obligation beyond supplying the 5.1 BSP back to
    WRS who can then forward it to Matt as soon as it has passed WRS's
    internal quality control.  This means *DELAYS*.  If Matt wants to
    pay Heurikon directly for the 5.1 BSP ($1500), then he will get it
    quicker, but still have to wait until its finished.  I understand
    Matt's frustration, but these are hard times and companies have
    only a finite set of resources from which to draw.  No one, not
    WRS, not Heurikon, not even Motorola has infinite resources (not
    even I have those ;-).  Just because you pay Sun for Solaris
    maintenance, doesn't mean that Sun can fix a bug in a third party
    software product like Framemaker.  Many of the BSPs in WRS's
    current style of business are essentially third party software.  At
    least, WRS will forward the BSP to you when it becomes available to
    them.  Sun won't do that for Framemaker.

I hope that this tirade will generate some discussion (especially on the
licensing).  Also, if Matt had purchased everything through me, I'd do 
what I had to to make it right ;-).  We all try to be "nice" guys and help
our customers as much as we can, but our mutual paychecks have got to come from 
somewhere and management frequently doesn't understand the problems faced
by the technical staff when trying to be nice.  My suggestion: continue using
5.0.X until you're sure that your 5.1 BSP is available.  Being on the 
bleeding edge of technology never wins points with management if you can't
deliver the goods.

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                         Voice: (703) 448-0210 ext. 235
Director, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@mclean.sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

From clark@saturnv.jpl.nasa.gov  Fri Sep 10 09:20:40 1993
From: clark@saturnv.jpl.nasa.gov (Clark Briggs #3-1019)
Date: Fri Sep 10 09:20:59 PDT 1993
Subject: WRS vs Heurikon
Matt Wette expressed his dissatisfaction here with the lack of cooperation 
Heurikon and Wind River over the BSP for the V4F.  I want to second that 
opinion (its mine not my employers!!!).  A while ago, before voicing this
opinion over the net, I approached both companies about this and got no 
resolution.  They both explained the situation to me and there it sat.
As I remember it, (anyone who knows can feel free to jump in here) WRS feels
compelled to reduce or limit the number of particular models of SBCs they will
support themselvs, presumably due to bounded resources.  They make initial
choices as new models come out based upon their expectations of the market for
each board.  The V4F they felt would not be big enough for them to resell the
BSP.  The standard approach then is to get Heurikon to do this.  In the case
of HK, they seem to build the BSP and resell them any way, so this appears to
simply relieve WRS of the duplicative effort of passing the HK thru QA and 
reselling it.

The trouble is, like Matt says, V4F customers must now deal with two organizations
that are pointing fingers.  It is rarely clear in which camp problems lie, so
I expect support to be continual ping-pong of finger pointing.

I'd like to be clear that I have always gotten good products, sales and support
out of both companies in the past.  I've bought systems several times, and 
prefer to buy the software from one shop.  When I buy from HK, I go further to
buy the complete hardware and software from one shop.  This is important for
compatibility and problem resolution, in my opinion.  The current relationship
interferes with this, and I pay for it.

I am taking this to the net with Matt in hopes of turning up the heat on these
two companies.  

clark briggs
briggs@csi.jpl.nasa.gov
Please take these comments as mine and not my employer's.

From buchanan@argus.oip.mil  Fri Sep 10 09:40:45 1993
From: buchanan@argus.lowell.edu (Thomas K. Buchanan)
Date: Fri Sep 10 09:40:57 PDT 1993
Subject: VNE board with Centronics
In article AA00803@helios, mea@mclean.sparta.com (Mike Anderson) writes:

>  Does anyone have a line on a VME-based I/O board that supports a Centronics
>  parallel port?  Ones with VxWorks drivers would be a real plus ;-).

GreenSpring Computers makes one of their IP daughter cards with a 68230
configured for a Centronics type interface.  You might have to make a 
cable for it and you need a carrier assembly of some sort.  If you buy a
6U VME carrier, you will have 3 other slots for other Greeenspring I/O cards.
It is cost effective if you can use the extra I/O.  We have a generic
68230 driver as I'm sure you do, but not a driver for that card.  Good Luck.

--------------------------------------------------------------
Thomas Keith Buchanan    buchanan@lowell.edu
Senior Engineer          buchanan@atlas.usno.navy.mil

Interferometrics, Inc.   Navy Prototype Optical Interferometer
8150 Leesburg Pike       P.O. Box 1269
Vienna, VA 22182         Flagstaff, AZ  86001
(703)790-8500            (602)773-4868
--------------------------------------------------------------

From rayssd!Thorin.esd.ray.com!ken@uunet.uu.net  Fri Sep 10 10:36:27 1993
From: ken@thorin.esd.ray.com (Ken Balmy)
Date: Fri Sep 10 10:36:36 PDT 1993
Subject: posix compliance
warning: possible dumb question
pardon me for not R'ing TFM enough

is VxWorks compliant with Posix?
if not, how much and where is it deficient?

thx
ken@thorin.esd.ray.com

From pean@mbari.org  Fri Sep 10 10:44:22 1993
From: Andrew Pearce <pean@mbari.org>
Date: Fri Sep 10 10:44:30 PDT 1993
Subject: WRS vs HEURIKON, customers et al.
Greetings,

>We bought some Heurikon HKV4F's and Wind Rivers' VxWorks to run on
>them.  We are paying (many $K/year) to Wind Rivers for VxWorks
>maintenance, as we have in the past for many projects.  We did get the
>5.1 distribution, but it seems that neither company wants to provide
>5.1 BSP for the HKV4F.  Heurikon want us to pay maintenance to them as
>well.  This is ridiculous.

We had a similar experience with both the BSPs we use here. My problem
with the situation is not that WRS is unable or unwilling to continue
providing BSP updates to the latest revision, but that they did not
adequately communicate this fact to the user community in a timely
manner. We pay WRS a considerable sum in license fees and maintenance
fees and I believe it is reasonable to expect WRS to provide BSP
updates.  WRS has stated they will not be providing 5.1 BSPs for the
boards we use because they have decided to obsolete BSPs in some cases
and encourage board vendors to provide support directly in others. That
is a reasonable position to take, but why did WRS wait until 5.1 was in
beta test to have their customers discover the bad news? When a customer
is told by WRS that "VxWorks 5.1 will be released in March" what he
hears is "VxWorks 5.1, including support for my boards, will be released
in March". WRS needs to do a better job of keeping customers informed
on release schedules, especially now the product is as complex as it is
and with optional products becoming available. Any time a product is
obsoleted, I expect a vendor to give several months notice and provide
a program to phase out support not just drop it and say sorry you're on
your own.

>We're pretty committed to VxWorks.  I just wish I had $40k to be able
>to buy Motorola boards and through those HEURIKON boards in the trash.

Board vendors listen up. This week, I sent purchase orders to Motorola,
for MV162 boards to replace our previous (now unsupported) boards, and
to WRS for new BSPs, licenses, etc. Several board vendors tried to get
our business, but having been burned once, I concluded we would be crazy
to buy boards that did not have BSPs supported DIRECTLY by WRS. We are
not a large volume customer, but a $20k order is still worth having.

>P.S.	We've been calling both companies about this problem and they
>	seem to just point fingers at each other.

This is EXACTLY what happened to us and the situation is still unresolved.
Earth to WRS - the current arrangement is not, repeat NOT working. Be
advised, there are several unhappy customers out here and we are looking
to WRS to provide a solution.

Andrew Pearce
Monterey Bay Aquarium Research Institute

From vlp@mr.picker.com  Fri Sep 10 12:55:35 1993
From: vlp@mr.picker.com (Vic Potter)
Date: Fri Sep 10 12:55:44 PDT 1993
Subject:  WRS vs HEURIKON, customers et al.

Hello,

About 2 years ago we were involved with the HKV4F and the initial
board support for vxWorks on this board, long before 5.1 was a
gleam in anyones eye.  We experienced ALL the problems currently
being discussed at that time. 

It seams little in the relationship between WRS and Heurikon has
changes since then.

To make a long story short we took a hard look at the kind of
support we could expect from this arrangement over the life of our
product.  We decided to change to a CPU that was directly supported
by WRS, fortunately our development was at a point where this did
not have a great impact.  After reading some of this discussion I
am SURE we made the correct choice.

I am writing to make the following points:

The problems being discussed are not new, and have existed for
some time.

If because of these problems someone decides to switch CPU boards
or operating systems they would not be the first.

Vic Potter
Picker International

P.S.  The comments express here are my own and those of no one
      else.

From ddavies@jaba.sim.es.com  Fri Sep 10 15:16:31 1993
From: ddavies@jaba.sim.es.com (Doug Davies)
Date: Fri Sep 10 15:16:41 PDT 1993
Subject: WRS & BSPs
Folks,

I have been reading with interest the discussion about WRS and BSP support and
thought I would add my opinion/experience...

A couple of years ago we were trying to decide upon which of the many new 68040
boards we would buy to support one of our new product lines.  After contacting
several vendors, we were able to get 2 boards each and their corresponding
BSP from several vendors free of charge for evaluation purposes (many thanks
to them for loaning us the boards).  There were a few vendors that weren't so
accomodating... and consequently did not get a shot at our business (we buy
a fairly large volume of VME boards).

After a rather extensive set of benchmarks dealing with CPU performance,
memory access, bus access, and network performance, we topped off the
evaluation with a look into reliability & compatibility.

A couple of the vendor's BSPs were not supported by WRS, which seemed to be a
possible compatibility issue.  We also found that a couple of the BSPs and
their accompanying versions of vxWorks (5.0.2) were not compatable with the
current version of vxWorks that we had from WRS.  A few of the boards would
not run reliably at all.

We did receive some Heurikon 68040 boards and had so many problems with
incompatibilies with their vxWorks and BSP that we were unable to run our
benchmarks on them, so we sent them back with a thank you.

We use many architectures of off the shelf VME boards running vxWorks along
with a couple of our own proprietary CPU boards which we have ported vxWorks
to.  We did not feel it prudent to buy a board from a vendor that was not
supported by WRS and *ESPECIALLY* one that had to have their own version of
vwWorks.

Just for the record, we found the MVME16X line of 68040 boards offered by
Motorola to be top performers in almost all categories, with BSPs supported
by WRS, and excellent technical support via Motorola.  I don't mean to slam
any of the other board manufacturers.  Our decision was largely determined
by empircal data (benchmarks, specifications, peripherals, etc).  We have been
pleased with the performance & reliability of these boards, and the support
that we have received, and are receiving from Motorola (in my opinion) has
been very good.  We are currently using Motorola MVME147s, MVME162s, MVME166s,
MVME167s, & MVME168s, along with a sprinkling of a few other VME boards from
other vendors.

This is longer than I had intended and has turned into a testimonial, sorry ;-)

The upshot is that board vendors need to work hard at compatibility with WRS
when offering their own BSP, and especially IMHO to insure that their BSP
is completely compatible with the standard vxWorks distribution!  I'm sure that
there are a lot of details that I am not aware of in interfacing between WRS
and custom BSP developers, for that I apologize if I have been insensitive.

-Doug
--------------------------------------------------------------------------------
Douglas Davies (software engineer) |
Evans & Sutherland                 | "Never underpay your software engineers"
INTERNET: ddavies@jaba.sim.es.com  |                     -Jurassic Park Moral

From dfraser@wrs.com  Fri Sep 10 16:52:14 1993
From: dfraser@wrs.com (David Fraser)
Date: Fri Sep 10 16:52:23 PDT 1993
Subject: VxWorks BSPs
Thanks a lot for the various comments regarding Wind River and its support 
of board vendors and BSPs.  Some time ago it became obvious to us here that:

a) we couldn't keep up with demand for more and more board support packages

b) some of the board vendors did an excellent job of writing their own

c) WRS' interests sometimes didn't match the desires of the vendor: we 
wanted to create portable drivers, whereas the vendors wished for maximum 
performance tuned to the advantages of their particular board

d) VxWorks was gaining mainstream acceptance in the custom and embedded market

To address this, we decided that we couldn't fairly do everything ourselves, 
and produced a kit - "the BSP Porting Kit" - for board vendors and 
custom-board designers.  In an inexpensive package, this distilled most of 
our accumulated knowledge on BSPs and driver development.  It came with 
template source code and (most importantly) a validation suite to check out 
the completed work.  This kit is doing real well, and now in its second 
generation (we also gave away the product to a whole bunch of vendors!)

To support joint customers and avoid "finger pointing" we also created an 
easy to use validation service, whereby ANY vendor could have their BSPs 
QAed by Wind River.  This again was a very inexpensive and quick service, 
during which we qualify the product for conformance, and issue a stamp of 
validation.  Sales and mainstream support does rest with the vendor, however 
WRS does perform first line support.  So far we've had considerable success 
with this, with numerous vendors taking advantage of it (with the notable 
exception of Heurikon I'm sad to say).

I think Doug Davies hit the nail on the head when he wrote:

"The upshot is that board vendors need to work hard at compatibility with WRS
when offering their own BSP, and especially IMHO to insure that their BSP
is completely compatible with the standard vxWorks distribution!  I'm sure 
that there are a lot of details that I am not aware of in interfacing 
between WRS and custom BSP developers, for that I apologize if I have been 
insensitive."

In short, WRS does recognise the need to get a great level of BSP support 
out there.  We try hard to concentrate on the bigger sellers (including 
NUMEROUS Heurikon boards) to make most of our customers very happy.  For the 
rest, we've tried to adopt a fair amount, and make tools and services 
available to the remainder.  Occasionally some to fall between the cracks, 
when the vendor doesn't take advantage of our validation service.  In time, 
I hope we manage to alleviate this.

Best regards,
David Fraser
Director, Product Development
Wind River Systems
(dfraser@wrs.com)

From daemon@vxw.ee.lbl.gov  Sat Sep 11 04:01:17 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep 11 04:01:31 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep 11 04:01:08 PDT 1993

        Subject: Contact in Wind River Systems
        Subject: sustainable FDDI throughput
        Subject: Re: Caution in buying WIND RIVERS / HEURIKON products !!!

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Contact in Wind River Systems
Date: Thu, 9 Sep 1993 07:18:26 GMT
From: eric@hpgnd153.grenoble.hp.com (Eric_Dumas)
Organization: Hewlett-Packard, GND
Message-ID: <82860001@hpgnd153.grenoble.hp.com>

I would need the phone number or e-mail address of Wind River Systems.
I need both sales and technical information from them. References for
their european office would be appreciated. 

So far I tried "inquiries@wrs.com" with no answer...

Thanks ahead of time for your help

Eric Dumas

---------------------------

Newsgroups: comp.os.vxworks
Subject: sustainable FDDI throughput
Date: Fri, 10 Sep 1993 14:13:58 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Keywords: sustainable FDDI throughput
Message-ID: <1993Sep10.141358.19676@afterlife.ncsc.mil>

I'd like to hear others' experiences with FDDI products and VxWorks.  In
particular, what kind of throughput can I expect to sustain?  There are
lots of variables.  I'll list some and state some "preferences", although
I'm interested in whatever you can tell me.

VxWorks version (5.0.2b or 5.1)
FDDI hardware
FDDI driver
Transfer type (memory-to-memory)
Protocol (TCP/IP)
Other network loading (none)

I've heard that the VxWorks protocol stack is the real bottleneck with FDDI.
Can anyone confirm that?  Will it get better?  I'd really hate to have to
circumvent it.

Thanks.
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Caution in buying WIND RIVERS / HEURIKON products !!!
Date: 10 Sep 1993 11:20:10 -0600
From: bgeer@beorn.sim.es.com (bob geer)
Organization: Evans & Sutherland Computer Corporation
Message-ID: <26qd0b$o15@beorn.sim.es.com>
References: <26o181$ju7@csi.jpl.nasa.gov>
Reply-To: bgeer@beorn.sim.es.com

mwette@csi.jpl.nasa.gov (Matt Wette) writes:

>We bought some Heurikon HKV4F's and Wind Rivers' VxWorks to run on
>them.  We are paying (many $K/year) to Wind Rivers for VxWorks
>maintenance, as we have in the past for many projects.  We did get the
>5.1 distribution, but it seems that neither company wants to provide
>5.1BSP for the HKV4F.  Heurikon want us to pay maintenance to them as
>well.  This is ridiculous.

It certainly is an undesirable situation; however, with VxWorks
offloading specific board support to the board manufacturers I expect
we'll see more of this kind of crap.

One question: didn't pre-purchase product evaluation reveal this
situation?  If it did, I assume you wouldn't have purchased the
Heurikon board; if Heurikon didn't tell you about this problem, I
assume they would take the boards back for a full refund.

<> This is the big-sig, required to thwart the following:
<>    "Article not posted -- more included text than new text"
<>    " (Article not posted.)"
<>     "/usr/local/bin/inews failed"
<> I apologize for my sysadmins; if I could fix it, I would!
<>
<> Bob `Bear' Geer | bgeer@beorn.sim.es.com                             /    <>
<>                 |  (this *often* works)         __o      o   ,______/o    <>
<> Salt Lake City, | speaking only for myself,    -\<,     <\   ,__/   >     <>
<>          Ootah  | one of my many tricks        O/ O  __ /__,       /      <>
<> Bob `Bear' Geer | bgeer@beorn.sim.es.com                        |_______| <>
<>      lift-holic |  (this *often* works)        _O_    |___O___| | |_O_| | <>
<> Salt Lake City, | speaking only for myself, |_|_|_|_| | `'|`' |     |     <>
<>          Ootah  | one of my many tricks     |  / \  |    / \       / \    <>

- -- 
<> Bob `Bear' Geer <>   bgeer@beorn.sim.es.com     (this *should* work)   <>
<>     cola-zombie <>   speaking only for myself, one of my many tricks   <>
<> Salt Lake City, <>    "We must strive to be more than we are, Lal."    <>
<>          Ootah  <>           -- Cmdr. Data, learning schmaltz          <>

---------------------------

End of New-News digest
**********************

From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com  Sun Sep 12 04:36:25 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Sep 12 04:36:44 PDT 1993
Subject: Re: Mbus Device Drivers
Assuming that Sun Microsystems Mbus was referred to, I fail to see the
need for drivers for MBus, this is a bus intended to interconnect
multiple procesors with their common memory and interrupt sources. MBus
was never intended to connect peripherals to, and in all SUN systems
that use MBus, there is an integral Mbus-to-Sbus adapter, and all
peripherals are connected to the SBus, including the integral SCSI and
Ethernet.  Some MBus systems (e.g. 600MP) also have an SBus-to-VMEbus
adapter on-board.

I hope this clears some confusion.
-----------------------------------------------------------------------
Leonid Rosenboim                           Voice/Fax: +972-3-72-44-98
R S T  Software Industries Ltd.            E-Mail: leonid@RST.HellNet.Org
P.O.Box 8077, Ramat-Gan 52180, Israel      WRS Distributor

From mea@mclean.sparta.com  Mon Sep 13 04:42:00 1993
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Sep 13 04:42:09 PDT 1993
Subject: Re: sustainable FDDI throughput
Greetings!

Steve Burinsky writes:

> 
> I'd like to hear others' experiences with FDDI products and VxWorks.  In
> particular, what kind of throughput can I expect to sustain?  There are
> lots of variables.  I'll list some and state some "preferences", although
> I'm interested in whatever you can tell me.
> 
> VxWorks version (5.0.2b or 5.1)
> FDDI hardware
> FDDI driver
> Transfer type (memory-to-memory)
> Protocol (TCP/IP)
> Other network loading (none)
> 
> I've heard that the VxWorks protocol stack is the real bottleneck with FDDI.
> Can anyone confirm that?  Will it get better?  I'd really hate to have to
> circumvent it.
> 

With the drivers that we sell (and support) for the Interphase
Peregrine FDDI controllers (both 4211 and 5211) we can sustain about
2.11 MBytes/sec using VME32 transfers with a 32 MHz 68030 (Heurikon
V3D).  That was using the imfamous blaster/blastee as a measurement
mechanism.  When we switch to VME64 (5211 only) our throughput jumps up
to about 3.3 MBytes/sec.  Both of those measurements are with 48KByte
packets running 5.0.2b.  Your mileage will vary no doubt, and I didn't
have a chance yet to put a bus analyzer on it to see how much bus
bandwidth was being used.  By short circuiting the TCP stack, you
should be able to get faster performance.  We get better performance
using the reliable datagram protocol we built for our ARTSE(R)
software, so I'm sure that you can too.  I think that Bob Crispen at
Boeing (among others) has done this as well.

We here at SPARTA are also working on getting VxWorks to run *ON* the
Rev C 5211 board (68040 w/ VME64).  We have most of it going, but
Interphase seems to have changed the UART ASIC on the REV C boards that
is slowing us down for the time being until we can get more
documentation from Interphase.  By going directly to the 5211, we
should be able to eliminate at least one copy operation in multi-cpu
crates and pick the performance up a bit.  However, I think that the
TCP stack is the significant bottleneck here and we won't see any major
improvements until TCP 2.  XTP looked like a good candidate for a
while, but I recently heard that the company that was championing it
went belly up (the licensing prices seemed a little steep for those of
us interested in OEMing it anyway :-( ).

Regards,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                         Voice: (703) 448-0210 ext. 235
Director, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@mclean.sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

From calvin@netcom.com  Mon Sep 13 23:27:50 1993
From: calvin@netcom.com (John Calvin)
Date: Mon Sep 13 23:27:59 PDT 1993
Subject: GNU 2.4.5 -> Vxworks
Hello:
Im working on the project of building a GNU2.4.5 linux host/vxworks68 target
cross compiler.  Regretably this is not quite as trivial a task as I had
originaly contemplated.  Unlike GNU2.3.3 which had necessary configuration
files for the m68k-wrs (alias vxworks68) target option, GNU2.4.5 makes little
reference to any such configuration.  The best option they provide the 
m68k-local (alias hackers choice) option, which requires 6 basic "local"
files.  These are local.md, local.h, local.c, xm-local.h, t-local and x-local.
Before I lose any sleep over trying to conjure these up myself, has anybody
already done this excercise?  And if so, could you share the information or
better yet the files with the general vxworks users domain.
Any help or suggestions would be greatly appreciated, and as usual, thanks
to everybody in advance.
Calvin@netcom.com
Sunnyvale Ca.

From daemon@vxw.ee.lbl.gov  Tue Sep 14 04:01:22 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 14 04:01:32 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 14 04:01:12 PDT 1993

        Subject: bug in hkv30 vx5.1 boot rom?
        Subject: Heurikon's VxWorks
        Subject: Re: Heurikon's VxWorks

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: bug in hkv30 vx5.1 boot rom?
Date: Mon, 13 Sep 1993 19:00:10 GMT
From: gshaffer@frc.ri.cmu.edu (Gary Shaffer)
Organization: Field Robotics Center
Message-ID: <CDB3GF.10K.1@cs.cmu.edu>
Followup-To: comp.os.vxworks
Reply-To: gshaffer@frc.ri.cmu.edu
Sender: news@cs.cmu.edu (Usenet News System)

I just installed the WRS-supplied vx5.1 boot rom in my
33 MHz hkv30xe board.  It seems to work just fine so far
except for writing the boot parameters to the novolatile
ram.  When I change the boot parameters, the piggy-backed
static ram gets the changes, but after I power cycle, the
original values are read in from the nonvolatile ram.  I'm
able to write to the nonvolatile ram with the 5.0.2b boot
rom.  I know that the software is supposed to handle the
timing when writing to the nonvolatile ram, but I haven't
looked at the source code.

Is anyone else having this problem?

- - Gary

- ---
Gary Shaffer                    Internet: gshaffer@frc.ri.cmu.edu
Field Robotics Center              Phone: (412) 268-6554
Carnegie Mellon University           Fax: (412) 682-1793
Pittsburgh, PA 15213-3890

---------------------------

Newsgroups: comp.os.vxworks
Subject: Heurikon's VxWorks
Date: 13 Sep 93 21:52:55 GMT
From: toddw@vme.heurikon.com (Todd Wynia)
Organization: Heurikon Corporation, Madison, WI
Message-ID: <2324@heurikon.heurikon.com>
Reply-To: toddw@heurikon.heurikon.com (Todd Wynia)
Sender: news@heurikon.heurikon.com

Heurikon has received a lot of attention in comp.os.vxworks recently.  We want
to assure you that our intention is always to provide the customer with the
best possible product and service and that's why we've made a substantial in-
vestment to support VxWorks in-house.  In addition to being a source code
licensee, we have full time software engineers dedicated to doing board sup-
port packages and a staff of customer service engineers who know VxWorks in-
side out.  We are a beta site for most of the WRS products and have devoted
man years to help make the product better for both companies.  While the rela-
tionship has not been without its challenges, we've generally worked very well
together.

Regarding some of the comments made on the Net:

1)  Heurikon was wrong not to keep our BSPs compatible with WRS's.  Our board
support packages should always be compatible with Wind River's version no
matter what and we compromised that.  In hindsight realize that we should not
have deviated from Wind River on the 5.0.2 release for the V4F.  The reason
for the incompatibility in the past is that we have always striven to optimize
our BSPs for performance.  In the case of the V4F, we didn't support T040 bus
snooping, so we had to make changes to the kernel in order to enable caches.
This meant that if a customer purchased the developer's license from WRS and
the BSP from Heurikon, the two were incompatible.  With the release of 5.1,
we've rectified the situation and we are now 100% compatible (future versions
of the V4F will also have bus snooping).  In addition, we've introduced the
V4D which has full support for '040 bus snooping and is 100% compatible with
WRS's development package.

2)  Our board support packages will quite often lag WRS's release of VxWorks
because by the time we get the new release, even in beta format, there is sub-
stantial work in order to make a BSP ready to market.  For instance, our in-
tention is to make the BSPs as tuned to the performance of the board as possi-
ble.  This means support for DMA, VME64 and other features which may not be
supported by WRS BSPs.  In addition to fully supporting the boards' features
we have to put the BSP through validation at WRS.  All of this, on several
boards, may take several weeks.

3)  Heurikon and Wind River both recognize that there are problems in our re-
lationship.  Recently the presidents of both companies met in a sincere effort
to rectify the snags in what has generally been a very productive and syn-
ergistic relationship.

Our changes to BSPs and VxWorks were always intended to benefit the customer.
However, this recent volley of Net postings has shown us that we have not al-
ways met customers' expectations.  We're committed to change that.  Clearly,
no one has benefited from the incompatibilities; particularly the customers
caught in the middle.  We look forward to continued success working with Wind
River and we'll put every effort into making our BSPs 100% compatible with
VxWorks.

Sincerely,

Todd Wynia
Heurikon Corporation
Marketing Manger

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Heurikon's VxWorks
Date: 13 Sep 1993 21:22:35 -0700
From: mwette@csi.jpl.nasa.gov (Matt Wette)
Organization: Jet Propulsion Laboratory
Message-ID: <273gub$9lk@csi.jpl.nasa.gov>
References: <2324@heurikon.heurikon.com>
Sender: mwette@csi.jpl.nasa.gov

Heurikon has contacted us and has shown they are very interested in
following up on our gripes.  I'll post results of these interactions
when I have something worthwhile to say.  Although I'm fairly new in
the imbedded SBC world, my understanding is that JPL has had, in
general, very good relations with Wind Rivers and Heurikon.

- -- 
mwette@csi.jpl.nasa.gov

---------------------------

End of New-News digest
**********************

From mmourier@netxwest.com  Tue Sep 14 10:04:33 1993
From: mmourier@netxwest.com (Marcelo C Mourier)
Date: Tue Sep 14 10:04:42 PDT 1993
Subject: Re: GNU 2.4.5 -> Vxworks
> 
> Submitted-by calvin@netcom.com  Mon Sep 13 23:27:50 1993
> Submitted-by: calvin@netcom.com (John Calvin)
>  
> Hello:
> Im working on the project of building a GNU2.4.5 linux host/vxworks68 target
> cross compiler.  Regretably this is not quite as trivial a task as I had
> originaly contemplated.  Unlike GNU2.3.3 which had necessary configuration
> files for the m68k-wrs (alias vxworks68) target option, GNU2.4.5 makes little
> reference to any such configuration.
Doesn't VxWorks use the "standard" BSD a.out object file format? If this is the
case, configuring --target=m68k-sun-sunos4 should generate the right cc1...

--
Marcelo

 

From daemon@vxw.ee.lbl.gov  Wed Sep 15 04:01:21 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep 15 04:01:30 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep 15 04:01:11 PDT 1993

        Subject: msgQ's vs. pipes?
        Subject: Re: WRS vs HEURIKON, customers et al.

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: msgQ's vs. pipes?
Date: Tue, 14 Sep 1993 20:52:17 GMT
From: dmw@teal.csn.org (Dave Warner)
Organization: Colorado SuperNet, Inc.
Message-ID: <dmw.748039937@teal>
Sender: news@csn.org (news)

As a VxWorks newbie, I've read the pertinent sections of the
Programmer's Guide and Reference Manual about message queues
and pipes.  I'm soliciting comments on their relative efficiency
(both space and time) and any 'undocumented features' and/or
gotchas of using one mechanism over the other for IPC.

Thanks, Dave
- -- 

| Dave Warner            | e-mail: dmw@csn.org   |
| 151 Sky Trail Road     | Voice:  (303)443-9589 |
| Boulder, CO 80302      | FAX:    (303)443-9589 |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: WRS vs HEURIKON, customers et al.
Date: Wed, 15 Sep 1993 07:53:41 GMT
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Organization: The Holy Oscillators
Message-ID: <BARD.93Sep15005341@cutter.ssd.loral.com>
References: <9309101744.AA27000@nak.berkeley.edu>
Sender: news@wdl.loral.com

In article <9309101744.AA27000@nak.berkeley.edu> Andrew Pearce <pean@mbari.org> writes:

   Earth to WRS - the current arrangement is not, repeat NOT working. Be
   advised, there are several unhappy customers out here and we are looking
   to WRS to provide a solution.

I know for a fact that this grumbling on the newsgroup is making the
rest of my team think twice about starting any new projects with
VxWorks.  I'm still supporting code that runs under VxWorks 4.0

- --
j h woodyatt

"You have to like us."
	-- Col. Korn explaining the catch to Capt. Yossarian
	   in Joseph Heller's _Catch-22_.

---------------------------

End of New-News digest
**********************

From vdbent@rulrol.leidenuniv.nl  Thu Sep 16 03:06:35 1993
From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent)
Date: Thu Sep 16 03:06:46 PDT 1993
Subject: Locking out interrupts globally?
Hi There,

How can I work around the IMPORTANT CAVEAT of intLock(): "the lock is part of
the task's context"?

What I want is preventing a certain interrupt not to be handled while
executing a certain code fragment of a task.

    #    # ####   #  #####################################  #####   #   ##     #
    #  #   #  # # ########## ###  #########################  #### ####  #     #
   #     ## #   ### #######  ##  ########################## ## #   #   ##
 #    #       # ##### #####  #  ########################## ### ## ## #  # # #
   #    # ## # #######  ###    ####    ####    ####   ### ## ###  #           #
  #  # #    ### # ## ######   #### ###  ## ###  ## ######## ## # ###    # #  #
 #           #  ### ## ####    ##       #       ##   ###  ####### # ## #    #
   # # #  # ## ## ### ####  #  ##  ######  ########   #### ##### #       #    #
       ##   #   # ## #####  ##  #  ##   #  ##   ####  ###### ###   # ##     #
 #     #  #### ####  #####  ###  #    ####    ###    ######### # #  #   #  #
#     ##   #   #####  #####################################  #   #### #    #

                                Kees van der Bent
                           vdbent@rulrol.LeidenUniv.nl
                                  +31-71-275805

                     Space Research Organisation Netherlands
                                  P.O. Box 9504
                                 2300 RA  Leiden
                                 The Netherlands

From daemon@vxw.ee.lbl.gov  Thu Sep 16 04:01:05 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 16 04:01:16 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 16 04:00:48 PDT 1993

        Subject: Re: WRS vs HEURIKON, customers et al.
        Subject: SLIP between vxworks and sunos4.1.3
        Subject: Re: Heurikon's VxWorks

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: WRS vs HEURIKON, customers et al.
Date: Wed, 15 Sep 93 14:11:22 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1993Sep15.141122.12404@ll.mit.edu>
References: <9309101744.AA27000@nak.berkeley.edu> <BARD.93Sep15005341@cutter.ssd.loral.com>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --

This is getting a bit out of control...

This situation is very much like the rest of the software industry 
where a new release of anything comes out first for those platforms in
widest release (MS-DOS or Sun) and maybe eventually for DEC, HP...etc and
when and if it does come out for those platforms, it is usually because
DEC, HP et al have done the port themselves or have paid to have it done.

Will you stop buying Sun because Word Perfect is two releases behind
vs the MS-DOS version? I doubt it. What is the big surprise? WRS is not
the only company to farm out ports to third party hardware to drop support
for older models. Can you get Solaris 2 for a Sun 2? Not that anyone would
want to :-) 

Anyone benchmarked SCSI or TCP/IP performance on a WRS supported BSP for 
Force CPU 40 vs a Heurikon done BSP V4F?  
Heurikon's SCSI driver is only about 7 times faster and FTP transfers are
about twice as fast.... Or how about Synergy who also does their own 
BSP adding Syncronous SCSI for me, when WRS just says "maybe in 5.2 sometime
next year" (well almost a quote anyway)...

What is the big surprise?

I use boards from Motorola, Force, Synergy and Heurikon and am more than
willing to trade off a delay in getting the latest release for the far
better support I get from a small vendor such as Heurikon. If I have to call
WRS, I call the 800 number, never get a real person, leave a message and
wait for a call back... Usually the next day (Still waiting on the message
I left yesterday).  With Heurikon, I have the name and number of both
hardware and software engineers... I can get them directly. They respond
to email... They email me patches when needed.  Can't praise them enough!

- -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

OK Brent... Can I get a free year of support now :-)

---------------------------

Newsgroups: comp.os.vxworks
Subject: SLIP between vxworks and sunos4.1.3
Date: 15 Sep 1993 17:32:13 GMT
From: nam@peregrine.esl.com (Nam N. Nguyen)
Organization: esl.com
Message-ID: <277jit$c8@gatekeeper.esl.com>

I have had SLIP working between a FORCE board running vxworks 5.1, and
a sparc10 running sunos4.1.1.  Now, when I upgrade my sunos to 4.1.3, it
does not seem to work!  

I read the document from WindRivers, and it mentioned their SLIP only
supports sunos 4.0-4.1.2.  Is there a problem upgrading this SLIP to
support sunos4.1.3?

Vxworks users, PLEASE help!

Thanks,

Nam N.

PS.  Please send email to nam@esl.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Heurikon's VxWorks
Date: Wed, 15 Sep 1993 23:32:36 GMT
From: aweiler@wrs.com (A.R. Weiler)
Organization: Wind River Systems
Message-ID: <aweiler-150993102237@147.11.12.89>
References: <2324@heurikon.heurikon.com>
Followup-To: comp.os.vxworks
Sender: news@wrs.com (News Manager)

In article <2324@heurikon.heurikon.com>, toddw@vme.heurikon.com (Todd
Wynia) wrote:

> Our changes to BSPs and VxWorks were always intended to benefit the customer.
> However, this recent volley of Net postings has shown us that we have not al-
> ways met customers' expectations.  We're committed to change that.  Clearly,
> no one has benefited from the incompatibilities; particularly the customers
> caught in the middle.  We look forward to continued success working with Wind
> River and we'll put every effort into making our BSPs 100% compatible with
> VxWorks.

At this point, I believe it is important to emphasize that both Heurikon
and Wind River are actively working together to resolve many of the issues
posted recently on the Net.  To date, many positive steps have been taken
on all levels (technical support, engineering, marketing), and the working
relationship between the two companies has never been better.  But as was
noted by Todd Wynia, we still need to work hard to meet and exceed customer
expectations.

Wind River is committed to supporting Heurikon, both as a reseller of
VxWorks and as an important supplier of high-quality board products.  We
look forward to hearing from you on how we can make this partnership more
beneficial to our joint customers.

Regards,

A.R. Weiler
Director - Strategic Accounts
Wind River Systems/Alameda
(510) 814-2044

---------------------------

End of New-News digest
**********************

From rayssd!ssd.ray.com!fjr@uunet.uu.net  Thu Sep 16 05:16:19 1993
From: Roeber <fjr@ssd.ray.com>
Date: Thu Sep 16 05:16:34 PDT 1993
Subject: Re: Locking out interrupts globally?
Kees van der Bent says:
>  How can I work around the IMPORTANT CAVEAT of intLock(): "the lock is part of
>  the task's context"?
>  
>  What I want is preventing a certain interrupt not to be handled while
>  executing a certain code fragment of a task.

Use of intLock is fine for this situation is  fine.  All the cavaet means is
that if you were to schedule some other task while you had interrupts locked
using some VxWorks call and that other task unlocked interrupts, they would
remain locked when control returned to your context.  I wouldn't expect that
you are intending to schedule someone else inside of your critical section.
If you simply want to prevent other task level code from interrupting your
critical section, then use taskLock/taskUnlock to prevent a rescheduling.
Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |

From vdbent@rulrol.leidenuniv.nl  Thu Sep 16 07:40:37 1993
From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent)
Date: Thu Sep 16 07:40:48 PDT 1993
Subject: MORE Locking out interrupts globally?
Dear Fred,

Thanks a lot for your swift reply!

Let me explain my problem in more detail.  I've thinking through this matter a
bit more than when I wrote my first message as you will see.

There's a background task returning linked list nodes containing data it
receives from a socket.  Here's some abbreviated code:

    FOREVER {

        /* receive block address */
        read (sock, &pBlock, sizeof (pBlock)

        /* return block to pool */
        lockKey = intLock ();
        lstAdd (&poolList, P_BLOCK_NODE (pBlock));
        intUnlock (lockKey);
    }

And there's an ISR() which takes nodes from the list which does the following
each time it is called:

    /* get data block */
    if ((pBlockItem = (BLOCK_ITEM *)lstGet (&poolList)) == NULL) {
        logError (S_dppTapeLib_NO_POOL_BLOCK_AVAILABLE__DATA_LOST);

What I've seen happening, and happens very rarely, is that the task hit a bus
error and was suspended.

This is what must have happened in time:
	A. task:   succesful intLock()
	B. task:   entered listAdd()
	C. kernel: resceduled, other task executing -> interrupts unlocked
	D. ISR():  called by HW interrupt, does lstGet() -> mixed up list
	E. kernel: resceduled, task executing again
	F. task:   *BUS ERROR* in lstAdd() -> suspended

To overcome this, task locking is not an option but a necessity:

        /* return block to pool */
        taskLock ();
        lockKey = intLock ();
        lstAdd (&poolList, P_BLOCK_NODE (pBlock));
        taskUnlock ();
        intUnlock (lockKey);

What do you think of all this?

My final question is, does taskLock() disables resceduling of all tasks that
are able to unlock interrupts when running?  What about kernel tasks?

Clearly the CAVEAT for intLock() is an IMPORTANT one.  Not taking notice of it
made me create this enexpected bug.

Thanks again Fred.  And I hope you agree the bug should be fixed now.

    #    # ####   #  #####################################  #####   #   ##     #
    #  #   #  # # ########## ###  #########################  #### ####  #     #
   #     ## #   ### #######  ##  ########################## ## #   #   ##
 #    #       # ##### #####  #  ########################## ### ## ## #  # # #
   #    # ## # #######  ###    ####    ####    ####   ### ## ###  #           #
  #  # #    ### # ## ######   #### ###  ## ###  ## ######## ## # ###    # #  #
 #           #  ### ## ####    ##       #       ##   ###  ####### # ## #    #
   # # #  # ## ## ### ####  #  ##  ######  ########   #### ##### #       #    #
       ##   #   # ## #####  ##  #  ##   #  ##   ####  ###### ###   # ##     #
 #     #  #### ####  #####  ###  #    ####    ###    ######### # #  #   #  #
#     ##   #   #####  #####################################  #   #### #    #

                                Kees van der Bent
                           vdbent@rulrol.LeidenUniv.nl
                                  +31-71-275805

                     Space Research Organisation Netherlands
                                  P.O. Box 9504
                                 2300 RA  Leiden
                                 The Netherlands

From phil@naic.edu  Thu Sep 16 12:44:08 1993
From: phil@naic.edu (Phil Perillat Rm 407 X286)
Date: Thu Sep 16 12:44:17 PDT 1993
Subject: intUnlock discussion
Kees van der Bent writes:

----- Begin Included Message -----
Dear Fred,

Thanks a lot for your swift reply!

Let me explain my problem in more detail.  I've thinking through this matter a
bit more than when I wrote my first message as you will see.

There's a background task returning linked list nodes containing data it
receives from a socket.  Here's some abbreviated code:

    FOREVER {

        /* receive block address */
        read (sock, &pBlock, sizeof (pBlock)

        /* return block to pool */
        lockKey = intLock ();
        lstAdd (&poolList, P_BLOCK_NODE (pBlock));
        intUnlock (lockKey);
    }

And there's an ISR() which takes nodes from the list which does the following
each time it is called:

    /* get data block */
    if ((pBlockItem = (BLOCK_ITEM *)lstGet (&poolList)) == NULL) {
        logError (S_dppTapeLib_NO_POOL_BLOCK_AVAILABLE__DATA_LOST);

What I've seen happening, and happens very rarely, is that the task hit a bus
error and was suspended.

This is what must have happened in time:
	A. task:   succesful intLock()
	B. task:   entered listAdd()
	C. kernel: resceduled, other task executing -> interrupts unlocked
	D. ISR():  called by HW interrupt, does lstGet() -> mixed up list
	E. kernel: resceduled, task executing again
	F. task:   *BUS ERROR* in lstAdd() -> suspended

----- End Included Message -----

All this seems a bit strange to me. If the interrupt lock level is set high
enough  (def == 7 for 68k) then no interrupts can occur. As long as the program
does not call any routines that cause the task to block, no rescheduling can
occur. I would be very surprised if lstAdd caused  a program to block (might
i add that i've been surprised before!!). I don't have source code, but i've
always assumed that the lst functions just manipulate pointers (other than
lstFree()). 

Could it be that there is some other piece of code that is manipulating the 
linked list (knowingly or unknowingly)? Another possible error (speaking
from experience) is to pass a pointer to an object without allocating
the old object...

good luck,

phil perillat
arecibo observatory

From turtle!turtle.fisher.com!schaubert@fisher.com  Thu Sep 16 13:03:21 1993
From: schaubert@turtle.fisher.com
Date: Thu Sep 16 13:03:29 PDT 1993
Subject: PCI standard and card identification

Can someone tell me where to look for more information on the
new PCI standards?   I've been told they are planning on having
some standard way of identifying cards in a system and that
IBM and DEC have already signed on board.  Since I'm doing the
system engineering now I am hoping to get my hands on the
details of card ID.

Thanks in advance,
Joel
schaubert@fisher.com

From visicom!VisiCom.COM!trest@nosc.mil  Thu Sep 16 15:09:12 1993
From: Mike Trest <trest@visicom.com>
Date: Thu Sep 16 15:09:21 PDT 1993
Subject: Re: PCI standard and card identification
> Can someone tell me where to look for more information on the
> new PCI standards? 

Joel

The definitive work is:

	PCI Local Bus Specification  
	Production Version 
	Revision 2.0 April 30, 1993

It may be obtained from:

PCI Special Interest Group
M/S FG3-15A
5200 N.E. Elam Young Parkway
Hillsboro, Oregon 97124-6497
(508)696-2000

ENJOY!  ..mike..
====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From daemon@vxw.ee.lbl.gov  Fri Sep 17 04:01:41 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Sep 17 04:01:50 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Sep 17 04:01:27 PDT 1993

        Subject: VxWorks Users Group Meeting - DC - Nov 9
        Subject: authentication for rlogin
        Subject: BSD's Routing Daemon

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks Users Group Meeting - DC - Nov 9
Date: 16 Sep 93 12:31:58
From: smith@ampersand.com (Steve Smith)
Organization: Ampersand Inc., Westford, Mass.
Message-ID: <SMITH.93Sep16123158@control.ampersand.com>

I am pleased to announce that the 1993 East Coast VxWorks Users Group 
meeting will be held on Tuesday, November 9. The meeting will be in the
Washington, DC area this year.  

For new users or users who have never attended, this is a great 
opportunity to learn about future directions of VxWorks.  It can
also be very valuable to discuss problems, issues, and ideas with
other users, many of whom have been working with VxWorks for 5 or
more years.  I have attended this meeting every year since 1989,
and have found the signal to noise ratio at these meetings to
be extremely high.

The meeting is inexpensive, $50 at the door (cash, check, Visa and
Mastercard accepted), or $40 if you send us your check by the RSVP
deadline, Oct 29. 

Wind River Systems is graciously providing its customary level of 
support and has arranged for space at the McLean Hilton at Tysons
Corner in McLean, VA.  This location is convenient to both National
and Dulles airports, as well as to many of the DC area users.  WRS
has booked a block of rooms for those coming in from out of town.

Sessions begin at 9:00 a.m. and last until approximately 4:30 p.m., with
a break at noon for lunch.   The morning sessions will consist of
updates and presentations from Wind River Systems personnel, including:

	*	a review of new products
	*	an update on current and pending releases, architecture
		ports, and target ports
	*	future goals and directions, including the POSIX strategy
	*	an update and Q&A period with Dave Wilner, Wind
		River Systems co-founder and VP of Engineering.

The afternoon session has traditionally been organized by us users.
Past meetings have included:

	*	guest speaker lectures (Mike Tieman of Cygnus last year)
	*	third party vendor presentations
	*	user presentations
	*	birds-of-a-feather discussions on a variety of topics,
		including C++, ADA, networking, X & Motif and many
		others.

		Request for Suggestions !!!
		---------------------------

As the volunteer chairperson, I will arrange speakers and presentations
and put together a final agenda for the afternoon session during
the next month.  In this vein, I would like to solicit suggestions
from you, the VxWorks community, regarding what you would like to
see.

Some of my thoughts are:

	1) It was quite interesting to have Mike Tieman as a guest
	speaker last year (good job Todd).  It would be nice to have
	another distinguished speaker this year.  Perhaps we could
	get a speaker from the DoD / Government Agency community to 
	discuss government use of VxWorks and/or real-time computing.
	Any ideas about whom people might like to see as a speaker,
	either on this topic or any other?

	2) It is useful to get the latest scoop on third party products.
	If you  sell a third party product or service and would
	like to make a short presentation please get in touch with
	me.

	3) We have often had very interesting presentations by users
	with unique or exciting applications.  If you are involved
	in such an application and would be willing to share details
	with the Users Group, please get in touch.  (Is anyone from the
	New York City traffic system out there?)

So please get in touch if you would like to give a presentation or have
any ideas with regards to speakers, presentations, or anything
else you'd like to see on the afternoon agenda.

For those of you who don't know me, my name is Steve Smith.  I preside
over Ampersand, Inc., a 7-person software consulting/contracting firm
specializing in Unix and real-time systems.  I've worked with VxWorks
on a variety of projects since 1988, and can remember the old days of
VxWorks when people ran kernels other than wind.  I also co-chaired
the User's group meeting with Rudy DeBruyn in Fall of 1990, thus making
me the first person foolish enough to volunteer for this job twice :-).

I can be contacted at:

	Stephen Smith		
	President	   
	Ampersand, Inc.		
	66 Tadmuck Road	
	Westford, MA 01886	
	smith@ampersand.com
	Phone: 508-392-1171
	Fax:  508-392-1174

I will be out of town until October 4, but please send me suggestions
in the meantime anyway.  You can also follow up with 

	Nora Mitchell		
	Wind River Systems
	1010 Atlantic Ave.	
	Alameda, CA 94501	
	nora@wrs.com
	Phone:	510-814-2052
	Fax: 510-814-2010

To register:
Checks can be made payable to the VxWorks Users Group.  Please include your
name, title, company, address, phone and fax numbers.  Send to Nora
Mitchell at the above address.  She will then fax you a confirmation letter
and directions to the hotel.

The address and phone for the meeting site are:

McLean Hilton at Tysons Corner
7920 Jones Branch Drive
McLean, VA 22102
703-847-5000
703-761-5100 fax

I welcome your input, and look forward to a great meeting!

Steve

---------------------------

Newsgroups: comp.os.vxworks
Subject: authentication for rlogin
Date: 16 Sep 1993 22:11:46 GMT
From: berg@fndaud.fnal.gov (David Berg)
Organization: Fermi National Accelerator Laboratory, Batavia IL
Message-ID: <27aob2$4n4@fnnews.fnal.gov>

Hi,

We are running VxWorks 5.0.2b at Fermilab.

We have a program that runs under Unix that uses rlogin to maintain open
terminal sessions with a number of remote nodes. On other Unix systems,
we use the .rhosts files for authentication. Our VxWorks nodes, however,
have only password protection, and we don't want to have to put passwords
into a file on the host. Is there anything equivalent to .rhosts that is
supported by rlogin under VxWorks? How about in 5.1?

Thanks,
David Berg

Online Support Dept.
Fermilab
P. O. Box 500
Batavia, IL 60510

(berg@fndaut.fnal.gov)
708-840-3021

---------------------------

Newsgroups: comp.os.vxworks
Subject: BSD's Routing Daemon
Date: Fri, 17 Sep 1993 03:57:57 GMT
From: mmourier@netcom.com (Marcelo Mourier)
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Message-ID: <mmourierCDHCCM.1Gq@netcom.com>

Has anybody ported BSD's Internet routing daemon (routed) to VxWorks? Does
anybody know of a similar comercial product?

Thanks,

- --
Marcelo
- -- 
Marcelo Mourier
mmourier@netcom.com

---------------------------

End of New-News digest
**********************

From rayssd!ssd.ray.com!fjr@uunet.uu.net  Fri Sep 17 05:30:14 1993
From: Roeber <fjr@ssd.ray.com>
Date: Fri Sep 17 05:30:23 PDT 1993
Subject: Re: intUnlock discussion
>  Kees van der Bent writes:
>
>  There's a background task returning linked list nodes containing data it
>  receives from a socket.  Here's some abbreviated code:
>  
>      FOREVER {
>  
>          /* receive block address */
>          read (sock, &pBlock, sizeof (pBlock)
>  
>          /* return block to pool */
>          lockKey = intLock ();
>          lstAdd (&poolList, P_BLOCK_NODE (pBlock));
>          intUnlock (lockKey);
>      }
>  
Phil then says:
>  
>  All this seems a bit strange to me. If the interrupt lock level is set high
>  enough  (def == 7 for 68k) then no interrupts can occur. As long as the program
>  does not call any routines that cause the task to block, no rescheduling can
>  occur. I would be very surprised if lstAdd caused  a program to block (might
>  i add that i've been surprised before!!). I don't have source code, but i've
>  always assumed that the lst functions just manipulate pointers (other than
>  lstFree()). 

I told Keys directly this same thing.  We have source, the list routines
don't cause task switches.  I thought the problem was that the code is reading
from a socket and assuming that the full structure is returned from the read.
With a TCP/IP socket, this won't always be the case.  You have to poll the
socket by reading until you get the full amount you expect.  Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |

From daemon@vxw.ee.lbl.gov  Sat Sep 18 04:01:33 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Sep 18 04:01:45 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Sep 18 04:01:23 PDT 1993

        Subject: Re: sustainable FDDI throughput
        Subject: Re: VxWorks Users Group Meeting - DC - Nov 9
        Subject: Interphase 4211 Peregrine driver.
        Subject: Re: bug in hkv30 vx5.1 boot rom?
        Subject: VxWorks 5.1 SCSI/DOS File System Issues
        Subject: re: PCI standard and card identification

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: sustainable FDDI throughput
Date: Fri, 17 Sep 1993 11:34:44 GMT
From: hjb@netcom.com (hwajin bae)
Organization: peaceful star, oakland, ca - vox: 510.536.7607 page: 510.466.9166
Message-ID: <hjbCDHxHx.3EH@netcom.com>
References: <9309131140.AA03743@helios>

In article <9309131140.AA03743@helios> mea@mclean.sparta.com (Mike Anderson) writes:
>With the drivers that we sell (and support) for the Interphase
>Peregrine FDDI controllers (both 4211 and 5211) we can sustain about
>2.11 MBytes/sec using VME32 transfers with a 32 MHz 68030 (Heurikon
>V3D).  That was using the imfamous blaster/blastee as a measurement
>mechanism.  When we switch to VME64 (5211 only) our throughput jumps up
>to about 3.3 MBytes/sec.  Both of those measurements are with 48KByte
>packets running 5.0.2b.  Your mileage will vary no doubt, and I didn't
>have a chance yet to put a bus analyzer on it to see how much bus
>bandwidth was being used.  By short circuiting the TCP stack, you
>should be able to get faster performance.  We get better performance
>using the reliable datagram protocol we built for our ARTSE(R)
>software, so I'm sure that you can too.  I think that Bob Crispen at
>Boeing (among others) has done this as well.

in order to really get as much as you can out of given HW, the driver
needs to be optimized.  i haven't looked at peregrine fddi driver for
years (BTW, i did *not* work on any interphase fddi stuff directly, altho
i wrote fddi drivers for other vendors; when i was at interphase i
worked on NFS co-processor product, exclusively), but it could prolly use
a bit of tuning.  to achieve a real "loaning" of mbufs (avoiding 
of bcopy), the mbuf code will need to be changed (unless it already
has).  basically the cluster mbufs can't be blindly 1K or 2K... or
whatever.  there needs to be generalized loaning support for
arbitrary size clusters (for example 4500 MTU on FDDI).  a single
largest overhead is always bcopy of data in network code profile.
the second is checksumming, but '030 assembly code that does this
is as optimal as can be.  

>We here at SPARTA are also working on getting VxWorks to run *ON* the
>Rev C 5211 board (68040 w/ VME64).  We have most of it going, but
>Interphase seems to have changed the UART ASIC on the REV C boards that
>is slowing us down for the time being until we can get more
>documentation from Interphase.  By going directly to the 5211, we
>should be able to eliminate at least one copy operation in multi-cpu
>crates and pick the performance up a bit.  However, I think that the
>TCP stack is the significant bottleneck here and we won't see any major
>improvements until TCP 2.  

net-2 TCP should help but not by much until you get the mbuf loan stuff
sorted out.

there are ports of net-2 code done for vxworks, but not by wrs.

> XTP looked like a good candidate for a
>while, but I recently heard that the company that was championing it
>went belly up (the licensing prices seemed a little steep for those of
>us interested in OEMing it anyway :-( ).
>

is this true?  what happened to all the TAB members and the KRM code
that used to be distributed?  i know bob crispin did a quick
port of XTP many years ago to vxworks based on early KRM code.
i also remember greg chesson and others mentioning something about
donating XTP code to berkeley...  but then again, i left before PEI really
went south.

kinda strange how all these companies i used to work for converge together
into a single problem.

;-)

- --
Hwajin Bae (hjb@netcom.com)				2899 Ford Street
PEACEFUL STAR						Oakland, CA 94601
Consulting Services: UNIX, VxWorks, FREE RT kernel	Voice/FAX: 510.536.7607
TCP/IP, NFS, Realtime, Embedded systems, SW & HW	Pager:     510.466.9166

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks Users Group Meeting - DC - Nov 9
Date: Fri, 17 Sep 1993 11:42:39 GMT
From: hjb@netcom.com (hwajin bae)
Organization: peaceful star, oakland, ca - vox: 510.536.7607 page: 510.466.9166
Message-ID: <hjbCDHxv3.457@netcom.com>
References: <SMITH.93Sep16123158@control.ampersand.com>

In article <SMITH.93Sep16123158@control.ampersand.com> smith@ampersand.com (Steve Smith) writes:
>	Perhaps we could get a speaker from 
>	the DoD / Government Agency community to 
>	discuss government use of VxWorks and/or real-time computing.

sounds like fun.

it's funny how things turn out when a good thing gets too big and greedy...

i know you've all heard it before...
peace & love,
hwajin

- --
Hwajin Bae (hjb@netcom.com)				2899 Ford Street
PEACEFUL STAR						Oakland, CA 94601
Consulting Services: UNIX, VxWorks, FREE RT kernel	Voice/FAX: 510.536.7607
TCP/IP, NFS, Realtime, Embedded systems, SW & HW	Pager:     510.466.9166

---------------------------

Newsgroups: comp.os.vxworks
Subject: Interphase 4211 Peregrine driver.
Date: Fri, 17 Sep 1993 13:15:29 GMT
From: heyes@dahp1.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.93Sep17081530@dahp1.cebaf.gov>
Sender: usenet@murdoch.acc.Virginia.EDU

I have an Interphase 4211 Peegrine FDDI VME interface which I 
would like to use for high speed data communication using TCP
streams between an mv167 and a HP 9000/715 workstation. 
I have a VxWorks driver which was provided unsupported and not
working by Interphase when I bought the board about 9 months 
ago. I got the driver working at about 2.7 Mb/s continuous
throughput with UDP then got side tracked onto other projects
for a few months. Meanwhile has anyone got a better driver for
this board ?

I am also looking at buying an Interphase 5211 Peregrine-II,
the sales rep tells me someone is working on a VxWorks driver
for that board.

If anyone has any information, improved drivers or just plain 
advice please send an E-mail. We are a DoE research lab so we
are not going to take your code and sell it to the highest 
bidder, just trying to save some tax dollars by not having to
develop a driver of our own.

	thanks,
- --

		Graham

- -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Graham Heyes,CEBAF,12000 Jefferson Ave,Newport News,VA 23606,Tel:(804) 249-7030

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: bug in hkv30 vx5.1 boot rom?
Date: 15 Sep 93 16:46:52 GMT
From: dale@bilbo.heurikon.com (Dale Wade)
Organization: Heurikon Corporation, Madison, WI
Message-ID: <2325@heurikon.heurikon.com>
References: <CDB3GF.10K.1@cs.cmu.edu>
Reply-To: dale@bilbo.heurikon.com (Dale Wade)
Sender: news@heurikon.heurikon.com

In article <CDB3GF.10K.1@cs.cmu.edu> gshaffer@frc.ri.cmu.edu writes:
>I just installed the WRS-supplied vx5.1 boot rom in my
>33 MHz hkv30xe board.  It seems to work just fine so far
>except for writing the boot parameters to the novolatile
>ram.  When I change the boot parameters, the piggy-backed
>static ram gets the changes, but after I power cycle, the
>original values are read in from the nonvolatile ram.  I'm
>able to write to the nonvolatile ram with the 5.0.2b boot
>rom.  I know that the software is supposed to handle the
>timing when writing to the nonvolatile ram, but I haven't
>looked at the source code.
>
>Is anyone else having this problem?
>
>- Gary
>
>---
>Gary Shaffer                    Internet: gshaffer@frc.ri.cmu.edu
>Field Robotics Center              Phone: (412) 268-6554
>Carnegie Mellon University           Fax: (412) 682-1793
>Pittsburgh, PA 15213-3890

The problem you describe is the result of trying to store too much info
into NVRAM and the code in the boot ROM failing to check for a return
status.  Also, since obtaining the boot parameters and storing them
into NVRAM is a two step process, the parameters are being updated in
RAM, but not NVRAM.  That is why everything works while power is applied
but fails once you power cycle and the RAM copy is reread from NVRAM.

Also, the difference in behavior between 5.0.2 and 5.1 is the result
of a change made so that sysNvRamSet() now knows how much NVRAM it
truly has.   Under 5.0 it used to think it had more NVRAM, thus it
didn't fail with a boot string that was too long, it just went ahead
and wrote the string to NVRAM truncating it in the process (which
of course you wouldn't see until power cycling).

The above is not specific to a v30, it just happens that the v30 uses
an NVRAM part with only 128 bytes of storage.

The quick fix is to edit config/all/bootConfig.c and change the call
to sysNvRamSet() from a (void) to look for a return of ERROR, and
then to print a warning message.  However, As the call to bootParamsPrompt()
has already been completed,  the RAM copy of the boot parameters will
already have been changed and you'll still notice the same behavior as
you mention above, its just that you'll now be warned about the problem.
Of course for the fix to take place, after editing bootConfig.c you'll
have to remake bootrom.hex and burn a new boot PROM.

The even quicker fix is to just know that you only have 128 bytes of
NVRAM on the v30 (actually 256 4-bit locations) and that VxWorks adds
a few characters to your boot string to mark the various boot fields
(display location 0x3000700 on the v30 to see what the boot string
looks like when stored).  If you stay under 100 characters or so
for boot parameters, things should work fine (the fewer boot fields
you use, the less extra characters taken up to denote the fields and
the more space that you'll have).

I'll contact Wind River so that we can work together to get a fix folded
in to future releases.

- -Dale

+------------------------------------------------------------------------------+
|       Dale Wade                       email: dale@heurikon.com               |
|       Software Customer Support       voice: (800) 327-1251                  |
|       Heurikon Corporation                   (608) 831-5500                  |
+------------------------------------------------------------------------------+

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks 5.1 SCSI/DOS File System Issues
Date: Fri, 17 Sep 1993 17:59:43 GMT
From: sstern@atl.com (Steven Stern)
Organization: Advanced Technology Laboratories
Keywords: SCSI, DOS
Message-ID: <1993Sep17.105943@atl.com>
Sender: news@atl.com

Has anyone had any success using a SCSI hard disk initialized under MS-DOS on
a 5.1 VxWorks system or a hard disk initialized on VxWorks on an MS-DOS system?
If I initialize on one, I can't read it on the other.

I'm also having a problem with optical drives.  One problem I have
encountered has to do with the "number of blocks" argument passed to
the scsiPhysDevCreate() function.  The temptation exists to hard code
this figure by dividing the block size (512) into the maximum byte
capacity of the optical disk used.  The problem with this approach is it
is not "friendly" to the possible insertion of an optical disk of a
different capacity.  To compute the capacity of the optical drive, one may
use the scsiReadCapacity() function but in order to use this function,
you must first call scsiPhysDevCreate(), i.e., chicken and egg problem.
I also tried calling scsiPhysDevCreate(pSysScsiCtrl, devId, devLUN, 0,
NONE, 0, 0, 0) which should compute this information
automatically according to the documentation.  This results in an
S_scsiLib_ILLEGAL_OPERATION error.

I also have problems reading floppy disks and optical disk on an MS-DOS system
which were initialized under VxWorks.
  
Any ideas?

Thank you,
sstern@atl.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: re: PCI standard and card identification
Date: 17 Sep 93 20:08:28 GMT
From: kab@strl.labs.tek.com (Kent Black)
Organization: DTL, Tektronix, Inc.
Message-ID: <5774@crl.LABS.TEK.COM>
References: <9309162129.AA04029@maureen.VisiCom.COM>
Sender: news@crl.LABS.TEK.COM

In article <9309162129.AA04029@maureen.VisiCom.COM>, trest@visicom.com (Mike Trest) writes:
|> > Can someone tell me where to look for more information on the
|> > new PCI standards? 
|> 
|> Joel
|> 
|> The definitive work is:
|> 
|> 	PCI Local Bus Specification  
|> 	Production Version 
|> 	Revision 2.0 April 30, 1993
|> 
|> It may be obtained from:
|> 
|> PCI Special Interest Group
|> M/S FG3-15A
|> 5200 N.E. Elam Young Parkway
|> Hillsboro, Oregon 97124-6497
|> (508)696-2000

The area code should be 503.  But that number gets you a recording.

Order from 1 800 433 5177; manual is $25 + $7 s/h.  VISA/MC.

- -- kab

Kent Black      
    -----------------------------------------------------------------
     DTL, Tektronix Inc.            |   Email:  kab@dtl.labs.tek.com
     P.O. Box 500, M/S 50-662       |   Voice:  (503) 627-6280
     Beaverton, OR  97077           |   FAX:    (503) 627-5502
    -----------------------------------------------------------------

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Mon Sep 20 04:01:26 1993
From: daemon@vxw.ee.lbl.gov
Date: Mon Sep 20 04:01:35 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Sep 20 04:01:18 PDT 1993

        Subject: Re: sustainable FDDI throughput

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: sustainable FDDI throughput
Date: Sun, 19 Sep 1993 22:48:43 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1993Sep19.224843.27721@afterlife.ncsc.mil>
References: <9309131140.AA03743@helios>

In article <9309131140.AA03743@helios>,
Mike Anderson <mea@mclean.sparta.com> wrote:
>                                           However, I think that the
>TCP stack is the significant bottleneck here and we won't see any major
>improvements until TCP 2.  XTP looked like a good candidate for a
>while, but I recently heard that the company that was championing it
>went belly up (the licensing prices seemed a little steep for those of
>us interested in OEMing it anyway :-( ).

Could you explain what TCP 2 and XTP are?

- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Tue Sep 21 04:01:26 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 21 04:01:34 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 21 04:01:14 PDT 1993

        Subject: Multiple Initiators On Scsi; VxWorks 5.1

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Multiple Initiators On Scsi; VxWorks 5.1
Date: Mon, 20 Sep 1993 16:58:35 GMT
From: sstern@atl.com (Steven Stern)
Organization: Advanced Technology Laboratories
Keywords: SCSI, Initiator
Message-ID: <1993Sep20.095835@atl.com>
Sender: news@atl.com

Does anyone know of a port to the Motorola MVME167 board which supports
SCSI 2 or multiple initiators?

Thank you,
sstern@atl.com

---------------------------

End of New-News digest
**********************

From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com  Tue Sep 21 04:35:39 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Tue Sep 21 04:35:53 PDT 1993
Subject: Moving to VxWorks 5.1 Technical Note
Here is an updated version of the paper I have published on this list
a couple of weeks ago, some comments from the network users have been 
incorporated when of value to the general public.
-----------------------------------------------------------------------
Leonid Rosenboim                           Voice/Fax: +972-3-72-44-98
R S T  Software Industries Ltd.            E-Mail: leonid@RST.HellNet.Org
P.O.Box 8077, Ramat-Gan 52180, Israel      WRS Distributor

                      APPLICATION NOTE
            Moving Applications onto VxWorks 5.1

                      Leonid Rosenboim
            RST Software Industries Ltd. Israel.

                          ABSTRACT

          This memo summarizes our experience  of  sup-
     porting  users  to  port  their  applications from
     VxWorks 5.0.x to 5.1. Common problems  are  listed
     and  their  recommended  solution.   Comments  and
     experiences from other users have also been incor-
     porated.

Compiler issues

One of the most significant changes in VxWorks  5.1  is  the
use  of  a  new compiler which is completely ANSI compliant,
and modification of all include files for  ANSI  compatibil-
ity.  It is recommended that with this new compiler the code
should be compiled in ANSI  mode.  That  however  may  cause
great difficulties - the application may require significant
modifications if it has not been written to be ANSI  compli-
ant.

We strongly recommend to invest  that  effort  in  order  to
obtain  a  cleaner  code  and avoid certain run-times errors
which are detected by the compiler.  On the other  hand,  if
time  is critical, use of the -traditional flag under 5.1 is
the short-term solution.

If the code was already written according to ANSI specifica-
tions,  the  compilation  errors  under 5.1 will be few, and
should be examined carefully, since some functions under 5.1
have  new interfaces.  Some of these functions are discussed
below.

There is also one quite annoying problem which  appeared  in
this  new compiler for the mv68040: you can not use floating
point operations in a  function  that  is  connected  to  an
interrupt  with  intConnect(),  this is because the compiler
produces floating-point instructions before it  reaches  the
first  "C"  statement, thus using fppSave() and fppRestore()
does not help. To overcome this create a stub function  that
is  connected  to  the  interrupt, calls fppSave(), then the
"real" function, and then fppRestore() and exists.

It is worth mentioning that this new compiler has  got  many
new  features,  some  of which are non-standard. Still it is
recommended to browse through the compiler  manual  to  know
about these new features.

VMEbus and the MMU

From the functional stand-point, probably the  most  radical
change in 5.1 is the use of the MMU on some processors. Even
without the optional VxVMI module, VxWorks 5.1 makes use  of
the  Memory  Management  Unit  to define Virtual-to-Physical
address translation maps.  The BSP file sysLib.c defines the
initial  translation  map,  and the option INCLUDE_MMU_BASIC
enables its use by the MMU support library.

Mostly the MMU does not cause any trouble, with  the  excep-
tion  of  applications  that use VMEbus extended space (e.g.
A32). In 5.1, if INCLUDE_MMU_BASIC is defined, only  a  part
of that A32 VME space is available to the processor.

If a BUS ERROR is experienced when attempting  access  to  a
VME  A32 device after moving to 5.1, the MMU is probably the
cause, and there are three possible solutions to this  prob-
lem, which are:

(1)  Comment out the line which defines INCLUDE_MMU_BASIC in
     the file config.h in the BSP directory, thus completely
     disabling the MMU and restoring  5.0.x  behavior.  This
     has  a  significant  drawback,  without this option the
     application will not be able to use Data Cache.  Still,
     this  is  worth  a try just to figure the source of the
     problem.

(2)  Examine the initialization of sysPhysMemDesc  array  in
     sysLib.c  to figure how much VME A32 space was actually
     mapped, and where are its boundaries. This  space  will
     usually  start  at  sysMemTop(),  and  will be 16 or 32
     MBytes in size.  If at all possible, the VME board base
     address  should  be  changed  so  it  will fit into the
     defined mapping, while not overlapping with  any  other
     card  installed.   If  that is not possible because the
     card's address space is just too large, or if there are
     many cards, the last option should be considered.

(3)  Modify the initialization of sysPhysMemDesc is sysLib.c
     to  enlarge  the  mapped  space size. It is practically
     safe to have each entry in  the  table  map  up  to  32
     MBytes  of space. If more space is still required, more
     entries may be added. The practical limit on the number
     of entries depends on the particular processor and MMU.

VxWorks backward compatibility options

VxWorks 5.1 is not completely, but is "mostly" compatible to
the  previous  versions 5.0.x.  There are a number of confi-
guration options that may be defined in configAll.h  to  add
some  code  to  VxWorks  to make 5.1 more compatible.  These
options are:

INCLUDE_DELETE_5_0
     The  5.0.x  delete()  function  has  been  renamed   to
     remove()  and unlink() in 5.1 for the sake of POSIX and
     ANSI compatibility.  Defining  this  options  adds  the
     delete()  function  as  an  alias. This can not be used
     with C++ support.

INCLUDE_ANSI_5_0
     This option makes sure that the  same  ANSI  C  library
     functions  that  where available on 5.0.x are included.
     defining INCLUDE_ANSI_ALL brings in much more of  these
     functions,  and  makes  INCLUDE_ANSI_5_0 obsolete. Thus
     where memory is limited, this option brings in  only  a
     subset  of  ANSI  library that was in the previous ver-
     sion.

INCLUDE_BP_5_0
     VxWOrks 5.1 offers a completely new mechanism  of  com-
     munication  across  the VME backplane. The new stuff is
     included using INCLUDE_SM_NET, but if old boot ROMs are
     still  in use, or if you have a SunOS Back-Plane driver
     running on one of the boards, you're stock with the old
     driver which is enabled using this option.

INCLUDE_SEM_OLD
     This undocumented option enabled semaphores  compatible
     with  VxWorks  4.x.  It  is expected that WRS will drop
     support for these facilities at some point,  users  are
     encouraged to discontinue usage of this facility.

Source Compatibility

However unfortunate it may seem, few functions have  changed
their  calling  prototype  in  5.1,  while keeping their old
names.  If the "-ansi" and "-pedantic" compiler options  are
used, these differences will come out clear by the compiler.
For those stock with "-traditional", these may pose  serious
problems.   In  some  cases adding a simple type cast should
suffice, or the difference may be ignored  altogether,  e.g.
when  an  argument  that  used  to be "int" is now "unsigned
int", and similar differences.

Here are a few functions that we feel require special atten-
tion:

-    The  ld()  function  if   used   programmatically   has
     completely  changed  its  return  value, now instead of
     returning 0 when OK, it returns a pointer, and  a  zero
     (NULL)  is  returned  on  error.   Usage  of  ld() from
     scripts is not affected by that, and that is  the  most
     common  use  of this function, hence the effect here is
     minimal.

-    Functions logMsg() and taskSpawn()  now  have  a  fixed
     number of arguments instead of variable number of argu-
     ments, namely, logMsg() is now limited to 6  arguments,
     and  taskSpawn()  to  10.   These functions where docu-
     mented to have these same fixed numbers of arguments in
     5.0.x, and their implementation had limitted numnber of
     arguments as well. Only the ANSI prototype had variable
     number  of  arguments.  Hence these are not expected to
     cause any real trouble, aside of  compiler  warning  of
     course.

Please refer to VxWOrks 5.1 Release  Notes  document  for  a
complete list of changed functions.

Binary compatibility

For reasons too many to mention it is recommended  that  the
entire  application be recompiled with the compiler supplied
with 5.1, and using the new include files. However, that may
be  not possible in some cases, hence are some tips on where
this might not work.

Modules using macros from ctype.h (e.g. isalpha(), isdigit()
etc.)  will  fail  to  load  on  5.1. Such modules should be
recompiled.

Modules using the macros defined in stdioLib.h of the previ-
ous  version must be recompiled with the 5.1 version of this
include file.  So are any modules that depend on the  inter-
nal  structure  or  size  of  typedef FILE. It has been com-
pletely changed.   Luckily  stdioLib  has  only  two  macros
getc()  and  putc()defined,  and  are  used rarely. Also all
references to macros stdin, stdout, stderr will fail at  run
time.

It is also worth noting that in many occasions binary compa-
tibility does work.

Development Environment

The most important of the development environment  that  has
changed  is  the  way the on-line manual pages are used, now
instead of using the vwman script, the manual is designed to
use  the  standard  UNIX "man" utility. This is definitely a
change for good, however if you just can't live without  the
good  old  "vwman",  the following statement can be added to
your .cshrc to fix it:

        alias vwman "man -P $VX_VW_BASE/man"

                     September 21, 1993

From vlp@mr.picker.com  Tue Sep 21 07:51:05 1993
From: vlp@mr.picker.com (Vic Potter)
Date: Tue Sep 21 07:51:13 PDT 1993
Subject: ping for vxWorks

Hello,

Does anyone know of or have a public domain ping client program for
vxWorks.  From our vxWorks system we need to periodically check to
see if our host unix system is still alive. 

Thanks.

Vic Potter
Picker International
vlp@mr.picker.com

From visicom!VisiCom.COM!trest@nosc.mil  Tue Sep 21 07:51:57 1993
From: Mike Trest <trest@visicom.com>
Date: Tue Sep 21 07:52:09 PDT 1993
Subject: RE: VxWorks 5.1 SCSI/DOS File System Issues
>Subject: VxWorks 5.1 SCSI/DOS File System Issues

>Has anyone had any success using a SCSI hard disk initialized under MS-DOS on
>a 5.1 VxWorks system or a hard disk initialized on VxWorks on an MS-DOS system?
>If I initialize on one, I can't read it on the other.

Steven,  

Under VxWorks you are responsible to "partition" your
own media.  You must provide application code or modifications to 
bootConfig / usrConfig to sort out the partition table created on 
disks formatted on DOS systems.  Likewise, if you format a
hard disk under VxWorks which you intend to use on a DOS machine,
you must create an appropriate partition table.

I have no problem doing this . . . however it does take
a bit of experience with DOS disks.  The quickest way to
get this experience is to use Norton or other utilities
to examine you DOS disk right after a FDISK has been run
to create some DOS partitions.  

BTW, you may have to think about whose boot code you will
put into the primary boot program which is part of the
first disk block which contains the partition table.

..mike..
====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From sugar2!focal.com!john@netcom.com  Tue Sep 21 13:40:51 1993
From: john@focal.com (John Calvin)
Date: Tue Sep 21 13:41:01 PDT 1993
Subject: Lock level set and Interupts.
With the latest discussions regarding the use of intLock, I would like to add
another variable into the intLock discussion.  
I need to lock out only level 4 interrupts on my 147 for a short interval while
doing some low level register transactions.
If I do a plain intLock > Register work > inUnlock sequence, everything seems to
work ok.  That is with the default Lock level of 0x07.  I really dont want to
suppress all my interrupts for this operation, so Ive modified my sequence to
look like the following.

    int oldlevel,intkey;    /* current interrupt level mask and lockout key */  

    /* Get current Lock Level */
    oldlevel = intLockLevelGet();
    logMsg ("Old int lock level is %d\n",oldlevel);

    /* Lockout Level 4 VMEbus Interrupts */
    intLockLevelSet (INT_LEVEL_4);  /* INT_LEVEL_4 = 0x04*/
    intkey = intLock ();

    logMsg ("locked out level 4 interrupts \n");

    /* set level register */

     << Do some critical stuff here >>

    /* Remove Interrupt level 4 inhibit  mask */
    intLockLevelSet (oldlevel);
    intUnlock (intkey);

Needless to say, if this worked I would'nt be sending this mail message.
In fact, I never see any of my logMsg's (Even the one before I do the intLock).
If I replace INT_LEVEL_4 with INT_LEVEL_7 everything works fine, and I get my
messages.  Does anyone have any suggestions as to what I'm doing wrong, and how
to effectivly mask out level 4 interrupts.
Thanks in advance..  John Calvin

From ah442@slc10.ins.cwru.edu  Tue Sep 21 19:11:44 1993
From: ah442@cleveland.freenet.edu (Erik C. Orange)
Date: Tue Sep 21 19:11:54 PDT 1993
Subject: "When Worlds Collide..."

This is sort of a "FYI / Yes You Can Do That"...

In the midst of our VxWorks project development, a special
circumstance prevented us from booting our target CPU from
the usual SPARCstation.  Instead, the CPU (a Heurikon HKV4F)
managed to boot off a VAX 4100.  I FTPed vxWorks and vxWorks.sym
to the VAX, and the target booted via FTP without a hitch.  I
suppose one could say "FTP should handle that transparently, etc.",
but considering filesystem differences, case insensitivity of the VAX,
etc., it was nice to see that it actually DID work.  Plus the VAX
was hundreds of miles away across a WAN, which also made it
interesting (and slooooow).

Speaking of Heurikon, I have to add my 2 cents and say that we've
had nothing but GOOD things to say about them.  They have been
helpful, responsive, and flexible to our needs (unfortunately,
sad to say, WRS is not).  Heurikon's hardware & software engineers
are RESPONSIVE, courteous, and very knowledgeable in helping us
SOLVE our systems development issues. And (so far...), we haven't
had any bad hangups with their BSPs, etc.  Overall, we're doing OK
with Heurikon.

Which brings me to...WRS.  I'll make this short.  The power and
flexibility of your RTOS, and the potential MARKETS that this
power brings, must be astounding.  We are building next-generation
process control systems with VxWorks, and it has been the ONLY
solution that answers ALL the questions.  DON'T limit your RTOS
with an outdated LICENSING POLICY.  The varied projects of today
just don't work like that anymore.  I'm faced with the task of
"proving" VxWorks on its technical merits, which I will do...however,
VxWorks has to make up a substantial amount of ground in our
company thanks to the inflexbile licensing policy.

I'm open to comments!

Erik

--
Erik C. Orange                        FRD Industrial Automation
Systems Engineer                      Avery-Dennison Corporation
ah442@cleveland.Freenet.Edu           Concord, OH

From daemon@vxw.ee.lbl.gov  Wed Sep 22 04:01:52 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep 22 04:02:02 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep 22 04:01:40 PDT 1993

        Subject: FTP
        Subject: BOOTP/TFTP problems...
        Subject: VME bus access problem

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: FTP
Date: Tue, 21 Sep 1993 15:40:05 GMT
From: jprice@lds.loral.com (Jeffrey Price, 6823)
Organization: LORAL Data Systems
Keywords: FTP
Message-ID: <1993Sep21.154005.27610@lds.loral.com>
Reply-To: jprice@lds.loral.com
Sender: news@lds.loral.com

Does anyone know whether VxWorks supports the "mkdir" command with FTP.

If so what version of vxWorks does this.

If not, is it planned for any future releases ?

Thanks

Jeff Price

---------------------------

Newsgroups: comp.os.vxworks
Subject: BOOTP/TFTP problems...
Date: Tue, 21 Sep 1993 18:55:38 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.93Sep21145538@squash.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Sender: news@cs.cmu.edu (Usenet News System)

I'm experimenting with BOOTP/TFTP now available under 5.1, and so far
things look pretty good - except for the following:

##############################################################################

Attaching network interface es0... done.
Getting boot parameters via network interface es0.
Bootp Server:128.2.44.41
    Boot file: /usr/vxworks/boot/vxWorks
    Boot host: 128.2.44.41
    Boot device Addr (es0): 128.2.44.207
    Subnet mask: 0xffff0000
Attaching network interface lo0... done.
Loading... 360376
128.2.44.41:/usr/vxworks/boot/vxWorks: tftp transfer failed: error 0x3d0004

Error loading file: errno = 0x44.

##############################################################################

Now, the strange part. If I then change my boot flags to 0x80 (TFTP
boot only), and leave the other parameters exactly the same (as
previously supplied by bootpd), the boot sequence works just fine!
The error code 0x3d0004 maps to "S_objLib_OBJ_TIMEOUT", so something
in the TFTP transfer gets stuck. But why does this only happen if
there was contact with the bootpd just prior to the loading ?
I can't find any hints in the documentation about this. Any ideas?

While I'm on the subject, how would I specify in my bootptab the
"host inet (h)" parameter, i.e. the host to load the boot file from?
The Programmer's Guide says you can, but doesn' say how. It always
defaults to the same machine running the bootpd, which isn't
necessarily what we want...
Any advice would be appreciated.
Thanks,

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
      If you aren't part of the solution, you're part of the precipitate.

---------------------------

Newsgroups: comp.os.vxworks
Subject: VME bus access problem
Date: 22 Sep 1993 05:16:29 GMT
From: rab@csg.lbl.gov (Robert Belshe)
Organization: Lawrence Berkeley Laboratory, California
Message-ID: <34091@dog.ee.lbl.gov>

I am trying to configure a MVME167 (4MB) to access two 
VME memory modules, using vxWorks 5.1.

The CES module is a 1MB unit, but it has some control registers, so
requires 2MB of address space.

The MMI module is a 32MB unit.

With CES memory at 0x1000000, "d 0x1000000" works from the shell 
			      but gets bus error from boot rom.

With CES memory at 0x2000000, both shell and boot rom get bus error 
			      when attempting to access CES memory.
			      

With MMI memory at 0x4000000, "d 0x4000000" works from the boot rom
			      but gets bus error when done from the
			      shell.

Help from anyone who has experienced a similar problem would
be appreciated.
Thanks,  Bob
- -----------------------------------------------------------------------

Here is a snippet from our current sysLib.c.

/* Globals */

PHYS_MEM_DESC sysPhysMemDesc [] =
    {
    /* adrs and length parameters must be page-aligned (multiples of 0x2000) */

    /* ram */
    {
    (void *) LOCAL_MEM_LOCAL_ADRS,
    (void *) LOCAL_MEM_LOCAL_ADRS,
    0x2000000,                /* 32 Mbytes (adjust if necessary) */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE
    },

    /* 9/21/93   space for 5 ces modules (2MB each) 
             0x2000000 - 0x29fffff                        */
    {
    (void *) 0x2000000,
    (void *) 0x2000000,
    0xa00000,                           /* 10 Mbytes */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },

    /* 9/21/93   space for MM-6390 module (32MB)    
             0x4000000 - 0x5ffffff                        */
    {
    (void *) 0x4000000,
    (void *) 0x4000000,
    0x2000000,                          /* 32 Mbytes */
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },

    /* remainder of sysLib.c is unchanged      */

   +----------------------------------------------------------+
   |  Robert Belshe                       rab@lbl.gov         |
   |  46A-1123                            Voice 510-486-7509  |
   |  Lawrence Berkeley Laboratory        FAX   510-486-5936  |
   |  Berkely, CA 94720                                       |
   +----------------------------------------------------------+
- -- 
   +----------------------------------------------------------+
   |  Robert Belshe                       rab@lbl.gov         |
   |  46A-1123                            Voice 510-486-7509  |
   |  Lawrence Berkeley Laboratory        FAX   510-486-5936  |

---------------------------

End of New-News digest
**********************

From rayssd!ssd.ray.com!fjr@uunet.uu.net  Wed Sep 22 05:27:15 1993
From: Roeber <fjr@ssd.ray.com>
Date: Wed Sep 22 05:27:30 PDT 1993
Subject: Re: Lock level set and Interupts.
John Calvin writes:
>   
>  With the latest discussions regarding the use of intLock, I would like
>  to add another variable into the intLock discussion.  I need to lock
>  out only level 4 interrupts on my 147 for a short interval while doing
>  some low level register transactions.  If I do a plain intLock >
>  Register work > inUnlock sequence, everything seems to work ok.  That
>  is with the default Lock level of 0x07.  I really dont want to suppress
>  all my interrupts for this operation, so Ive modified my sequence to
>  look like the following.

>      /* Get current Lock Level */
>      oldlevel = intLockLevelGet();
>      logMsg ("Old int lock level is %d\n",oldlevel);
>  
>      /* Lockout Level 4 VMEbus Interrupts */
>      intLockLevelSet (INT_LEVEL_4);  /* INT_LEVEL_4 = 0x04*/
>      intkey = intLock ();
>  
>      logMsg ("locked out level 4 interrupts \n");
>  
>      /* set level register */
>  
>       << Do some critical stuff here >>
>  
>      /* Remove Interrupt level 4 inhibit  mask */
>      intLockLevelSet (oldlevel);
>      intUnlock (intkey);

This is real dangerous.  VxWorks makes the assumptions that it can protect
critical regions in its code by calling intLock.  About the only reason I
could see for changing the intLock level would be if you had a real critical
interrupt that you couldn't afford latency on.  You would have to realize
that once you dropped the level, the interrupt handlers for all higher level
interrupts would have to be careful to call NO VxWorks functions.  I am
guessing that your system has some other interrupts at higher levels than
level 4; how about the clock or especially the serial channels.  If that
is the case, then I am surprised all you see is not logMsg output.  You
could end up with a crash if multiple interrupts at higher levels occured
and all called VxWorks functions that manipulated critical data structures
in an overlapping fashion as would now be possible since their use of intLock
would no longer be effective.  My advice is, don't worry about locking out
all interrupts.  If your critical code segment is really long, then you
probably shouldn't be doing the stuff in the interrupt handler anyway;
use a semaphore to signal some task to do the real work.   Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |

From imp!rst!RST.HellNet.org!leonid@spud.hyperion.com  Wed Sep 22 06:48:33 1993
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Wed Sep 22 06:48:45 PDT 1993
Subject: Signals on 5.1
Here is a small quote from the VxWorks 5.1 release notes that is very
important, it makes the signals on VxWorks usable at last:

    Blocked tasks can now receive signals. In 5.0, if a signal was sent to
    a blocked (pending) task, the signal was ingored until after the task
    became unblocked.  In 5.1, a blocked task stops waiting, invokes the
    signal handler, then resumes waiting, after the signal handler exits.
    ...

This fact is worthy to note when moving to 5.1.
-----------------------------------------------------------------------
Leonid Rosenboim                           Voice/Fax: +972-3-72-44-98
R S T  Software Industries Ltd.            E-Mail: leonid@RST.HellNet.Org
P.O.Box 8077, Ramat-Gan 52180, Israel      WRS Distributor

From ihw@rtp.co.uk  Wed Sep 22 07:37:28 1993
From: ihw@rtp.co.uk (Ian Willats)
Date: Wed Sep 22 07:37:38 PDT 1993
Subject: SCSI DMA on MVME-167

Mike Anderson writes:

>     particular board.  For example, why is the SCSI performance of the
>     MVME167 boards so absolutely dismal?  Because WRS doesn't support
>     the DMA core facilities provided on-chip by the NCR 53C710 SCSI
>     controller.  If you want faster SCSI performance, you either WIY

In our experience, the '167 has reasonable SCSI performance when used with a
single target device ... in any case, the standard WRS drivers certainly _do_
use the NCR 710's on-board DMA controller because it's about the only way the
chip can move data around when it's running a SCRIPTS program.  (There's no
DMA code in the BSP though - it all happens in the 710 driver itself.)

I suspect the most significant performance improvements would come from
supporting disconnect/reconnect (if you're using multiple SCSI targets) and
synchronous data transfers.  I believe WRS are working on both features.

Regards,

Ian Willats
RTP

From ihw@rtp.co.uk  Wed Sep 22 09:56:57 1993
From: ihw@rtp.co.uk (Ian Willats)
Date: Wed Sep 22 09:57:07 PDT 1993
Subject: Multiple Initiators On Scsi; VxWorks 5.1

Steven Stern writes:

> Does anyone know of a port to the Motorola MVME167 board which supports
> SCSI 2 or multiple initiators?

Yes; please contact me directly (ihw@rtp.co.uk) for details.  How much of
SCSI 2 do you need ?  For example, fast/wide transfers, tagged command
queuing, or just the basics ?

From daemon@vxw.ee.lbl.gov  Thu Sep 23 04:01:28 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 23 04:01:37 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 23 04:01:17 PDT 1993

        Subject: Re: "When Worlds Collide..."
        Subject: VSB Anyone?
        Subject: Re: AM29200 ( or Am29K) with VxWorks

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: "When Worlds Collide..."
Date: Wed, 22 Sep 93 15:45:23 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1993Sep22.154523.11957@ll.mit.edu>
References: <9309220211.AA23952@slc10.INS.CWRU.Edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --
In article <9309220211.AA23952@slc10.INS.CWRU.Edu>, ah442@cleveland.freenet.edu (Erik C. Orange) writes:
|>
|>
|>This is sort of a "FYI / Yes You Can Do That"...
|>
|>Which brings me to...WRS.  I'll make this short.  The power and
|>flexibility of your RTOS, and the potential MARKETS that this
|>power brings, must be astounding.  We are building next-generation
|>process control systems with VxWorks, and it has been the ONLY
|>solution that answers ALL the questions.  DON'T limit your RTOS
|>with an outdated LICENSING POLICY.  The varied projects of today
|>just don't work like that anymore.  I'm faced with the task of
|>"proving" VxWorks on its technical merits, which I will do...however,
|>VxWorks has to make up a substantial amount of ground in our
|>company thanks to the inflexbile licensing policy.
|>
|>I'm open to comments!
|>
|>
|>Erik
|>
|>--
|>Erik C. Orange                        FRD Industrial Automation
|>Systems Engineer                      Avery-Dennison Corporation
|>ah442@cleveland.Freenet.Edu           Concord, OH
|>

I have to strongly agree. Their licensing structure goes beyond unreasonable. It
may be fine for their license to Toyota for doing an ABS system where they will
make thousands of them, but it is unusual to build even two systems on a "project"
here....  Its hard to win a bid when you have to include $25K each time....

- -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: VSB Anyone?
Date: Wed, 22 Sep 1993 19:55:32 GMT
From: davisrj@arts.dfrf.nasa.gov (Roy Davis)
Organization: NASA Ames-Dryden Flight Research Facility, Edwards, CA
Message-ID: <1993Sep22.195532.3693@news.dfrf.nasa.gov>
Sender: news@news.dfrf.nasa.gov (Usenet news)

Hi all,

Has anyone out there done much with VSB busses.  We're running Force40's with
Eagle02 modules and MM-6326 Dualport Memory (64MB) on then VSB bus.  We can
access the VSB bus through the reserved space at 0xfd000000 but we'd like to be
able to use 32-bit addressing in the extended addressing space to work so that
we can get to more than 16MB.  The docs I've read seem to indicate it is
possible, but everything I've tried hasn't worked.

Anyone have any ideas?

						- Roy
- -- 
The following is the sig that would appear if I knew what I was doing:
=========================================================================
= Roy Davis is :			= TTFN - VF102                  =
=	davisrj@arts.dfrf.nasa.gov	= Neophyte (ne-o-fite) -        =
=	davisrj@arts2.dfrf.nasa.gov	=   newbie + <2 years exp       =
=========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: AM29200 ( or Am29K) with VxWorks
Date: Thu, 23 Sep 1993 03:12:15 GMT
From: bharath@iti.gov.sg (Bharath Narayanan (MMC))
Organization: Information Technology Institute, National Computer Board, Singapore.
Message-ID: <1993Sep23.031215.3718@iti.gov.sg>
Sender: news@iti.gov.sg (News Admin)

Could anyone provide HELP/Suggestions/recomentations/comments about the
usage of AM29200 RISC microcontroller with VxWorks!
Thanks in advance.
BTW, our application is for a Telecom product.
Bharath

bharath@iti.gov.sg

---------------------------

End of New-News digest
**********************

From nftdf!arvids@norway.eu.net  Thu Sep 23 06:49:02 1993
From: nftdf!arvids@norway.eu.net (Arvid Sternang)
Date: Thu Sep 23 06:49:17 PDT 1993
Subject: atan2 malfunction
To all of you using VxWorks version 5.0 (or older?): There is a problem with
the atan2 function.
Running a small test-program under VxWorks 5.0 gives the following:

trews->version
VxWorks (for Motorola MVME-147) version 5.0.
Kernel: WIND version 2.0.
Made on Thu Jun 17 14:19:06 MET DST 1993.
-----
trews->ld  <atantest.o
value = 0 = 0x0
trews->atan2Test
Test of atan2 function
atan2 test: x= 1.000000, y= 1.000000, result from atan2= 1.570796
atan2 test: x= 1.000000, y= -1.000000, result from atan2= -1.570796
atan2 test: x= -1.000000, y= -1.000000, result from atan2= -1.570796
atan2 test: x= -1.000000, y= 1.000000, result from atan2= 1.570796
value = 0 = 0x0
trews->

The same program run on my Sun SPARCstation:
sun75:85% arch -k
sun4c
sun75:86% a.out
Test of atan2 function
atan2 test: x= 1.000000, y= 1.000000, result from atan2= 0.785398
atan2 test: x= 1.000000, y= -1.000000, result from atan2= -0.785398
atan2 test: x= -1.000000, y= -1.000000, result from atan2= -2.356194
atan2 test: x= -1.000000, y= 1.000000, result from atan2= 2.356194
sun75:87% 

The bug is fixed in VxWorks 5.0.2

Arvid Sternang
Norsk Forsvarsteknologi,
Defence Systems Division,
Dept. F4B3
Kongsberg, Norway

From stan@rti.com  Thu Sep 23 09:30:30 1993
From: stan@rti.com (Stan Schneider)
Date: Thu Sep 23 09:30:40 PDT 1993
Subject: atan2 under 5.0

>> Submitted-by nftdf!arvids@norway.eu.net  Thu Sep 23 06:49:02 1993
>> Submitted-by: nftdf!arvids@norway.eu.net (Arvid Sternang)
>>  
>> To all of you using VxWorks version 5.0 (or older?): There is a problem with
>> the atan2 function.

The problem is actually with all math functions that take two arguments.
Here's a patch; install it in your "startup" script:

----- Begin Included Message -----

pMathPatch = fmod + 0x12;
*pMathPatch = (short) 0x10;
pMathPatch = atan2 + 0x0e;
*pMathPatch = (short) 0x10;
pMathPatch = pow + 0x16;
*pMathPatch = (short) 0x10;
pMathPatch = pow + 0x28;
*pMathPatch = (short) 0x10;
pMathPatch = pow + 0x46;
*pMathPatch = (short) 0x10;
pMathPatch = pow + 0x4c;
*pMathPatch = (short) 0x10;
 
 
I think the script should work the same for 5.0.1, but
the names change.  They all start with "mathHard", and
the first character of the old name gets capitalized.
So, instead of "fmod" it would be "mathHardFmod", etc.
 
In all cases, the 0x10 should be replacing a 0x0c.
 

----- End Included Message -----

Sounds like it's time for an upgrade.  This is fixed in all "modern" versions.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From reidson@nexus.aer.loral.com  Mon Sep 27 12:12:52 1993
From: reidson@nexus.aer.loral.com (Ricky Eidson x5988)
Date: Mon Sep 27 12:13:07 PDT 1993
Subject: email addres change

Please change my email address 	from: reidson@asterisk.aer.loral.com
				to  : reidson@nexus.aer.loral.com

Thanks

Rick Eidson

From visicom!VisiCom.COM!trest@nosc.mil  Mon Sep 27 18:19:51 1993
From: Mike Trest <trest@visicom.com>
Date: Mon Sep 27 18:20:02 PDT 1993
Subject: Extension to VxWorks ld()

From daemon@vxw.ee.lbl.gov  Tue Sep 28 04:01:57 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Sep 28 04:02:18 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Sep 28 04:01:43 PDT 1993

        Subject: SCSI Scripts
        Subject: Will NT Kill RTOSs, VME?
        Subject: vxWork EPROM burning
        Subject: Sr. S/W Engineer Real-Time / NCalif.
        Subject: Re: BOOTP/TFTP problems...
        Subject: Re: "When Worlds Collide..."
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: DMA functionality on the Force CPU30 board
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Test                     
        Subject: Test                     
        Subject: Test                     
        Subject: Info                     
        Subject: Info                     
        Subject: Test                     
        Subject: Test                     
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: vxworks header files vs. unix header files
        Subject: Re: DMA functionality on the Force CPU30 board
        Subject: Re: vxworks header files vs. unix header files
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Re: vxworks header files vs. unix header files
        Subject: VxWorks driver for Ethernet SBus card
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Extension to VxWorks ld()
        Subject: VxWorks driver for Raster Graphics cards
        Subject: Video Capturing and Compression Support w/ vxWorks
        Subject: GPIB support
        Subject: Re: Will NT Kill RTOSs, VME?
        Subject: Re: vxworks header files vs. unix header files

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI Scripts
Date: Thu, 23 Sep 1993 14:06:26 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <1993Sep23.140626.16619@nrtpa038.bnr.ca>
Sender: billag@b4pphff (Bill Gutknecht)

	Does anyone know where I can get hold of the SCSI Scripts
	compiler for the NCR53C710?  I'd need to run it on HP/UX 8.07.

	Thanks.

- ------------------------------------------------------------------------------
Bill Gutknecht                  "When I die, I will go before Crom and he will 
Bell Northern Research         	 ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC	 not know it, he will cast me out of Valhalla
billag@bnr.ca			 and laugh at me ... "
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Will NT Kill RTOSs, VME?
Date: 23 Sep 93 15:12:24 GMT
From: sp_sjp@space.alcbel.be (Simon Pryor)
Organization: Alcatel Bell Telephone
Keywords: NT RTOS VME
Message-ID: <2112@alcbel.be>
Reply-To: sp_sjp@space.alcbel.be
Sender: root@alcbel.be

I've just been catching up on articles and magazines. There is
a lot of dicussion about the impact Microsoft NT will have on
the PC and Workstation markets, and the response by Unix vendors
with COSE, etc, etc.

One thing that I haven't seen mentioned (I may well have missed it)
is the impact it may have on the real-time embedded markets. I'd be
interested in peoples thoughts on the subject and any relevant gossip.

Many RTOSs have florished because there have been no other multi-tasking
OSs with the required characteristics. Eg. Deterministic, prioritized, 
preemptive schedulers, small interrupt latencies, etc, etc.

NT seems to change that. It has a preemptive multi-tasking,
multi-threaded kernel. Networking is integrated. It is scalable from
standalone PCs to multi-processor servers, etc. I don't know many details
about the performance, and whether it is fast enough to handle hard RTOSs.
Certainly, its 12-16Mbyte RAM, 80Mbyte disk VGA requirements, will exclude
it from some types of systems. NT is also destined to run on other than
Intel hardware: Alphas, MIPS RISC, PowerPC.

Any impact may well only start a few years from now, but it is interesting
to get the crystal ball out occcasionally.

One area where it could obviously impact, is on the RTOSs that currently run
on standard PC hardware, QNX, real-time Unixes, etc.

Certainly, in the host/target type of cross development (VxWorks, VRTX, etc),
many vendors may well support NT for the host development system instead of
or as well as Unix.

I'm sure that there will be many niche markets where NT won't reach. For
instance, small promable embedded micro-controllers, with no disk or
monitor, etc.

But in the large networked real-time systems, I could see it having a
significant impact. There could be potentially large cost savings by using
standardized hardware.

And what about VME & Futurebus+? A lot of the RT market typically ran
on Motorolla 680x0 boards in a VME rack. Now that Motorolla are moving
to the PowerPC (is this the beginning of the end of the 680x0?), will
VME & Futurebus+ be threatened with "standard" PC/Workstation hardware.
I'm sure not totally, but a big chunk of the market could go along with
many RTOSs. Again, the cost of using standard Workstation hardware with
NT and Borland C++ for NT (no separate host & target), could well be an
order of magnitude less than a more conventional VME RTOS setup.

So, what do you think? I realise it is difficult to predict the future,
but as many of our jobs depend on it (RTOS vendors, VME board manufacturers,
Application software engineers, Microsoft share-holders) it is worth
a few thoughts.

Simon Pryor
sp_sjp@space.alcbel.be

---------------------------

Newsgroups: comp.os.vxworks
Subject: vxWork EPROM burning
Date: 23 Sep 1993 17:04:30 GMT
From: nam@peregrine.esl.com (Nam N. Nguyen)
Organization: esl.com
Message-ID: <27skuu$drd@gatekeeper.esl.com>

I am attempting to burn the vxWorks system software (and my application)
into EPROMs using an EPROM programmer called UNISITE.

I am having a lot of problems, please help:

1.  The programmer asks for I/O format (for data transferring):
    Netter having using this programmer, please let me know which I/O
    format to use?  (width of word?, MotorolaXOR, binary, ...)

2.  Using a FORCE 68K/40B target board, my current EPROM pair are 
    of the type: AM27C1024.  What does this mean in term of my total
    capacity?

3.  Related to # 2 above, if my vxWorks (boot+application,...) image
    file has the size:

	vxWorks.st_rom		357045 (bytes)
	vxWorks.st_rom.hex	992661 (bytes)  (S-record, I think)

    Would the above pair of EPROMs work?  or do I need to buy another
    pair of EPROM device with more capacity?

Thank you very much,

Nam N.

PS.  Please send email to me at nam@esl.com

---------------------------

Newsgroups: misc.jobs.offered,comp.os.vxworks
Subject: Sr. S/W Engineer Real-Time / NCalif.
Date: 23 Sep 93 19:52:49 GMT
From: staffing@gvgpsa.gvg.tek.com (Staffing)
Organization: The Grass Valley Group, Inc.
Message-ID: <7420@gold.gvg.tek.com>
Followup-To: misc.jobs.offered
Reply-To: staffing@gvgpsa.gvg.tek.com
Sender: news@gold.gvg.tek.com

- ---
The Grass Valley Group is looking for Senior Software Engineers with experience in the design of real-time systems.

We are looking for candidates who have the following experience:

Required:
* Experience with real-time operating systems
* Design of embedded systems
* Design of I/O and device drivers
* Unix and C
* Software design and implementation methodology
* 5+ years of experience in team environment

Desired:
* VxWorks
* Knowledge of hardware
* Experience using in-circuit emulators, oscilloscopes and logic analyzers
* Video or computer graphics

The Grass Valley Group (GVG) is the recognized leader in the advancement of video production and distribution processing equipment.

We are located in the heart of California's historic gold country.

We support a drug-free work environment and all employment offers are contingent upon successful completion of our pre-employment drug test. Grass Valley Group is an equal opportunity/affirmative action employer and encourages diversity in the workplace.

If you are interested and have the requirements listed above, please send your resume and a cover letter to:

email:      staffing@gvgpsa.gvg.tek.com (ascii only)
fax:        (916) 478-3808
U.S. mail:  Staffing 9E
            Grass Valley Group
            P.O. Box 1114, Dept. RM/P1
            Grass Valley, CA 95945-1114

Please no phone calls.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: BOOTP/TFTP problems...
Date: 23 Sep 1993 20:33:57 GMT
From: gwr@mc.com (Gordon W. Ross)
Organization: Mercury Computer Systems, Inc.
Message-ID: <GWR.93Sep23163407@walnut.mc.com>
References: <HMP.93Sep21145538@squash.frc.ri.cmu.edu>
Reply-To: gwr@mc.com

In article <HMP.93Sep21145538@squash.frc.ri.cmu.edu>
hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:

> Newsgroups: comp.os.vxworks
> From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
> Nntp-Posting-Host: squash.frc.ri.cmu.edu
> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
> Organization: Field Robotics Center, CMU
> Date: Tue, 21 Sep 1993 18:55:38 GMT
> 
> 
> I'm experimenting with BOOTP/TFTP now available under 5.1, and so far
> things look pretty good - except for the following:
> 
> ##############################################################################
> 
> Attaching network interface es0... done.
> Getting boot parameters via network interface es0.
> Bootp Server:128.2.44.41
>     Boot file: /usr/vxworks/boot/vxWorks
>     Boot host: 128.2.44.41
>     Boot device Addr (es0): 128.2.44.207
>     Subnet mask: 0xffff0000
> Attaching network interface lo0... done.
> Loading... 360376
> 128.2.44.41:/usr/vxworks/boot/vxWorks: tftp transfer failed: error 0x3d0004
> 
> Error loading file: errno = 0x44.
> 
Make sure you can read the file using TFTP.  If your TFTP server is
a typical SunOS host, it runs a "secure" TFTP server that restricts
access to files under the /tftpboot directory.  Put your boot file
(and the symbol file too) in /tftpboot and you should be all set.

You can test the TFTP service by running tftp on another host, i.e.:
% cd /tmp
% tftp boothost
tftp> get no-such-file
Error code 1: File not found
tftp> get vxWorks
Received 478573 bytes in 4.1 seconds
tftp> quit

> Now, the strange part. If I then change my boot flags to 0x80 (TFTP
> boot only), and leave the other parameters exactly the same (as
> previously supplied by bootpd), the boot sequence works just fine!

Yes, because the PROM is using "rsh cat file" to load the kernel.

> While I'm on the subject, how would I specify in my bootptab the
> "host inet (h)" parameter, i.e. the host to load the boot file from?
> The Programmer's Guide says you can, but doesn' say how. It always
> defaults to the same machine running the bootpd, which isn't
> necessarily what we want...

The CMU bootp server (version 2.1) does not supportd that, but
if you get version 2.2 you can do it.  It has documentation too!

Unfortunately, CMU bootp-2.2 is "alpha", and I'm not sure anyone is
still maintaining it.  I tried to reach the authors to offer some
enhancements I made to the program, with no success so far.

It does not appear that the 2.2 sources are available anywhere
at this point (at least "archie" can't find them) so if there is
sufficient interest, I can make bootp-2.2 available here.

> Any advice would be appreciated.
Buy low, sell high.  (Snicker, snicker :-)

> Thanks,
> 
> -Henning
> 
> --
> Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
> Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
> ------------------------------------------------------------------------------
>       If you aren't part of the solution, you're part of the precipitate.

- --
Gordon W. Ross  		Mercury Computer Systems
gwr@mc.com      		199 Riverneck Road
508-256-1300			Chelmsford, MA 01824-2820

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: "When Worlds Collide..."
Date: Fri, 24 Sep 1993 09:21:48 GMT
From: ebg@hoshi.hip.atr.co.jp (Ed Gamble)
Organization: ATR Human Information Processing Research Labs., Japan
Message-ID: <EBG.93Sep24092148@hoshi.hip.atr.co.jp>
References: <9309220211.AA23952@slc10.INS.CWRU.Edu> <1993Sep22.154523.11957@ll.mit.edu>
Sender: news@hip.atr.co.jp (USENET News System)

In articlesinger@ll.mit.edu (Matthew R. Singer) writes:

   From: singer@ll.mit.edu (Matthew R. Singer)
   Date: Wed, 22 Sep 93 15:45:23 GMT

   --

   I have to strongly agree. Their licensing structure goes beyond unreasonable. It
   may be fine for their license to Toyota for doing an ABS system where they will
   make thousands of them, but it is unusual to build even two systems on a "project"
   here....  Its hard to win a bid when you have to include $25K each time....

Not to disagree with your point - but to provide some information....

The price for VxWorks 5.1 with one BSP in Japan is just under 5,000,000
Yen.  A second license is 50% less.  If you want VxMP and VxVMI add
1,000,000 Yen.  WindX add 1,000,000 Yen.  VxSim add 1,000,000.  1-4 target
licenses are 120,000 Yen each, 5-9 goes for 96,000 Yen each.

So Toyota pays nearly US$ 50,000.

Incidently, while the Yen has dropped from 140 Yen/$ to the current 105
Yen/$ during my stay in Japan and awareness of VxWorks, the price of
VxWorks in Japan has remain nearly constant.

Inappropriate (for this newsgroup) note: In spite of the dollars drop, the
price of most ever other US imported product has *not been* reduced...
doesn't bode well for the US Govs "raise-the-Yen -> lower-the-price ->
increase-exports -> reduce-the-deficit" plan.  But that's a simplistic
statement on the wrong newsgroup....)

- -- Ed

Ed Gamble
Invited Researcher
ATR Human Information Processing
  Research Laboratory
2-2 Hikari-dai, Seika-cho, Soraku-gun
Kyoto 619-02 JAPAN

Phone: +81-7749-5-1036
Fax:   +81-7749-5-1008
Email: ebg@hip.atr.co.jp

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: 23 Sep 1993 22:58:18 GMT
From: alfredb@pogo.wv.tek.com (Alfred Brown)
Organization: Tektronix, Inc. Wilsonville
Keywords: NT RTOS VME
Message-ID: <27t9ma$p6o@gazette.wv.tek.com>
References: <2112@alcbel.be>
Reply-To: alfredb@pogo.WV.TEK.COM

In article <2112@alcbel.be>, sp_sjp@space.alcbel.be (Simon Pryor) writes:
> I've just been catching up on articles and magazines. There is
> a lot of dicussion about the impact Microsoft NT will have on
> the PC and Workstation markets, and the response by Unix vendors
> with COSE, etc, etc.
> 
> So, what do you think? I realise it is difficult to predict the future,
> but as many of our jobs depend on it (RTOS vendors, VME board manufacturers,
> Application software engineers, Microsoft share-holders) it is worth
> a few thoughts.
> 
> Simon Pryor
> sp_sjp@space.alcbel.be
> 

I'm not at all familiar with NT, but it seems that when looking into the
crystal ball, fuzzy logic systems ought to be factored into the future outlook
too.  Everyone is looking to turn more complicated designs in shorter time.
My limited experience/knowledge with fuzzy logic suggests that it can deliver
robust solutions with cheap hardware/tools/talent.  I am also aware that many
software professionals do not believe that the preceding statement is true in
any sense.  Any thoughts out there?

- -- 
Alfred Brown, Sr. Software Engineer, Graphics Printing & Imaging Division,
Tektronix, Inc.  P.O. Box 1000  MS 63-424  Wilsonville, Oregon  97070-1000
Ph:(503) 685-3698      FAX:(503) 682-1183  email: alfredb@pogo.wv.tek.com
disclaimer: I do not speak for Tektronix, Inc.,  nor does it speak for me.

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Fri, 24 Sep 1993 06:16:29 GMT
From: emil@shell.portal.com (emil rojas)
Organization: Portal Communications Company
Keywords: NT RTOS VME
Message-ID: <CDuHFK.HLn@unix.portal.com>
References: <2112@alcbel.be>
Sender: news@unix.portal.com

I agree with your thesis, NT will have a big impact on the RTOS
market.  I think this will first be seen at the low end, i.e.
applications that can use real prioritied tasks, but for which
the CPU is not being pushed.  Beyond that, I think we will have
to wait and see how well NT handles these applications.

I have recently worked on two applications that I feel are in
this category.  One that needs just a little real time, and would
benefit greatly by having access on the same platform to standard
spread sheet and WP tools,  And the other that is using windows
now and would be improved by having real tasks.  If I were
starting these projects today I would use NT.

emil

- --
Emil Rojas  emil@shell.portal.com               There is truth,
(408) 973-0603                                  but no one knows what it is.
Cognisys  -- Software Systems Development       My opinions are my own,
San Jose, CA 95129-2205                         nobody else works here.

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Fri, 24 Sep 1993 05:29:23 GMT
From: rgallen@muug.mb.ca (Rennie Allen)
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Keywords: NT RTOS VME
Message-ID: <1993Sep24.052923.2136@muug.mb.ca>
References: <2112@alcbel.be>

In <2112@alcbel.be> sp_sjp@space.alcbel.be (Simon Pryor) writes:

[munch..]

>One area where it could obviously impact, is on the RTOSs that currently run
>on standard PC hardware, QNX, real-time Unixes, etc.

I wondered about this myself somewhat.. until I actually obtained a copy of
NT.  NT is definately not capable of any performance characteristics that 
even remotely resemble an OS like QNX.  NT is not even a desireable platform
for soft real-time since it's performance is generally... well.... sluggish,
and programming for the Windows interface is nightmarish.  One major area
where the real-time market differs radically from the business market is in
it's tolerence of complex programming environments.  Real-time developers
require a simple API for a number of reasons:

1. Complexity means more bugs, and bugs are much less tolerable in any kind
   of real-time environment than they are in the business environment.

2. Complexity means longer (read: more expensive) development schedules.
   Since the real-time market is so much smaller than the business market
   additional cost of R&D is felt to a much greater degree in the pricing
   of the final product.

3. Real-time developers don't require a lot of the features designed 
   for business system or desktop use, and this additional baggage simply
   adds unecessary memory nd processing overhead.

>Certainly, in the host/target type of cross development (VxWorks, VRTX, etc),
>many vendors may well support NT for the host development system instead of
>or as well as Unix.

This is possible.  I still think that most developers will prefer the
productivity benefits of developing on the target platform, if at all
possible.

>I'm sure that there will be many niche markets where NT won't reach. For
>instance, small promable embedded micro-controllers, with no disk or
>monitor, etc.

This is for sure.  Those 8MB ROMS (for NT's "kernel") are still pretty 
expensive, and they take lot's of board real-estate (not to mention the
power requirements :-)))

>But in the large networked real-time systems, I could see it having a
>significant impact. There could be potentially large cost savings by using
>standardized hardware.

QNX would be pretty hard to unseat (at least technically - which counts
for *alot* more in RT than for biz), in the large networked RT systems
environment.  The standard hardware argument doesn't hold up;  I'm typing
this from an off-the-shelf 40Mhz 386 running QNX 4.2

>And what about VME & Futurebus+? A lot of the RT market typically ran
>on Motorolla 680x0 boards in a VME rack. Now that Motorolla are moving
>to the PowerPC (is this the beginning of the end of the 680x0?), will
>VME & Futurebus+ be threatened with "standard" PC/Workstation hardware.
>I'm sure not totally, but a big chunk of the market could go along with
>many RTOSs. Again, the cost of using standard Workstation hardware with
>NT and Borland C++ for NT (no separate host & target), could well be an
>order of magnitude less than a more conventional VME RTOS setup.

Here I agree whole-heartedly.  Like it or not, right or wrong, this *is*
what will happen to a large extent (migration from proprietary hardware
to ISA boxes (ruggedized or desktop).

>So, what do you think? I realise it is difficult to predict the future,
>but as many of our jobs depend on it (RTOS vendors, VME board manufacturers,
>Application software engineers, Microsoft share-holders) it is worth
>a few thoughts.

Well, this is what I think.  Like it or not ISA (not necessarily ISA bus -
but the basic board design - ie. BIOS, memory layout, standard support chips
etc.) is going to (already has IMHO) make as big an impact in real-time as
it has in business systems, however, I don't think that anyone software
vendor (ie. MS) is going to dominate the market, since the RT market has know
where near the degree of homogenity that the business market exhibits...

Just my 2 cents ($1.75 US)

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943

---------------------------

Newsgroups: comp.os.vxworks
Subject: DMA functionality on the Force CPU30 board
Date: Wed, 22 Sep 1993 21:52:41 GMT
From: doug@neopath.wa.com (Doug Carlton)
Organization: NeoPath Inc.
Message-ID: <1993Sep22.215241.1392@neopath.wa.com>
Reply-To: doug@neopath.wa.com
Sender: news@neopath.wa.com

We are using the Force CPU30 with vxWorks version 5.0.2b. I am aware
that currently, the DMA capability is not enabled. We really need to 
speed up disk and NFS transfers so does anyone know how we might go
about getting the DMA capability enabled. Has Force or someone else 
modified a BSP to provide DMA??

Your time and attention are appreciated.

- ---
+-------------------------------+--------------------------------------+
| Doug Carlton                  | "I didn't vote for him .... or her!" |
| doug@neopath.wa.com           +--------------------------------------+
| (206) 455-5932                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Fri, 24 Sep 1993 13:14:01 GMT
From: dboyes@is.rice.edu (David E Boyes)
Organization: Rice University
Keywords: NT RTOS VME
Message-ID: <CDv0rD.278@rice.edu>
References: <2112@alcbel.be>
Sender: news@rice.edu (News)

In article <2112@alcbel.be> sp_sjp@space.alcbel.be writes:

>Many RTOSs have florished because there have been no other multi-tasking
>OSs with the required characteristics. Eg. Deterministic, prioritized, 
>preemptive schedulers, small interrupt latencies, etc, etc.

NT doesn't really address most of those issues very well at all.
There are vast quantities of code in the kernal that disable
interrupts for long periods, and the "determinism" of the
scheduler is not guaranteed for the small time ticks common in
most real-time systems.

>I don't know many details
>about the performance, and whether it is fast enough to handle hard RTOSs.

Unlikely. NT might be used in the same sorts of arenas that VMS
would be appropriate; its performance and scheduler behavior are
very much like the way VMS operates. I would actually expect to
see more use of OS/2 in hard RT than NT; OS/2 has some excellent
facilities for meeting deadlines and runs acceptably on far less
hardware than NT requires (disabling the GUI stuff reduces the
hardware requirements significantly). OS/2 also has the benefit
of several previous releases, which seem to have shaken some of
the worst of it's problems with RAS. 

>NT is also destined to run on other than
>Intel hardware: Alphas, MIPS RISC, PowerPC.

NT already does run on the Alpha and M3000 boxes. IBM has demoed
an OS/2 personality for the PowerPC and I've heard muttering about NT for the
PowerPC, but no concrete evidence of same. 

>One area where it could obviously impact, is on the RTOSs that currently run
>on standard PC hardware, QNX, real-time Unixes, etc.

Both OS/2 and NT have a pretty long way to go for RT development
tools. The latest release of the OS/2 developers kit has some
tools that would be very useful to RT users, but I'd really like
to see IBM free up some of their internal tools that they use to
develop their controller code used in the 3172 and others.
There's some serious RT stuff in there somewhere -- but it's not
making it outside to the customers.

>Certainly, in the host/target type of cross development (VxWorks, VRTX, etc),
>many vendors may well support NT for the host development system instead of
>or as well as Unix.

Maybe. Good tools will need to appear on NT first. The GNU tools
on Unix systems are going to be a hard act to follow on NT.
Someone's sure to do GNU ports for NT, but it will take time. 

>I'm sure not totally, but a big chunk of the market could go along with
>many RTOSs. Again, the cost of using standard Workstation hardware with
>NT and Borland C++ for NT (no separate host & target), could well be an
>order of magnitude less than a more conventional VME RTOS setup.

The VME market is dwindling somewhat anyway. ISA/EISA aren't
anything to really crow about, but there are tons of firms that
can make anything you want cheaply with that form factor, so I
think this is somewhat inevitable. MCA was a nifty idea, but at
this point (even given IBM making the standard freely available),
it's probably too little, too late for the ucontroller crowd.
Physical size is also getting to be a problem for the VME
folks; rack space is expensive.

>Simon Pryor
>sp_sjp@space.alcbel.be

- -- 
David Boyes      | This signature modified to be inoffensive to any race,
dboyes@rice.edu  | color, creed, sexual orientation, or programming limitation.
My opinion is my | Sober pursuit of truth and to all high ideals consecrated?
own.             | Look, it says so right on the box, next to the Vitamin A.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Test                     
Date: Thu, 23 Sep 1993 20:55:12 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrG0.2KG@mother1.UUCP>

GROUP
                                                                                                                          

---------------------------

Newsgroups: comp.os.vxworks
Subject: Test                     
Date: Thu, 23 Sep 1993 20:55:16 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrG5.2L8@mother1.UUCP>

This is a test message to see if anything actually happens here.
                                     

---------------------------

Newsgroups: comp.os.vxworks
Subject: Test                     
Date: Thu, 23 Sep 1993 20:55:21 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrG9.2M0@mother1.UUCP>

Hello Ivan,

   I hope you received this message fine.
   Its only a test anyway.

Vassilo.
             

---------------------------

Newsgroups: comp.os.vxworks
Subject: Info                     
Date: Thu, 23 Sep 1993 20:55:25 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrGE.2Ms@mother1.UUCP>

GROUPS
                                                                                                                         

---------------------------

Newsgroups: comp.os.vxworks
Subject: Info                     
Date: Thu, 23 Sep 1993 20:55:30 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrGI.2nK@mother1.UUCP>

ALLGROUPS
                                                                                                                      

---------------------------

Newsgroups: comp.os.vxworks
Subject: Test                     
Date: Thu, 23 Sep 1993 21:04:20 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrv8.2ps@mother1.UUCP>

GROUP
                                                                                                                          

---------------------------

Newsgroups: comp.os.vxworks
Subject: Test                     
Date: Thu, 23 Sep 1993 21:04:24 GMT
From: vassilo@mother1.UUCP (Vassilo)
Organization: The Motherload BBS;Public Access Unix System !
Message-ID: <CDtrvC.2qK@mother1.UUCP>

This is a test message to see if anything actually happens here.
                                     

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Fri, 24 Sep 1993 16:05:38 GMT
From: rgallen@muug.mb.ca (Rennie Allen)
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Keywords: NT RTOS VME
Message-ID: <1993Sep24.160538.4948@muug.mb.ca>
References: <2112@alcbel.be> <1993Sep24.052923.2136@muug.mb.ca>

In <1993Sep24.052923.2136@muug.mb.ca> rgallen@muug.mb.ca (Rennie Allen) writes:

>vendor (ie. MS) is going to dominate the market, since the RT market has know

I hate following myself up... but I must apologize for this ---------------^
Hey... it was late and my cat was helping me type..:-)

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Fri, 24 Sep 1993 16:21:27 GMT
From: rgallen@muug.mb.ca (Rennie Allen)
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Keywords: NT RTOS VME
Message-ID: <1993Sep24.162127.5628@muug.mb.ca>
References: <2112@alcbel.be> <CDuHFK.HLn@unix.portal.com>

In <CDuHFK.HLn@unix.portal.com> emil@shell.portal.com (emil rojas) writes:

[munch..]

>I have recently worked on two applications that I feel are in
>this category.  One that needs just a little real time, and would
>benefit greatly by having access on the same platform to standard
>spread sheet and WP tools,  And the other that is using windows
>now and would be improved by having real tasks.  If I were
>starting these projects today I would use NT.

With QNX I can do hard real-time and run MS-EXCEL and MS-WORD on another QNX 
box on the net, or I could do soft real-time and run these two packages on
the same box, or I could use TCP/IP (NT ships with it) and put and NT box
on the ether with the HRT QNX box.  No I don't think this argument holds any
water; the true real-time capabilities can be so tightly integrated with 
personal productivity tools, that there is no need to compromise the RT 
portions of the project to have effective (and cheap) non-RT components.

I have used NT and I can safely say that you would be compromising the RT
component by using it....

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943

---------------------------

Newsgroups: comp.os.vxworks
Subject: vxworks header files vs. unix header files
Date: Fri, 24 Sep 1993 21:21:22 GMT
From: jwp@bernie.sal.wisc.edu (Jeffrey W Percival)
Organization: Space Astronomy Lab, Madison WI
Message-ID: <1993Sep24.212122.13852@sal.wisc.edu>
Sender: jwp@sal.wisc.edu (Jeffrey W Percival)

I am compiling many modules for a vxworks application, and these
modules use sockets, time structures, and many, many things defined in
the standard Unix header files (struct tm, struct hostent, and on and on).

Several reliable and experienced vxworks users have told me not to use
unix header files, and should use only vxworks header files.  The
problem is, the vxworks header files do not define all of the
"standard" things found in unix files.

How is this problem handled?  Do I hunt through all the unix header
files, seeking out each and every vx-absent definition and copying it
to my own header file?

Is there some "foo.h" out there that defines all the vx-absent structs
and types?
- -- 
Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: DMA functionality on the Force CPU30 board
Date: Fri, 24 Sep 1993 20:23:23 GMT
From: doug@neopath.wa.com (Doug Carlton)
Organization: NeoPath Inc.
Message-ID: <1993Sep24.202323.6364@neopath.wa.com>
References: <1993Sep22.215241.1392@neopath.wa.com>
Reply-To: doug@neopath.wa.com
Sender: news@neopath.wa.com

I am posting to my own post. Let me first thank Mike Delliman of WRS
for his timely response. Mike mailed me a shar with a patch to enable
SCSI DMA on the Force CPU30 board. If anyone else is in need of this
patch e-mail to support@wrs.com.

- ---
+-------------------------------+--------------------------------------+
| Doug Carlton                  | "I didn't vote for him .... or her!" |
| doug@neopath.wa.com           +--------------------------------------+
| (206) 455-5932                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks header files vs. unix header files
Date: Fri, 24 Sep 1993 23:32:07 GMT
From: hjb@netcom.com (hwajin bae)
Organization: peaceful star, oakland, ca - vox: 510.536.7607 page: 510.466.9166
Message-ID: <hjbCDvtDK.Asu@netcom.com>
References: <1993Sep24.212122.13852@sal.wisc.edu>

In article <1993Sep24.212122.13852@sal.wisc.edu> jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes:
>Several reliable and experienced vxworks users have told me not to use
>unix header files, and should use only vxworks header files.  The
>problem is, the vxworks header files do not define all of the
>"standard" things found in unix files.

probably because those "standard" things are not supported in vxworks.
vxworks is not unix.  i wouldn't expect it to support all the "standard"
things in unix.  alot of similarities exist between unix and vxworks,
especially in networking area, but they're two very different operating
systems.

copying definitions of things from unix to vxworks header and using them
as is may or may not work.  if it works at all, it'll only be by accident, 
not by design.

hwajin

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: 24 Sep 1993 09:44:50 GMT
From: ken@minster.york.ac.uk
Organization: Department of Computer Science, University of York, England
Message-ID: <748863889.18093@minster.york.ac.uk>
References: <2112@alcbel.be>
Followup-To: comp.realtime,comp.os.vxworks

Simon Pryor (sp_sjp@space.alcbel.be) wrote:
: Many RTOSs have florished because there have been no other multi-tasking
: OSs with the required characteristics. Eg. Deterministic, prioritized, 
: preemptive schedulers, small interrupt latencies, etc, etc.

: NT seems to change that. It has a preemptive multi-tasking,
: multi-threaded kernel. Networking is integrated. It is scalable from
: standalone PCs to multi-processor servers, etc. I don't know many details
: about the performance, and whether it is fast enough to handle hard RTOSs.
: Certainly, its 12-16Mbyte RAM, 80Mbyte disk VGA requirements, will exclude
: it from some types of systems. NT is also destined to run on other than
: Intel hardware: Alphas, MIPS RISC, PowerPC.

From the experience of the Mach people, being able to analyse a kernel,
albeit priority pre-emptive, is not entirely straightforward. And that's
with access to the source code. How are people going to analyse NT as a RT
kernel when there's not a hope of getting the source code released. I
suppose microsoft could always try and analyse it themselves. It's all very
well having a pre-emptive kernel, but there will be blocking regions because
of the need for concurrency control, and if they have not used appropriate
techniques for concurrency control in real-time (e.g. priority ceiling
protocol), then there will be unbounded priority inversion or long
worst-case paths through the kernel. There are other hardware considerations
too: if the device independence of NT is cited then there is an obligation
to work out the precise behaviour of the hardware used, from interrupt
latencies, to priority inversion. This includes the processor: the memory
management of the 486 makes WCET bounds very difficult to obtain unless a
careful memory model is used (which NT doesn't).

- --
Ken Tindell             Internet      : ken@minster.york.ac.uk
Computer Science Dept., Local FTP site: minster.york.ac.uk
University of York,     Tel.          : +44-904-433244         
YO1 5DD, UK             Fax.          : +44-904-432708
- --
"The Gulf War won't be like a Rambo film; it will be long, bloody and terrible"

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks header files vs. unix header files
Date: 25 Sep 93 17:56:41 GMT
From: jwp@sal.wisc.edu (Jeffrey W Percival)
Organization: Space Astronomy Lab, Madison WI
Message-ID: <1993Sep25.175641.26812@sal.wisc.edu>
References: <1993Sep24.212122.13852@sal.wisc.edu> <hjbCDvtDK.Asu@netcom.com>

In article <hjbCDvtDK.Asu@netcom.com> hjb@netcom.com (hwajin bae) writes:
>In article <1993Sep24.212122.13852@sal.wisc.edu> jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes:
>>Several reliable and experienced vxworks users have told me not to use
>>unix header files, and should use only vxworks header files.  The
>>problem is, the vxworks header files do not define all of the
>>"standard" things found in unix files.
>
>...
>vxworks is not unix.
>...
>copying definitions of things from unix to vxworks header and using them
>as is may or may not work.  if it works at all, it'll only be by accident, 
>not by design.

I see.  I think my confusion is understandable, when I see comments like this
in vxworks header files:

    /* systime.h - UNIX-style timeval structure defenition */
    /* the following conditional is to avoid conflict with SunOS header...

Clearly, *some* unixy definitions are duplicated, and more than a nod
is given to collision with unix header files, so I feel that Mr Bae's
disclaimer above may be a little too stringent.

Anyway, the point is well taken and I thank Mr Bae for his helpful comments.
- -- 
Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks driver for Ethernet SBus card
Date: 26 Sep 93 17:19:28 GMT
From: lgm@polaris.flw.att.com (Lawrence G. Mayka)
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
Message-ID: <LGM.93Sep26121928@polaris.flw.att.com>
Sender: news@cbnewsc.cb.att.com (NetNews Administrator)

Does anyone know of a VxWorks driver for an Ethernet SBus card?  More
specifically, if I have a FORCE (SPARC-based) CPU-2CE which is running
IP over its 1 on-board Ethernet interface, does a driver exist that
would enable me to attach an SBus card with another Ethernet interface
and run IP over that as well?

- --
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@iexist.att.com

Standard disclaimer.

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Mon, 27 Sep 1993 07:17:39 GMT
From: muts@compi.hobby.nl (Peter Mutsaers)
Organization: My unorganized home
Message-ID: <MUTS.93Sep27081739@compi.hobby.nl>
References: <2112@alcbel.be>
Sender: muts@compi.hobby.nl (Peter Mutsaers)

>> On 23 Sep 93 15:12:24 GMT, sp_sjp@space.alcbel.be (Simon Pryor)
>> said:

  SP> Many RTOSs have florished because there have been no other
  SP> multi-tasking OSs with the required
  SP> characteristics. Eg. Deterministic, prioritized, preemptive
  SP> schedulers, small interrupt latencies, etc, etc.

  SP> NT seems to change that. It has a preemptive multi-tasking,
  SP> multi-threaded kernel. Networking is integrated. It is scalable
  SP> from standalone PCs to multi-processor servers, etc. I don't
  SP> know many details about the performance, and whether it is fast
  SP> enough to handle hard RTOSs.  Certainly, its 12-16Mbyte RAM,

It won't and is not made for that. Maybe it will come into the market
of the current RT Unices, but not in that of hard RTOSs like VxWorks.
We use both, and they are different worlds.

I even doubt its suitability to replace RT Unices (and even plain Unix
for that matter) because in these cases reliability is very important.
Knowing the history of MS and the frantic way they hacked together NT,
it will take years before they reach the maturity that 20 year old
Unix will get. Also it is much more resource hungry than Unix (except
OSF maybe).
- -- 
_______________________________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Extension to VxWorks ld()
Date: 27 Sep 93 18:34:42 GMT
From: kab@strl.labs.tek.com (Kent Black)
Organization: DTL, Tektronix, Inc.
Message-ID: <5798@crl.LABS.TEK.COM>
Sender: news@crl.LABS.TEK.COM

Has anyone ever considered or tried to extend the vxWorks dynamic load
facility, ld, to handle archives?  We would like to be able to use a
tool like Unix ar(1) to archive a group of objects, then use an extended
vxWorks ld to obtain either a specific object or every object from the
archive.  Arguably, there is no need for such an extension (we can live
with hundreds of little .o files cluttering the file system), but the
capability would be nice.  This is primarily a development tool,
although it might be useful for infrequent post-production use (e.g.,
diagnositics).

Now comes the kicker.  As a spiffy (and admittedly problematic)
extension of pulling individual objects out of archives, we'd like ld to
recursively query that archive for undefined symbols (rather than
failing to load at all) in the loaded object(s), so that complex
subsystems could be dynamically loaded.  Leads to lots of ugly design
issues.  Stick with the first paragraph first.

Comments welcome,
- -- kab

Kent Black      
    -----------------------------------------------------------------
     DTL, Tektronix Inc.            |   Email:  kab@dtl.labs.tek.com
     P.O. Box 500, M/S 50-662       |   Voice:  (503) 627-6280
     Beaverton, OR  97077           |   FAX:    (503) 627-5502
    -----------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks driver for Raster Graphics cards
Date: 27 Sep 1993 13:57:29 -0700
From: billr@saab.cna.tek.com (Bill Randle)
Organization: Tektronix, Inc., Redmond, OR
Message-ID: <287k3p$av1@saab.cna.tek.com>

A VxWorks driver is available for Raster Graphics, Inc. high performance
VME bus add-on graphics boards (RG-7XX series and RG-17XX series). The
driver, though written for VxWorks 5.1, should also work with 5.0. For
details, you can contact me via email or Raster Graphics directly at
(503)388-2584.

	-Bill Randle
	Tektronix, Inc.
	billr@saab.CNA.TEK.COM

---------------------------

Newsgroups: comp.os.vxworks
Subject: Video Capturing and Compression Support w/ vxWorks
Date: 27 Sep 1993 20:37:59 GMT
From: nam@peregrine.esl.com (Nam N. Nguyen)
Organization: esl.com
Message-ID: <287iv7$4pf@gatekeeper.esl.com>

I am in the design phase of an application to:

	* real-time (fast speed) capture video images, 
	* compress these images (JPEG, ...), and
	* transmit images over possibly FDDI link.

from an embedded system (preferably running vxWorks) to a SUN workstation.

No need to display the images on the embedded computer.  The SUN X server
will handle this capability.

I am currently looking at all possible options (hardware and software
availability, cost, ...).

If you have done similar projects, please advise me on:

	* kind of devices that you use, 
	* OS, (vxWorks, ..)
	* vendor of video cards, ...

Of if your company provides products that do image's CAPTURING and COMPRESSION
as described above, please send me the quote on the products.

Please either send me email at nam@esl.com, or FAX to me at 
(408) 743-6425 (please attn. Nam Nguyen, extn. 4485).

Thank you very much,

Nam N.

---------------------------

Newsgroups: comp.os.vxworks
Subject: GPIB support
Date: Mon, 27 Sep 1993 21:00:13 GMT
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1993Sep27.210013.28775@bnlux1.bnl.gov>
Sender: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)

	We're getting closer to the point when we need
to add GPIB to our vxWorks systems. Since we're using
MVME162s as our CPUs, I'm tempted to use an IndustryPack,
rather than a separate VMEbus card. IndustryPacks might
be cheaper, tho since they are real-estate limited, they
might be less full-featured, and since IP is a less mature
standard, the products might be less debugged. Also I'm
*very* interested in buying, rather than building vxWorks
support.

	Does anyone have experience with a GPIB IndustryPack
they'd like to share? GreenSpring sells such a beast, but
markets an OS-9, rather than vxWorks, driver. I assume
that the OS-9 driver could be fairly easily (but not without
effort) ported.

	On the flip side... any comments about VMEbus GPIB
cards with vxWorks support? 
- -- 

     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_   

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: Re: Will NT Kill RTOSs, VME?
Date: Tue, 28 Sep 1993 01:05:14 GMT
From: montasmm@ntmtv.com (Medi Montaseri)
Organization: Northern Telecom Inc, Mountain View, CA
Keywords: NT RTOS VME
Message-ID: <1993Sep28.010514.20665@ntmtv>
References: <2112@alcbel.be>
Reply-To: montasmm@ntmtv.com (Medi Montaseri)
Sender: news@ntmtv

IMHO, NT is not delivering any out of the ordinary OS feature. In fact its 
down word compatibility with DOS, and 16 bit windows would be its very enemy.

Has anyone looked into SVR4 and its real-time attribute.

Medi
- -- 
| Medi Montaseri          "The fact that it works, is immaterial."   |
| montasmm@ntmtv.com                                                 |
| medi@earth.milkyway_galaxy.local_group.local_supercluster.universe |
+--------------------------------------------------------------------+

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vxworks header files vs. unix header files
Date: Tue, 28 Sep 1993 01:30:40 GMT
From: montasmm@ntmtv.com (Medi Montaseri)
Organization: Northern Telecom Inc, Mountain View, CA
Message-ID: <1993Sep28.013040.20957@ntmtv>
References: <1993Sep24.212122.13852@sal.wisc.edu>
Reply-To: montasmm@ntmtv.com (Medi Montaseri)
Sender: news@ntmtv

In article <1993Sep24.212122.13852@sal.wisc.edu> jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes:
>I am compiling many modules for a vxworks application, and these
>modules use sockets, time structures, and many, many things defined in
>the standard Unix header files (struct tm, struct hostent, and on and on).
>
>Several reliable and experienced vxworks users have told me not to use
>unix header files, and should use only vxworks header files.  The
>problem is, the vxworks header files do not define all of the
>"standard" things found in unix files.
>
>How is this problem handled?  Do I hunt through all the unix header
>files, seeking out each and every vx-absent definition and copying it
>to my own header file?
>
>Is there some "foo.h" out there that defines all the vx-absent structs
>and types?
>-- 
>Jeffrey W Percival (jwp@larry.sal.wisc.edu) (608)262-8686

Its called host/target issue. You are developing on a host for a target.
If your target is a Unix box, then sure, be my guest, use all the Unix libs and system
calls (hope you are getting them from the same unix vendor). But if your target
is some box running vxworks or joe_blow operting system, then how do you
expect these libs or system calls to work for you. vxworks is not unix, but their 
marketing people are good. Their file system sucks. No virtual memory. But it allows you
to download stuff using sockets.

Medi
- -- 
| Medi Montaseri          "The fact that it works, is immaterial."   |
| montasmm@ntmtv.com                                                 |
| medi@earth.milkyway_galaxy.local_group.local_supercluster.universe |
+--------------------------------------------------------------------+

---------------------------

End of New-News digest
**********************

From zander@luke.atdiv.lanl.gov  Tue Sep 28 09:57:23 1993
From: zander@luke.atdiv.lanl.gov (Mark Zander)
Date: Tue Sep 28 09:57:30 PDT 1993
Subject: Re: Extension to VxWorks ld()
Kent Black writes:

> Has anyone ever considered or tried to extend the vxWorks dynamic load
> facility, ld, to handle archives?  We would like to be able to use a
> tool like Unix ar(1) to archive a group of objects, then use an extended
> vxWorks ld to obtain either a specific object or every object from the
> archive.  Arguably, there is no need for such an extension (we can live
> with hundreds of little .o files cluttering the file system), but the
> capability would be nice.  This is primarily a development tool,
> although it might be useful for infrequent post-production use (e.g.,
> diagnositics).

We've kludged something up along these lines.  We take an archive file,
extract all objects from that file, then put it in a single .o file.
The following is an example from our make files:

		(if test -d o;then rm -r o;fi); \
		(mkdir o);\
		(cd o; ar x archive.a; \
		(ld  -o ldname.o *.o ); \
		(rm -r o); \

Having a more general facility like you suggest would be nice.

---------------------------------------------------------
|							|
|	Mark Zander					|
|	Los Alamos National Laboratory			|
|	Accelerator Operations and Technology Division	|
|	Controls and Automation Group			|
|	MS-H820						|
|	Los Alamos, NM 87545				|
|							|
|	phone: 505-665-0690				|
|	fax:   505-665-5107				|
|	email: mez@lanl.gov				|
|							|
---------------------------------------------------------

From visicom!VisiCom.COM!trest@nosc.mil  Tue Sep 28 10:08:40 1993
From: Mike Trest <trest@visicom.com>
Date: Tue Sep 28 10:08:56 PDT 1993
Subject: Employment Wanted
To All:

About a 2 months ago I posted a message on this net suggesting that
we may not really know the true state of employment prospects for
the RTOS professional.  At that time, I invited any firms who have
positions available for "Experienced Real Time Professionals" to
send me an EMAIL message.  Likewise, I offered to mail this list
of positions to any individual who request it by a private EMAIL.

The latest update was mailed 28 September 1993. I sent a list of 
11 firms with 20+ open positions to approximately 90 individual 
requesters.  

I have received some feedback.  Several firms have received
contacts from people looking.  Obviously, the firms do not tell
me who or even how many. One firm has commented that the professional 
experience level of respondants is just what they were looking for.

This is not a large number, but it is significant given the limited 
distribution of this news group and the restriction to experienced 
real time professionals.

If you or you employer are searching for experienced real time 
software and hardware talent, please send me an EMAIL message.  
Please include a few words about your firm, the kinds
of things you do, the kind of talent you are looking for, and
the method by with interested individuals may contact you.

If you, as an individual, are interested in receiving a copy of
EMAIL from any firms who have positions open, send me a EMAIL
note.  I will not send your name to anyone, including my own
employer.  When you receive a copy of the EMAIL messages from
firms with positions, the firms will not be notified either.

As a slight variation, I am interested your responses to
a few questions.  Answer if you want to:

1. How many years of formal education / training do
   you have?

2. How many years have you been working Real-Time
   applications (hardware or software)?
   
3. Are you pleased/satisfied/unsatisfied with your
   current compensation?

4. Are you using most/some/little of your professional 
   training and skills in your present assignments?

I plan to send out a summary of the responses and the next 
general message at the end of October.

PLEASE REMEMBER TO USE trest@visicom.com  NOT THE EXPLODER
OR NET NEWS ADDRESS!

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From daemon@vxw.ee.lbl.gov  Wed Sep 29 04:01:16 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Sep 29 04:01:25 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Sep 29 04:01:07 PDT 1993

        Subject: CES VCC2117 CAMAC crate controller?
        Subject: Has anyone used Spectrum CVn w/ 68K+Vxworks?
        Subject: nfs on VxWorks

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: CES VCC2117 CAMAC crate controller?
Date: Tue, 28 Sep 1993 16:07:47 GMT
From: vb@iri.tudelft.nl
Organization: TU Delft, Interfac. Reactor Institute
Message-ID: <1993Sep28.160747.1@iri.tudelft.nl>
Sender: news@dutrun2.tudelft.nl (UseNet News System)

CES VCC2117 camac crate controller

We are looking for a crate controller module to be used as target system
in a CAMAC crate. Such modules are hard to find. A candidate module
would be the VCC2117 crate controller from CES.

Does anyone have experience with this module as vxWorks target; maybe
even a BSP ?

Victor Bom, VB@IRI.TUDELFT.NL

---------------------------

Newsgroups: comp.os.vxworks
Subject: Has anyone used Spectrum CVn w/ 68K+Vxworks?
Date: 28 Sep 1993 22:41:31 GMT
From: eddie@ux5.lbl.gov (edward moler)
Organization: Lawrence Berkeley Laboratory
Keywords: 
	Howdy.  The subject says most of it.  I'm looking at
Message-ID: <28aeis$640@overload.lbl.gov>

collecting large amounts of data (~20 million from an ADC) @ 1KHz
rates and filtering in real time or at least near-real-time.  It seems
Spectrum's Boards might do the job.  What do the collective You think? Any
other suggestions are welcome.  

	Please reply to EJMOLER@LBL.GOV

					Thanks in advance,

					Eddie Moler
					Lawrence Berkeley Labs

---------------------------

Newsgroups: comp.os.vxworks
Subject: nfs on VxWorks
Date: Tue, 28 Sep 1993 21:56:06 GMT
From: wjasper@tx.ncsu.edu (Warren Jasper)
Organization: College of Textiles, North Carolina State University
Message-ID: <1993Sep28.215606.6321@ncsu.edu>
Reply-To: wjasper@tx.ncsu.edu
Sender: wjasper@unity.ncsu.edu (Warren Jasper)

- -- 

I am running VxWorks 5.1 on a MVME167 and am trying to write via nfs to
a DECstation 5000.  I have noticed that fflush does not really flush an
nfs buffer on the VxWorks side, but it sends UDP packets when it's buffer is
full.  I think the decstation is unable to process the large packet sizes, and
does not acknowledge a write.  I have spent many hours with tcpdump to try
to figure out what is going on.  VxWorks supplies a file called usrNetwork.c
with the comment:

    /*
     * The following values are the default values used in NFS.
     * They can be reset here if necessary.
     *
     *     nfsMaxMsgLen   = 8192        message size (decrease only)
     *     nfsTimeoutSec  = 5           timeout seconds
     *     nfsTimeoutUSec = 0           timeout microseconds
     */

Question:

How do I change the message size and the nfsTimeoutSec?  Other than the comment,
I am at a loss.  Any other suggestions why I can not write to the Decstation?
I know it's getting the packets, it just does not acknowledge them.  The
'open'  command works, as does ls and copy.  The problem comes with large (multi-fragment) packets.

Thanks in advance,

	-- Warren

Warren J. Jasper
wjasper@tx.ncsu.edu

---------------------------

End of New-News digest
**********************

From hebo@mbari.org  Wed Sep 29 09:12:47 1993
From: Bob Herlien <hebo@mbari.org>
Date: Wed Sep 29 09:12:54 PDT 1993
Subject: Re: comp.os.vxworks newsdigest
> I am running VxWorks 5.1 on a MVME167 and am trying to write via nfs to
> a DECstation 5000.  I have noticed that fflush does not really flush an
> nfs buffer on the VxWorks side, but it sends UDP packets when it's buffer is

I always use

	fflush( fp );
	ioctl( fileno(fp), FIOSYNC, 0 );

But I think the fflush is ineffective, and it's the ioctl that causes
NFS to flush.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org

From daemon@vxw.ee.lbl.gov  Thu Sep 30 04:01:44 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Sep 30 04:01:53 PDT 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Sep 30 04:01:31 PDT 1993

        Subject: HELP! Race Condition debugging
        Subject: Re: nfs on VxWorks
        Subject: not at all pleased with 5.1...

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: HELP! Race Condition debugging
Date: 29 Sep 93 16:24:02 GMT
From: gchow@futuna.inria.fr (Gloria Chow)
Organization: INRIA, Sophia-Antipolis (Fr)
Keywords: race, debugging
Message-ID: <57546@sophia.inria.fr>
Sender: news@sophia.inria.fr

I am having problem with my program on VxWorks.  It seems that I have some
kind of race condition hidden in my tasks and it caused the system to lock
up completely ( I have to do a hardware reset every time).  Yet, none of my
spawned tasks have very high priority.  They were at 110, now they are at 100,
just random trials :(

I have it traced down to a single function where I am just doing a simple
loop of "writes" to some memory map I/O.  If I put in a taskDelay of 6 ticks
before calling this function, everything seems to be fine!!

I am completely clueless what to do, where to begin, how to debug this kind
of bugs.  Please, please, please, some kind souls lend me a hand, points me
in the right direction.

- -- 
Gloria, on her knees, Chow		INRIA, Sophia Antipolis, France
gchow@sopia.inria.fr

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: nfs on VxWorks
Date: Wed, 29 Sep 1993 16:09:13 GMT
From: marcg@array.arraycomm.com (Marc Goldburg)
Organization: ArrayComm, Inc.
Message-ID: <MARCG.93Sep29090913@array.arraycomm.com>
References: <1993Sep28.215606.6321@ncsu.edu>
Sender: marcg@arraycomm.com (Marc Goldburg)

On Tue, Sep 28, Warren Jasper writes in message <1993Sep28.215606.6321@ncsu.edu>,

Warren> I am running VxWorks 5.1 on a MVME167 and am trying to write via
Warren> nfs to a DECstation 5000.  I have noticed that fflush does not
Warren> really flush an nfs buffer on the VxWorks side, but it sends UDP
Warren> packets when it's buffer is full.  
Warren> 
Warren> (remainder of message deleted)

We had a similar problem.  The problem with fflush() is that the streams
package lives above NFS in the VxWorks I/O system.  Calls to fflush() flush
data down to NFS, but don't cause NFS to flush to the remote file.  

According to Wind Rivers, NFS will send on three events:
   1. The nfs buffer is full
   2. close
   3. fiosync
So, our solution was to use fflush() followed by ioctl(), e.g.

        FILE *s;
        ...
        /* force an update of the remote file */
        fflush(s);
        ioctl(fileno(s), FIOSYNC, 0);
        ...

Hope this helps,

Marc Goldburg
marcg@arraycomm.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: not at all pleased with 5.1...
Date: Wed, 29 Sep 1993 16:57:37 GMT
From: heyes@dahp1.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.93Sep29115737@dahp1.cebaf.gov>
Sender: usenet@murdoch.acc.Virginia.EDU

We are running 5.0.2b on many 68k based systems on this site and also
off site. Many of our systems have kernels burned into ROM or flash
memory so changing OS versions is non-trivial and takes some time.

As a precursor to moving to 5.1 I started this morning to recompile
our sourse code, many thousands of lines in hundred's of files, 
against the 5.1 headers. That is where the problems begin...

For example ...

scRpc_svc_main.c:50: too few arguments to function `svcudp_create'

in John Bloomer's book "Power programming with RPC" and the 5.0.2b
headers this call has one argument, in 5.1 it suddenly has three.

Also existing compiled code won't load because for some reason the
global variable _ctype_ used in 5.0.2b becomes __ctype in 5.1 !!

Now I know there are some problems, in fact I have the 5.1 known
problems in front of me BUT I would have expected that in going
from 5.0.2b to 5.1 I wouldn't have to plough through all my code
essentially debugging it all again. Normally the number to the 
left of the dot is the major release number indicating major 
changes and the possability of porting problems and the one to the 
right is minor release indicating bug fixes etc. It looks like 
wrs are not working this way.

This sounds like a trivial gripe maybe but I have just recieved a
pile of mvme162 boards and the only board support I have is 5.1.
I must either have two versions of all my code
Has anyone got a list of routines who's argument lists have changed
and other similar pitfalls that they can FAX of E-mail to me.

---------------------------

End of New-News digest
**********************

From vdbent@rulrol.leidenuniv.nl  Thu Sep 30 08:25:28 1993
From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent)
Date: Thu Sep 30 08:25:45 PDT 1993
Subject: S_scsiLib_ABORTED_COMMAND
Hi there,

I'm writing blocks of data with a maximum size of 131072 Bytes, to a EXB-8500
tape drive via the SCSI port of a Mizar MZ7130 CPU.

With the following code fragment

    #define BLOCK_SIZE 2048

    if (write (exbFd, buf, nBlocks * BLOCK_SIZE) != nBlocks * BLOCK_SIZE) {
        reportError (0);  /* report error status string */
        return;
    }

I get a "S_scsiLib_ABORTED_COMMAND" error from write() once in a long while.

What does this error mean, and what could have caused it?  Let me note that
the drive is in a noisy laboratory environment.  We had to shield a piece of
'SCSI-flatcable' of only about 8 inches long to make it work in the first
place.
I suppose that a write() always returns after having processed the number
bytes requested OR on an error.  This correct (for this device) isn't it?!

Regards,

    #    # ####   #  #####################################  #####   #   ##     #
    #  #   #  # # ########## ###  #########################  #### ####  #     #
   #     ## #   ### #######  ##  ########################## ## #   #   ##
 #    #       # ##### #####  #  ########################## ### ## ## #  # # #
   #    # ## # #######  ###    ####    ####    ####   ### ## ###  #           #
  #  # #    ### # ## ######   #### ###  ## ###  ## ######## ## # ###    # #  #
 #           #  ### ## ####    ##       #       ##   ###  ####### # ## #    #
   # # #  # ## ## ### ####  #  ##  ######  ########   #### ##### #       #    #
       ##   #   # ## #####  ##  #  ##   #  ##   ####  ###### ###   # ##     #
 #     #  #### ####  #####  ###  #    ####    ###    ######### # #  #   #  #
#     ##   #   #####  #####################################  #   #### #    #

                                Kees van der Bent
                           vdbent@rulrol.LeidenUniv.nl
                                  +31-71-275805

                     Space Research Organisation Netherlands
                                  P.O. Box 9504
                                 2300 RA  Leiden
                                 The Netherlands

From stan@rti.com  Thu Sep 30 09:19:43 1993
From: stan@rti.com (Stan Schneider)
Date: Thu Sep 30 09:19:52 PDT 1993
Subject: Re:  HELP! Race Condition debugging
>> Date: 29 Sep 93 16:24:02 GMT
>> From: gchow@futuna.inria.fr (Gloria Chow)

>> I am having problem with my program on VxWorks.  It seems that I have
>> some kind of race condition hidden in my tasks and it caused the system
>> to lock up completely ( I have to do a hardware reset every time).  Yet,
>> none of my spawned tasks have very high priority.  They were at 110, now
>> they are at 100, just random trials :( 

Unless there's something running on your system between 100 & 110, that makes
no difference.

>> I have it traced down to a single function where I am just doing a simple
>> loop of "writes" to some memory map I/O.  If I put in a taskDelay of 6 ticks
>> before calling this function, everything seems to be fine!!
>> 

This doesn't really sound like a race condition.  Are you by any chance running
with polled backplane communications?  Does the delay help if it's put anywhere
else in your loop (e.g. after the function)?  What normally clocks this task
(i.e. keeps it from burning all the CPU)?  What else is running on the system
(esp. at lower priority)?  What do the i/o writes do?  If you send the output
of the "i" command (with the delay so the system runs) it might give a clue.

If that doesn't work, we have some tools that might help.  In particular, we
have a "Trace" tool that will show you what routines got called in what order,
and a "Patch" tool that will let you easily disable tasking around functions,
insert delays without recompiling, etc.  They should be useful if you really
have a race condition.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From thor@thor.atd.ucar.edu  Thu Sep 30 23:00:20 1993
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Thu Sep 30 23:00:30 PDT 1993
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 2786
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor        37126 Jun 12  1992 ansilib01
-rw-r--r--  1 thor        18913 Jun 12  1992 ansilib02
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6  1991 dhrystones01
-rw-r--r--  1 thor        19170 Apr  1  1993 dirlib01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         2453 Mar 10  1993 gcc+68040
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor        10352 Sep 16 15:06 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
lrwxrwxrwx  1 root            6 Aug 14  1991 libx11 -> libX11
-rw-r--r--  1 thor         3515 Mar 16  1993 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor        41667 Feb  5  1992 ntpvx01
-rw-r--r--  1 thor        38524 Feb  5  1992 ntpvx02
-rw-r--r--  1 thor        41997 Feb  5  1992 ntpvx03
-rw-r--r--  1 thor        39218 Feb  5  1992 ntpvx04
-rw-r--r--  1 thor        39625 Feb  5  1992 ntpvx05
-rw-r--r--  1 thor        28741 Feb  5  1992 ntpvx06
-rw-r--r--  1 thor        32516 Feb  5  1992 ntpvx07
-rw-r--r--  1 thor        37119 Feb  5  1992 ntpvx08
-rw-r--r--  1 thor        41643 Feb  5  1992 ntpvx09
-rw-r--r--  1 thor        19593 Oct 27  1992 ping01
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14  1991 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14  1991 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        41196 Oct 16  1992 stevie01
-rw-r--r--  1 thor        35279 Oct 16  1992 stevie02
-rw-r--r--  1 thor        35278 Oct 16  1992 stevie03
-rw-r--r--  1 thor        35012 Oct 16  1992 stevie04
-rw-r--r--  1 thor        34502 Oct 16  1992 stevie05
-rw-r--r--  1 thor        37476 Oct 16  1992 stevie06
-rw-r--r--  1 thor        30073 Oct 16  1992 stevie07
-rw-r--r--  1 thor        31562 Oct 16  1992 stevie08
-rw-r--r--  1 thor        37360 Oct 16  1992 stevie09
-rw-r--r--  1 thor        20662 Oct 16  1992 stevie10
-rw-r--r--  1 thor        25717 Oct 16  1992 stevie11
-rw-r--r--  1 thor        28075 Oct 16  1992 stevie12
-rw-r--r--  1 thor        31852 Oct 16  1992 stevie13
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1  1992 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-rw-r--  1 root       694807 Sep 16 15:05 tclvx7.0.v1.tar.Z
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        19912 Aug 27  1992 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor         5608 Dec  2  1992 veclist01
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22  1991 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22  1991 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22  1991 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22  1991 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22  1991 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22  1991 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22  1991 vwcurses07
-rw-r--r--  1 thor         8601 Mar 16  1993 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16  1992 wdog_class
-rw-r--r--  1 thor         5179 Apr  1  1993 xxx
Unix sources: