From mickel@wrsec.fr  Mon Aug  1 02:49:00 1994
From: mickel@wrsec.fr
Date: Mon Aug  1 02:49:11 PDT 1994
Subject: Re: By-passing lengthy self-test (on MVME-167)
There has recently been some discussions about having
VxWorks to co-exist with 167bug on an MVME-167.

I have a contact who tried out a configuration using 167bug
to boot VxWorks off the network (i.e. no VxWorks boot ROMSs
installed on the board). Here are some things to consider:

- VxWorks image must not conflict with RAM used by 167bug; change load
  address from 0x1000 to 0xe000

- VxWorks usage of NVRAM must not conflict with 167bug; there is no
  strict definition of which addresses may be used, but it should be OK
  to set NV_RAM_ADRS to a high BBRAM address (currently it is at offset 0).

- sysToMonitor(); pRom must be changed to point to entry address of 167bug.
  CAUTION - the entry address will change between different 167bug
revisions!
  The correct way to do this would be to read the reset vector of the PROM,
  and set up pRom accordingly.
(This should fix the reboot problem for dmr@iassf.easams.com.au)


Rebuilding VxWorks with the above changes will make it possible to boot
from 167bug using the "nbo" command, or setting the auto-boot flag.

My contact has only tried booting vxWorks.st, but I guess it should
be OK with vxWorks/vxWorks.sym also.

Best regards
_________________________________________________________________________
Mikael Liden    | Wind River Systems, Scandinavia   | Tel: +46-8 707 3220
mickel@wrsec.fr | Box 206, S-136 23 Haninge, Sweden | Fax: +46-8 777 3049



From crispen@eight-ball.hv.boeing.com  Mon Aug  1 07:28:46 1994
From: crispen@eight-ball.hv.boeing.com (Bob Crispen)
Date: Mon Aug  1 07:28:54 PDT 1994
Subject: Re: Network Interfaces
penny@paramount.sna.dec.com (Simon Penny) sez:

>The FDDI card documentation then tells me to set up the internet
>address of the FDDI interface using the routine
>
>ifAddrSet("rpf0", "90.0.0.1");
>
>(although we use the proper address of course). When I do this,
                      ^^^^^^

There's your problem.  You need a second set of IP addresses for
your FDDI network.  Since we never attached our FDDI ring to anything
outside our closed system, we used a class A address; I recall it was
80.0.0.x.

Let's imagine you've got a VME bucket and its main host is called
"envme1" talking to a second bucket whose name is "envme2".  Each
of them has an IP address for its ethernet interface, which we'll
assume are 90.0.0.1 and 90.0.0.2, respectively.

To talk between them, as you already know, you use ifAddrSet() on
the own-bucket IP address (or rather the bootup does this for you)
and you use hostAdd() to add the foreign-bucket addresses.  Once again
bootup does this for you for your boothost, but you probably have to
do this manually for envme2 on bucket1 and for envme1 on bucket 2.

To attach the FDDI net, we do the same thing: on bucket 1 use
ifAddrSet() for "fdvme1" at 80.0.0.1 and use hostAdd() "fdvme2" at
80.0.0.2.  Do the opposite on bucket 2.

We're now ready for the magic to happen.  If we're sitting in bucket 1
(envme1 and fdvme1) when we send a packet to envme2, it goes to
bucket 2 over the ethernet, and when we send a packet to fdvme2 it
goes over FDDI.  If you've used the backplane interface, this should
all sound familiar to you.

There may be subtler ways than assigning a whole network number to each
interface you're using (Ethernet, backplane, and FDDI), but the above
is simple and bulletproof and doesn't involve huge amounts of effort.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From guthrie@power.amasd.anatcp.rockwell.com  Mon Aug  1 09:10:13 1994
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Mon Aug  1 09:10:27 PDT 1994
Subject: Network Interfaces
Simon Penny:
        I don't believe there is any switch to be set in the kernel.
I am using 5.1.1 and have an ethernet and two FDDI interfaces.

        The only thing I can think of is that the your ethernet and
FDDI are on the same subnet. If you are using class B addresses with
255.255.0.0 as the subnet mask, you would be on the same subnet if
the top 2 bytes were the same. If you are using class C addresses with
255.255.255.0 as the subnet mask, you would be on the same subnet if
the top 3 bytes were the same.

        My ethernet is just the basic interface in my BSP that I load 
vxWorks over. That IP address is assigned in my boot parameters.
For my two FDDI cards, I also do ifAddrSet, and this works for me.

        If you have any specific questions about other set up, mail back.

        Robert Guthrie
        Rockwell


From daemon@ntmtv.com  Mon Aug  1 10:47:47 1994
From: daemon@ntmtv.com
Date: Mon Aug  1 10:47:55 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Network Interfaces

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Mon Aug  1 12:51:33 1994
From: daemon@ntmtv.com
Date: Mon Aug  1 12:51:41 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From mwbrown@somnet.sandia.gov  Mon Aug  1 12:52:42 1994
From: "Matthew W. Brown" <mwbrown@somnet.sandia.gov>
Date: Mon Aug  1 12:52:53 PDT 1994
Subject: tip & xterm
I have a question that I thought that I would throw 
out to the net.  While it is not strictly a VxWorks 
question, I suspect many of you have seen this same
behavior ...

I have been using tip & xterm to talk to the serial
ports of my target boards .  Things seem to work OK
but every once in a while, the xterm window just
disappears.  I can fire it right back up and every
thing appears normal again.  Has any one else seen
this?  Better yet, can any one explain what is going
on so that I can stop it?  I really can't seem to 
narrow down what is causing this--I can sometimes
go for days with out any trouble.

I start my tip session with the following command:

xterm -geometry 80x40+25+25 -sb -sl 1500 -e tip DAS1 &

"DAS1 is defined in /etc/remote as:

DAS1:\
        :dv=/dev/ttym00:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:


Any insights would be appreciated.

Matthew Brown
mwbrown@sandia.gov


From daemon@vxw.ee.lbl.gov  Tue Aug  2 04:00:22 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Aug  2 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Aug  2 04:00:13 PDT 1994

        Subject: Re: loading object file containing a huge array
        Subject: VxWorks pipes
        Subject: handling UNIX SIGIO interrupts in vxWorks simulator on sparc
        Subject: Branch Flow Analysis (BFA)

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

Newsgroups: comp.os.vxworks
Subject: Re: loading object file containing a huge array
Date: Mon, 1 Aug 1994 16:12:08 GMT
From: jerald@wrs.com (Jerald Pendleton)
Organization: Wind River Systems, Inc.
Message-ID: <jerald.775757528@wrs.com>
References: <9407261727.AA00582@adac.com>
Sender: news@wrs.com (News Manager)

atl@adaclabs.com (Anthony Le) writes:


> 
>This is a problem related to loading in VxWorks when declare
>a huge array in a program.
> 
>When I declare a huge array of 2 MBytes (not use malloc() in
>my program) I can not load the object file to SBC. It complains
>about the memory patition error.

<snip>

I think I saw this in a previous post and someone made a very
good answer, but just in case...

I would suggest that you rebuild your vxWorks kernel with INCLUDE_NFS
and NFS mount the disk that you loading from.

If you don't do this, you must have twice the size of your image, plus
a smidge more in available contigious memory.   The default network
driver in vxWorks, netDrv, essentially does an rcp from the host
into local memory.  The loader then loads from the local memory.  Having
an NFS mounted disk allows the loader to fetch data as needed rather
than in one fell swoop.

The memPartAlloc error, which indicates that a malloc failed is
a good clue that this is happening.

- ----

Jerald R. Pendleton (Jerry) - Senior Tech Support Engineer - Wind River Systems
         Corporate Headquarters: 1010 Atlantic Ave, Alameda, Ca.  94501 
 email: jerald@wrs.com  phone: 1-510-814-2563  Non-WRS-email: jrpend@netcom.com
                        "Wind River Software - Everywhere!" 
- -- 
Jerald R. Pendleton Email: jerald@wrs.com, Personal Email:  jrpend@netcom.com
The preceeding message represents only the opinon of the author.  This
do not represent the opinions/positions of Wind River Systems, my mother,
my wife or my poodle.

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

Newsgroups: comp.os.vxworks
Subject: VxWorks pipes
Date: 1 Aug 94 18:53:16 GMT
From: ruppin@bimacs.BITNET (Adi Ruppin)
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel
Keywords: VxWorks, pipes
Message-ID: <4860@bimacs.BITNET>

Hello,
I've been using pipes. I managed to create them and use them, but I
don't know how can I destroy them. The memory allocated for the pipes
remains occupied no matter what I do.
How can I destroy a pipe and in fact any other device I create on VxWorks?
Please reply also by mail,

ruppin@bimacs.cs.biu.ac.il


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

Newsgroups: comp.os.vxworks
Subject: handling UNIX SIGIO interrupts in vxWorks simulator on sparc
Date: Mon, 1 Aug 1994 22:37:37 GMT
From: ngupta@micom.com (Niraj Gupta)
Organization: Micom Communications Corp.
Message-ID: <1994Aug1.223737.20524@micom.com>

Hi

	We are using 1.1 beta release of vxSim (vxWorks simulator)
on sparcstations. We are using vxWorks for our router. We are 
developing our system using vxSim on sparcstations. We are using
sun nit devices to access additional ethernet boards in our box.
so our router can route between the lan segments. Currently we 
have to poll our file descriptors from our driver in vxSim. The
file descriptor can be put in ASYNC mode in which the vxSim will
receive SIGIO whenever their is a packet available. I have not been 
to tie up the signal to my interrupt handler running in vxSim.

Please help me if you have any ideas.

niraj gupta
ngupta@micom.com

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

Newsgroups: comp.os.vxworks
Subject: Branch Flow Analysis (BFA)
Date: 2 Aug 1994 04:33:43 GMT
From: echang@cup.hp.com (Edward Chang)
Organization: Information Networks Division: Hewlett Packard
Message-ID: <31kib7$a03@hpindda.cup.hp.com>

Hello,

Have anyone ported BFA tools such as Generic Coverage Tool (GCT) to
vxWorks to get test coverages of your modules?

I am using the Intel 80960 processor and vxWorks 5.1 on the target system.

Any info would be greatly appreciated.

Thanks,
Ed Chang

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

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


From sergi@hpbpq5.bpo.hp.com  Tue Aug  2 05:33:23 1994
From: Sergi Casas (QA Software Testing, BPO) <sergi@hpbpq5.bpo.hp.com>
Date: Tue Aug  2 05:33:31 PDT 1994
Subject: Re: SIGIO on vxSim
Niraj Gupta wrote:

>        We are using 1.1 beta release of vxSim (vxWorks simulator)
> on sparcstations. We are using vxWorks for our router. We are
> developing our system using vxSim on sparcstations. We are using
> sun nit devices to access additional ethernet boards in our box.
> so our router can route between the lan segments. Currently we
> have to poll our file descriptors from our driver in vxSim. The
> file descriptor can be put in ASYNC mode in which the vxSim will
> receive SIGIO whenever their is a packet available. I have not been
> to tie up the signal to my interrupt handler running in vxSim.


	We are using vxSim on HP workstations, not on Sun, but I bet the reason
of the problem is exactly the same: in the BSP for vxSim the simulated version
of the tyCo driver uses the SIGIO mechanism, and if you have the vxWorks shell
active, it is using tyCo.

	I'd suggest as a solution to set the parameter NUM_TTY (in config.h)
to 0. Then the tyCo driver is not initialized, and you'll need to use telnet
to access the shell (not that bad !). Now, you'd have the SIGIO interrupt
free for use with your driver or application.

	Anyway, I'd recommend to look at the code in 
"$VW/src/drv/serial/unixSerial.c", to see how the tyCo driver gets connected
to the SIGIO mechanism. Note in tyCoDevCreate() the sentence:

    (void)intConnect (FD_TO_IVEC(pTyCoDv->u_fd), tyCoIntRd, pTyCoDv);

	I've never tried this, but hope this and the unixSerial.c file help
to solve your problem.
--


|============================================================================|
| Sergi Casas                #####  /  #####                                 |
| Hewlett-Packard Company    ###   /_  _ ### e-mail: sergi@hp-bpo.bpo.hp.com |
| Barcelona Division (BCD)   ##   / / / / ##                                 |
| Avda. Graells, 501         ##  / / /_/  ## Phone : +34 3 582 14 75         |
| 08190 S. Cugat (Barcelona) ###    /    ### FAX   : +34 3 582 25 15         |
| SPAIN                      ##### /   #####                                 |
|============================================================================|




From daemon@ntmtv.com  Tue Aug  2 05:37:57 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 05:38:04 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: comp.os.vxworks newsdigest

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 07:11:39 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 07:11:50 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: SIGIO on vxSim

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 07:11:41 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 07:11:54 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From mickey!@denali.uucp.cleaves  Tue Aug  2 07:38:26 1994
From: <cleaves%mickey.UUCP%denali.UUCP@cub.kscorp.com>
Date: Tue Aug  2 07:39:23 PDT 1994
Subject: help
help


From daemon@ntmtv.com  Tue Aug  2 08:35:45 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 08:35:57 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: help

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 08:35:48 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 08:36:06 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 08:54:18 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 08:54:28 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From mcswain@se01.wg2.waii.com  Tue Aug  2 09:39:00 1994
From: Marc McSwain <mcswain@se01.wg2.waii.com>
Date: Tue Aug  2 09:39:09 PDT 1994
Subject: vxworks_users is no longer with Northern Telecom, Mountain View

Is anybody else as tired of seeing these messages as I am?
What can we do to put a stop to them?


From daemon@ntmtv.com  Tue Aug  2 09:48:00 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 09:48:09 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 09:48:03 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 09:48:19 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 10:19:02 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 10:19:12 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 10:50:18 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 10:50:25 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users is no longer with Northern Telecom, Mountain View

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 11:54:05 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 11:54:21 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 11:54:11 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 11:54:41 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 11:54:14 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 11:54:43 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 12:25:03 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 12:25:15 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 13:26:35 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 13:26:49 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 13:26:38 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 13:27:05 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 13:26:41 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 13:27:12 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 13:26:44 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 13:27:18 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 15:00:21 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 15:00:37 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 15:00:24 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 15:00:48 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 15:00:27 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 15:01:00 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 15:00:30 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 15:01:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 16:34:16 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 16:34:30 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 16:34:19 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 16:34:44 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 16:34:25 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 16:34:56 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 16:34:22 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 16:34:57 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 17:05:24 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 17:05:37 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 17:05:27 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 17:05:59 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 17:05:30 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 17:06:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 17:05:35 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 17:06:16 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 18:39:15 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 18:39:31 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 18:39:18 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 18:39:47 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 18:39:22 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 18:39:57 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 18:39:24 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 18:40:02 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 19:41:33 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 19:41:44 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 20:12:49 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 20:13:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 20:12:51 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 20:13:15 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 20:12:55 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 20:13:24 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 21:15:19 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 21:15:34 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 21:15:22 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 21:15:48 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 21:15:26 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 21:16:04 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 21:15:28 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 21:16:06 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 22:49:10 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 22:49:26 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 22:49:07 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 22:49:39 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 22:49:04 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 22:49:43 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Tue Aug  2 22:49:18 1994
From: daemon@ntmtv.com
Date: Tue Aug  2 22:49:53 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 00:22:50 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 00:23:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 00:22:54 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 00:23:23 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 00:22:58 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 00:23:30 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 00:23:02 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 00:23:45 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 01:56:35 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 01:56:47 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 01:56:38 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 01:57:07 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 01:56:43 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 01:57:08 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 01:56:49 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 01:57:28 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 03:30:28 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 03:30:40 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 03:30:31 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 03:30:57 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 03:30:25 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 03:31:07 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 03:30:22 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 03:31:10 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@vxw.ee.lbl.gov  Wed Aug  3 04:00:38 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Aug  3 04:00:50 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Aug  3 04:00:25 PDT 1994

        Subject: Help! frc3ce MMU support
        Subject: Ping
        Subject: MVME332 driver
        Subject:  Not waiting for input
        Subject: Using C++ under VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Help! frc3ce MMU support
Date: 2 Aug 1994 18:30:41 GMT
From: najam@biostat.wisc.edu (Haroon Najam)
Organization: Department of Biostatistics, University of Wisconsin-Madison
Keywords: frc3ce MMU backplane vm
Message-ID: <31m3ch$iig@news.doit.wisc.edu>


Hello everyone,
	We, out here, are just starting up with vxWorks so if this sounds too
elementary, except my apology. Apparently it doesn't sound too simple for
WRS tech support though. But then its only their product... Here goes my problem.

We have two force cpu-3ce boards, running vxWorks 5.1(Sun10/40 host). Among 
other things, I am trying to get the backplane network to work. The master 
(cpu 0) boots up fine with the anchor at 0x600. Now this translates (or
should) to 0x6f000600 for the slave. But in booting up, or any other time that
I access this memory address (to see if I can see the telltale value of 0x8765),
the board hangs. Note that this is different from getting a bus error which
is usually the case for an invalid address. Infact the board hangs on any 
address between 0x60000000 and 0x6fffffff. I have checked and verified the
following things.
1) There is an entry for this region in sysPhysMemDesc.
2) configAll.h 
3) All the relevant constants are set to correct valuesin config.h etc

Infact WRS tech support at this point is suggesting that we ship the two boards
out to them so that they can check them out and get them working. I still
think that it is some sort of a configuration thing on our part that I don't
know as yet, or have overlooked, which is causing this problem. Part of the
reason I think this maybe the case is that I have also noticed, that despite
the fact that we have installed VxVMI and I have included the line
INCLUDE_MMU_FULL in configAll.h, vxWorks is still starting up with minimal
MMU support. This situation is being caused by the following two lines in
config.h:
#define INCLUDE_MMU_BASIC   /* undefine for optional VxVMI package */
#undef  INCLUDE_MMU_FULL    /* use for optional VxVMI package */
Well you think it would be simple to reverse the effect of the above statements.
Right? Wrong. If I compile with INCLUDE_MMU_FULL defined the boards don't boot.
The following happens:
- -----------------------------------------------------------
       [VxWorks Boot]: @
 
       boot device          : ln
       processor number     : 0 
       host name            : tinman
       file name            : /tools/vw/config/frc3ce/vxWorks
       inet on ethernet (e) : x.x.x.x:ffffff00
       inet on backplane (b): x.x.x.x
       host inet (h)        : x.x.x.x
       user (u)             : x
       flags (f)            : 0x0 
       target name (tn)     : target
 
       Attaching network interface ln0... done.
       Attaching network interface lo0... done.
       Loading... 506176 + 39336 + 25208
       Starting at 0x20000...
 
 
       [VxWorks Boot]: 
- -----------------------------------------------------------
i.e. it jumps back to the Boot prompt with no error messages. I have no clue on
this one. I also don't know if the two problems are related (I hope they are). 

So if somebody has run into such a situation or if you have any insights into how
these sub-systems behave, please let me know something. Or guide me as to what 
things to look at and look (out) for. I am quite desperate. Thanks in anticipation.
If you would prefer to, you can e-mail me at najam@biostat.wisc.edu

Haroon Najam				najam@biostat.wisc.edu
Waisman Center for Mental Retardation and Human Development
University of Wisconsin-Madison

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

Newsgroups: comp.os.vxworks
Subject: Ping
Date: Tue, 2 Aug 1994 17:53:27 GMT
From: jh@nsy.structure (Jomar Honsi)
Organization: Sun Microsystems, Inc.
Message-ID: <Ctx5p4.3sp@liverpool.ac.uk>
Reply-To: jh@nsy.structure
Sender: news@liverpool.ac.uk (News System)

Does anyone know if there exists a 'ping' function for VxWorks, and where I can get
one from ?

Thank you 
- ---
** Jomar Honsi                     Phone:  + (44)(51)7943398
** Department of Physics           E-mail: jh@ns.ph.liv.ac.uk
** University of Liverpool, UK


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

Newsgroups: comp.os.vxworks
Subject: MVME332 driver
Date: Wed, 3 Aug 94 08:39:43 GMT
From: jpcalvez@ifremer.fr (Jean Pierre Calvez)
Organization: Ifremer
Message-ID: <1994Aug3.083943.8077@molene.ifremer.fr>
Reply-To: jpcalvez@ifremer.fr
Sender: news@molene.ifremer.fr


I have a probleme concerning a driver for MVME332 board. There is a delay in sending a character to a serial line. This delay varies continuously from a few milliseconds
(that's normal) up to 20 or 25 milliseconds. The variation of this delay is not at 
random, but in a saw teeth form.
I wonder if this is due to the driver, or to the 332's firmware.
Until now, Motorola is reluctant to provide informations and claims that they don't
master the firmware.
Communications between CPU host (here MVME147) and MVME332 are fairly complex, and 
several possibilities of initializing the 332 are opened. 

Are there ways not to use, and other to prefer ?

In the case this problem cannot be solved, are there other intelligent serial board
with an existing driver under VxWorks ? I'm just interested in serial ports.

Thanks for any comment.


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

Newsgroups: comp.os.vxworks
Subject:  Not waiting for input
Date: Wed, 3 Aug 1994 09:52:45 GMT
From: rsgawera@wg.icl.co.uk (Raj Gawera)
Organization: International Computers Limited
Keywords: stdin
Message-ID: <CtyE3y.Ao@oasis.icl.co.uk>
Reply-To: rsgawera@wg.icl.co.uk
Sender: news@oasis.icl.co.uk

Dear VxPerts,
      Is there any way of looking at stdin to see if there is anything to read, or some
way of reading stdin without blocking.  I need to have a section of code which
loops performing some actions but periodically checks stdin for user input. On
unix I used getch() as part of the curses library but there is no equivalent in
VxWorks.
 	Thanks in anticipation,
		Raj 

Raj Gawera
Designer
ICL CSD
email : rsgawera@wg.icl.co.uk






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

Newsgroups: comp.os.vxworks
Subject: Using C++ under VxWorks
Date: Tue, 2 Aug 1994 22:06:47 GMT
From: rik@misty.ca.boeing.com (Rik slaven)
Organization: Boeing Commercial Airplane BCS Support
Message-ID: <103100003@misty.ca.boeing.com>


How does one go about using C++ under VxWorks?

Do I just get a copy of the g++ sources and build the compiler
"on top of" my current VxWorks cross-compiler?  Or do I need to
get something from WRS?




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

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


From daemon@ntmtv.com  Wed Aug  3 05:04:08 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 05:04:27 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 05:04:10 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 05:04:33 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 05:04:15 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 05:04:56 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 05:04:18 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 05:04:58 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 05:04:21 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 05:05:08 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: comp.os.vxworks newsdigest

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 06:37:50 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 06:38:08 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 06:37:53 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 06:38:29 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 06:37:57 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 06:38:37 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 06:37:59 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 06:38:41 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 06:38:04 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 06:38:52 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From rhin!joergb@lbl.gov  Wed Aug  3 06:38:06 1994
From: rhin!joergb@lbl.gov
Date: Wed Aug  3 06:39:05 PDT 1994
Subject: curses for VxWorks
Greetings,

did anybody use curses (to build semi-graphical output on e.g. an
VT100 terminal) with VxWorks ?

Thanks for any information.



Joerg Bertholdt, FAE

Wind River Systems GmbH
Freisinger Strasse 34
85737 ISMANING 
GERMANY

+49 89 96 09 49 49 phone
+49 89 96 09 49 40 fax

Email: joergb@wrsec.fr
 


From crispen@eight-ball.hv.boeing.com  Wed Aug  3 07:35:27 1994
From: crispen@eight-ball.hv.boeing.com (Bob Crispen)
Date: Wed Aug  3 07:35:40 PDT 1994
Subject: Re: curses for VxWorks
>Joerg Bertholdt, FAE asks:

>did anybody use curses (to build semi-graphical output on e.g. an
>VT100 terminal) with VxWorks ?

I did, with the vwcurses0[1-7] files at vxworks_archive@ncar.ucar.edu.
Works like a charm.  Note, it's Berkeley curses and not System V
curses, but we can use either on our Sun (SunOs).  I decided to do
some parallel development (the VME system wasn't always available).
In everything I've tried, curses often behaved maddeningly, but it
behaved on my VxWorks host through an xterm or a sun (shelltool) window
exactly like the Sun version did.  We all ought to give a cheer to
Georg Feil for this splendid package.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From guthrie@power.amasd.anatcp.rockwell.com  Wed Aug  3 07:47:31 1994
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Wed Aug  3 07:47:42 PDT 1994
Subject: Northern Telecom
I am the only one getting "lots" of messages from
Northern Telecom in Mountain View.

Can the exploder administrator please take the Northern
Telecom e-mail address out of the list.

	Robert Guthrie
	Rockwell


From guthrie@power.amasd.anatcp.rockwell.com  Wed Aug  3 07:53:17 1994
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Wed Aug  3 07:53:31 PDT 1994
Subject: Not waiting for input
Raj Gawera:
	You should be able to use the select function on the
stdin file descriptor, just like in unix.
Example:
#include <stdio.h>
#include <sys/time.h>
main()
{
static struct timeval stimeout = {0,0};
char temp;
int loop_counter;
int fdesc;

loop_counter = 0;
while(1)
{
        loop_counter++;
        fdesc = 1<<fileno(stdin);
        if (select(32,&fdesc,0,0,&stimeout)) {
                temp = getc(stdin);
                printf("%d\n",loop_counter);
                fflush(stdout);
        }
}

}
The select will return true if there is anything in stdin. One potential
problem is that it won't get anything until a <cr> is entered. To change
that behavior, you have to put stdin into raw mode.

	Robert Guthrie
	Rockwell


From dowling@cub.kscorp.com  Wed Aug  3 08:34:24 1994
From: Bob Dowling <dowling@cub.kscorp.com>
Date: Wed Aug  3 08:34:33 PDT 1994
Subject: Ping and getch()

Jomar Honsi (jh@ns.ph.liv.ac.uk) asks:
> Does anyone know if there exists a 'ping' function for VxWorks, and 
> where I can get one from ?

The VxWorks archive lists one such function.  To get it, send the following
line as the body of a message to vxworks_archive@ncar.ucar.edu:

send ping01 from vx

Also, Raj Gawera (rsgawera@wg.icl.co.uk) asks:
> Is there any way of looking at stdin to see if there is anything to read, or
> some way of reading stdin without blocking.

Yes, there is.  You put stdin into Raw mode (the opposite of Line mode) and
look to see if any characters have arrived.  (You are then simulating the
IBM-PC function kbhit() supplied by Microsoft, Borland, etc.)  The crwait()
function I wrote contains the same logic, and can be modified to do as little
as kbhit() (take out the "while" and "read()") or as much as getch() - just
uncomment the "return" statement.  crwait() works as shown here on a National
Instruments VXIcpu030 (an MVME147 look-alike) with VxWorks 5.0.1 and should
work fine for you.

Regards,

Bob Dowling, Software Engineer       dowling@kscorp.com
KineticSystems Corp.                 (815) 838-0005 x335
900 N. State St.
Lockport, Illinois 60441
/* -------------------- cut here -----*/
#include "vxWorks.h"
#include "stdioLib.h"
#include "ioLib.h"

void crwait( void )
{
   char   answer;
   int    normal, new, ncount = 0;

   printf("\n\n                    Hit any key to Continue\n");
   new = normal = ioctl(0, FIOGETOPTIONS, &ncount);

/*printf("options word value was %X\n", new);*/
/* Wait for all output to get out */
   do
   {
      ioctl(0, FIONWRITE, &ncount);
   }
   while( ncount > 0 );

/* NOW reset STDIN to "raw input", not line, mode */
   new &= ~OPT_LINE;
   ioctl(0, FIOSETOPTIONS, (int *)new);

/* WAIT for key to be hit - comment out the "while" if you just want to
 * know if a character has been received
 */
   while( ncount < 1 )
   {
      ioctl(0, FIONREAD, &ncount);  /* you NEED this */
   }

   read(0, &answer, 1);

/* Put STDIN back the way we found it (Highly Desireable!) */
   ioctl(0, FIOSETOPTIONS, (int *)normal);

/* return( answer ); this is _your_ choice */
}


From daemon@ntmtv.com  Wed Aug  3 08:42:53 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:43:10 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:42:55 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:43:20 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:00 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:43:48 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:02 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:43:53 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: curses for VxWorks

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:06 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:44:12 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:10 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:44:30 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:13 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:44:34 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: curses for VxWorks

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 08:43:17 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 08:44:53 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Northern Telecom

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 09:15:49 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 09:16:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Not waiting for input

vxworks_users is no longer with Northern Telecom, Mountain View



From prb@aplexus.jhuapl.edu  Wed Aug  3 09:36:59 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Wed Aug  3 09:37:14 PDT 1994


Hi,

Is anyone awake?
Don't you think that everyone is tired of being inundated with
these annoying messages from Northern Telecom:


vxworks_users is no longer with Northern Telecom, Mountain View



Please Please Please, delete them from the mailing list.

	

	Thanks from all of the subscribers


From dwampl@atl.com  Wed Aug  3 09:42:30 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Wed Aug  3 09:42:42 PDT 1994
Subject: Re:  Subject: Using C++ under VxWorks
> Newsgroups: comp.os.vxworks
> Subject: Using C++ under VxWorks
> Date: Tue, 2 Aug 1994 22:06:47 GMT
> >From: rik@misty.ca.boeing.com (Rik slaven)
> Organization: Boeing Commercial Airplane BCS Support
> Message-ID: <103100003@misty.ca.boeing.com>
> 
> How does one go about using C++ under VxWorks?
> ....

We've been experimenting with "WindC++" from WRS, along with ObjectCenter.  
The package has the feel of a "version 1.0" tool, but has been sufficiently 
reliable for our needs.  It's not free, of course, but it's a viable choice.

We haven't tried using "g++", so I can't compare the two approaches.

Dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+





From rgonzale@esperanza.harvard.edu  Wed Aug  3 10:18:48 1994
From: rgonzale@esperanza.harvard.edu (Ray Gonzalez)
Date: Wed Aug  3 10:18:59 PDT 1994
Subject: Re: vxworks_users@vxw.ee.lbl.gov IS GONE

Could somebody please do something about this messages, It's not funny anymore.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Raymond Gonzalez            <___<      * *     Smithsonian Astro. Observatory
gonzalez@cfa.harvard.edu   </SMA\<     * @ *   60 Garden St.   MS-78
Office (617) 496-7622      <\___/<      o *    Cambrigde, Mass    02138
FAX    (617) 496-7554   *___/<  <     *  * o* 
          (other email address: rgonzale@esperanza.HARVARD.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From stan@lassen.rti.com  Wed Aug  3 10:38:39 1994
From: stan@lassen.rti.com (Stan Schneider)
Date: Wed Aug  3 10:38:54 PDT 1994
Subject: Re: Not waiting for input

>> From: rsgawera@wg.icl.co.uk (Raj Gawera)
>> Organization: International Computers Limited
>>
>> Dear VxPerts,
>>       Is there any way of looking at stdin to see if there is anything
>> to read, or some way of reading stdin without blocking.  I need to
>> have a section of code which loops performing some actions but
>> periodically checks stdin for user input. On unix I used getch() as part
>> of the curses library but there is no equivalent in VxWorks.
>>  	Thanks in anticipation,
>> 		Raj 
>> 

I've appended the source to QueryGetKey (simplified a bit), one of the
functions in the "Query" package included with RTILib...

Enjoy.

        -- Stan

P.S.  I hope this doesn't generate 372 responses from ntmtv.com...

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

/* ------------------------------------------------------------------
   QueryKeyReady \- Check for user input.

   This routine provides a non-blocking single character read.

   Thus, QueryKeyReady can be used to poll the keyboard for input.  Under Sun
   UNIX in cmdtools with scrolling enabled, no keyboard activity is reported to
   the I/O system until a <CR> is hit.  Thus, QueryKeyReady will return 0 until
   <CR> is pressed.

   Most applications will want to flush the input stream (via QueryFlushChar or
   QueryFlushCR, or by calling QueryKeyReady until it returns 0) before calling
   this function.

   RETURNS: 0, if no character is ready, or the character read, if available.

   EXAMPLE:
    To execute a loop until the user hits CR:

	printf("Type <CR> to stop.\\n");
   	QueryFlushChar(stdin);
	while(!QueryKeyReady(stdin)) {
	    execute your code ...
	}

   SEE ALSO: QueryFlushCR, QueryFlushChar
*/
public
char QueryKeyReady(FILE *fp)
{
    long n;
    char c;
    int fd;

    fd = (fp == stdin) ? 0 : fileno(fp);

    /* This is a hack, but avoids the overhead of changing to "raw" mode.  */

    ioctl(fd, FIONREAD, (long) &n);	/* Anything in the channel? */
    #if VXWORKS_VERSION_5_1_OR_BETTER
      n += (fp)->_r;		/* or in buffer? */
    #else
      n += (fp)->count;		/* or in buffer? */
    #endif

    if (n > 0) {
	c = getc(fp);		/* Yes, get a character. */
    } else {
	c = 0;			/* No, return 0. */
    }   
    return(c);
}




From Flemming_Kevin/macom_pbl_ctc@draft1.macom.com  Wed Aug  3 10:44:26 1994
From: Flemming_Kevin/macom_pbl_ctc@draft1.macom.com
Date: Wed Aug  3 10:44:36 PDT 1994
Subject: ftp server doesn't support file delete
Item Subject: Message text
Help!!  I have a requirement to support file deletion from a remote
station via the ftp server.  The server supplied with VxWorks 5.1
doesn't support a delete command.  

Is there a way around this?  Can I intercept the deletes or add a new
command??  

Any help would be appreciated.


From daemon@ntmtv.com  Wed Aug  3 10:47:52 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 10:48:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Ping and getch()

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:07 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:19:22 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:10 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:19:43 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:14 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:20:06 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:17 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:20:30 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:19 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:20:40 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: 

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:25 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:20:59 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:32 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:21:19 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:42 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:21:43 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:40 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:21:45 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 11:19:45 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 11:22:05 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: Subject: Using C++ under VxWorks

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:21:38 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:21:57 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: Not waiting for input

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:21:41 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:22:17 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:21:51 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:22:48 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: ftp server doesn't support file delete

vxworks_users is no longer with Northern Telecom, Mountain View



From nrd1vxs@nrd.ups.com  Wed Aug  3 12:43:51 1994
From: nrd1vxs@nrd.ups.com (Victor Silva Contractor)
Date: Wed Aug  3 12:44:03 PDT 1994
:Submitted-by daemon@ntmtv.com  Wed Aug  3 11:19:17 1994
:Submitted-by: daemon@ntmtv.com
: 
:
:You have recently sent the following Email:
:
:To: vxworks_users@vxw.ee.lbl.gov
:Subject: vxworks_users@vxw.ee.lbl.gov IS GONE
:
:vxworks_users is no longer with Northern Telecom, Mountain View
:
:
:**********

AAAAAAAAAAAUUUUUUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGGHHHHHHHHHHHHHHH


From AW@lns62.lns.cornell.edu  Wed Aug  3 12:45:49 1994
From: "Andreas H. Wolf, OSU CLEO group, Wilson Lab, R. 315, 255-5748"
Date: Wed Aug  3 12:46:07 PDT 1994
Subject: Re: vxworks_users@vxw.ee.lbl.gov IS GONE
Hi folks,
	I'm getting sick of those messages popping up
	like mushrooms...
	Please, PLEASE, P_L_E_A_S_E stop this!

	Andreas Wolf ==8-0


From mad@strata.com  Wed Aug  3 12:50:12 1994
From: mad@strata.com (Madhu R. Grandhi)
Date: Wed Aug  3 12:50:31 PDT 1994
Subject: unsubscribe



From daemon@ntmtv.com  Wed Aug  3 12:52:52 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:53:07 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:52:57 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:53:33 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:05 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:54:06 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:12 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:54:27 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:18 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:54:52 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:20 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:55:10 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:28 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:55:39 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:42 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:56:02 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 12:53:44 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 12:56:20 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 13:55:17 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 13:55:29 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 13:55:21 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 13:55:47 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 13:55:25 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 13:55:53 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From greg@huey.jpl.nasa.gov  Wed Aug  3 14:01:39 1994
From: greg@huey.jpl.nasa.gov (Greg Wanish)
Date: Wed Aug  3 14:01:50 PDT 1994
Subject: unsubscribe



From daemon@ntmtv.com  Wed Aug  3 14:26:36 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:26:50 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: 

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 14:26:39 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:27:11 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: unsubscribe

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 14:26:43 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:27:32 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 14:26:51 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:27:43 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: Re: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 14:26:56 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:28:03 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From daemon@ntmtv.com  Wed Aug  3 14:27:00 1994
From: daemon@ntmtv.com
Date: Wed Aug  3 14:28:06 PDT 1994
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

You have recently sent the following Email:

To: vxworks_users@vxw.ee.lbl.gov
Subject: vxworks_users@vxw.ee.lbl.gov IS GONE

vxworks_users is no longer with Northern Telecom, Mountain View



From bordua@csg.lbl.gov  Wed Aug  3 14:45:04 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Wed Aug  3 14:45:13 PDT 1994
Subject: Test mail for bounce problem
This is test mail to see if the Northern Telecom bounce problem is fixed.

Sorry for the bandwidth.

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory


From bordua@csg.lbl.gov  Wed Aug  3 15:56:31 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Wed Aug  3 15:56:53 PDT 1994
Subject: Test mail for bounce problem

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

 
This is a 2nd test mail to see if the Northern Telecom bounce problem is fixed.

Sorry for the bandwidth.

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory


From bordua@csg.lbl.gov  Wed Aug  3 16:15:24 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Wed Aug  3 16:15:32 PDT 1994
Subject: 3rd Test mail for bounce problem
This is test mail to see if the Northern Telecom bounce problem is fixed.

Sorry for the bandwidth.

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory


From crispen@eight-ball.hv.boeing.com  Thu Aug  4 05:43:32 1994
From: crispen@eight-ball.hv.boeing.com (Bob Crispen)
Date: Thu Aug  4 05:43:41 PDT 1994
Subject: A proud father gets ready to take his lumps
There is absolutely no excuse for posting the following to the VxWorks
list, except that my kid is doing this:
-----
ROADMAP on LISTSERV@UA1VM.UA.EDU

   The Roadmap for the Information Superhighway Interactive Internet
   Training Workshop

   FREE Internet training workshop open to anyone who wishes to
   subscribe.  The entire Roadmap workshop will take place on the
   ROADMAP list (ROADMAP is a distribution list, not a discussion list).

   The Roadmap workshop sessions will cover: E-mail;  Listservs,
   Majordomo, Listproc and other distribution systems;  Usenet;  FTP;
   Archie;  Gopher;  Veronica;  Address Searches;  WAIS;  WWW;  and many
   other topics.  As a number of ROADMAP subscribers only have e-mail
   access, the Roadmap workshop will also teach how to access many
   Internet tools (FTP, Archie, Gopher, etc.) using E-mail.
 
   The first Roadmap for the Information Superhighway workshop will
   begin in *OCTOBER 1994*.  To subscribe, please send the following
   command in the BODY of your e-mail letter to LISTSERV@UA1VM.UA.EDU on
   the Internet:
 
       SUB ROADMAP yourfirstname yourlastname
 
   For example:
 
       SUB Roadmap Bill Gates
 
   Owner:  Patrick Crispen <PCRISPE1@UA1VM.UA.EDU>
-----
When he came home last night there were >2300 people signed up, and
he's gotta close the list at some reasonable number, so if there's
somebody in your organization who ought to be on this list, let them
know fairly soon.

Please send complaints about abusing vwexplo to me, not my son.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.hv.boeing.com    +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+


From xhd@zfssun1.tz.rus.uni-stuttgart.de  Thu Aug  4 07:49:06 1994
From: xhd@zfssun1.tz.rus.uni-stuttgart.de (Nikolaus Hild / ZFS)
Date: Thu Aug  4 07:49:14 PDT 1994
Subject: Re: tip & xterm
> Things seem to work OK but every once in a while, the xterm window
> just disappears.

This also happens using cu in a OpenWin cmdtool (SUN). By the way: Can
anybody tell me how to manage ^C not to be catched by cu?

 ____________________________________________________________________
|                                                                    |
| Nikolaus Hild                                                      |
| Centre for Manufacturing Technologies Stuttgart                    |
| Nobelstr. 15                                                       |
| 7000 Stuttgart 80                                                  |
| Germany                                                            |
|____________________________________________________________________|
|                                                                    |
| Phone: 0711 13162-41                                               |
| Fax:   0711 13162-11                                               |
| Email: xhd@zfssun1.tz.rus.uni-stuttgart.de                         |
|____________________________________________________________________|



From 100067.355@compuserve.com  Thu Aug  4 09:41:05 1994
From: Phil Weber <100067.355@compuserve.com>
Date: Thu Aug  4 09:41:11 PDT 1994
Subject: Serial I/O on SBus
Hello,

I am using a Themis SPARC LXE VME board. I have needs for a number of
serial I/O and, as my VMEbus is already loaded, I am contemplating to use
on my CPU a SBus card with 16 RS232 serial lines.
I don't think there is any problem to find such a board, the thing will
be to use it with VxWorks and not with Solaris which is the standard
for SBus add-ons. 

If no solution exist with an existing device driver, I will certainely
have to write one. I am afraid that finding programming information
for SBus cards may not be as easy as it is with VME.

Does anybody have experience ?

Thanks in advance




From bordua@csg.lbl.gov  Thu Aug  4 11:09:44 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Thu Aug  4 11:09:53 PDT 1994
Subject: Mail bounces related to Northern Telecom
This is in response to the mail I've been getting about the mail bounces that
seemed to be related to Northern Telecom in the last few days.

I have been spending quite a bit of time trying to figure out what caused the
problem.  I removed the ntmtv.com users from the list but that didn't work.

A filter was added to remove the mail from daemon@mtmtv.com which should cause
no more messages to the Exploder.

I regret that it took so long to figure out what was wrong.

Thank you for your patience,

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory


From tornado!lassen.com!scott@rambone.psi.net  Fri Aug  5 15:23:08 1994
From: scott@lassen.com (Scott Harper)
Date: Fri Aug  5 15:23:16 PDT 1994
Subject: gnu yacc overflow
I'm having a problem compiling a module using gcc version cygnus-2.2.3 as
supplied with vxWorks version 5.1. The module used to compile when the compiler
was running on a Sparc running SunOS using the compiler supplied with vxWorks 
version 5.0.2, but now that I am running solaris it produces the following 
error :
 
diag.c: In function `diag':
diag.c:980: yacc stack overflow before `('

Any suggestions on how I can resolve this problem would be appreciated

Please send any replies to stafford@lassen.com


From howard@sidney.nosc.mil  Mon Aug  8 09:53:24 1994
From: howard@sidney.nosc.mil (Mike Howard)
Date: Mon Aug  8 09:53:32 PDT 1994
Subject: Phone Number
Does anyone have the current phone number for Force Computers?  The number I have (408)370-3600 is disconnected.
				Thanks
              __  __  __                     
             /  \/  \/  \  o    /_          /^\    /
                /   /   /      /__)  __       /   /
               /   /   /  /   / \   /__)     /---/
              /   /   /__/\__/  /___\___    /   / o

------------------------------------------------------------------
                                |
 G. "Mike" Howard               |      _/      _/_/_/_/  _/_/_/_/_/_/_/
 NCCOSC RDT&E Div Code 714      |     _/_/    _/      _/      _/     _/
 Rm 234, Bldg 106, Bayside      |    _/ _/   _/      _/  _/_/_/      _/
 Ph: (619) 553-1524             |   _/  _/  _/_/_/_/        _/      _/
 Fax: (619) 553-5229            |  _/   _/ _/  _/      _/_/_/      _/
 e-mail: howard@sidney.nosc.mil | _/    _/_/    _/   _/   _/     _/
                                |_/      _/      _/  _/_/_/_/_/_/
                                |
------------------------------------------------------------------


From prb@aplexus.jhuapl.edu  Mon Aug  8 11:40:52 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Mon Aug  8 11:40:59 PDT 1994
Subject: TCL 7.3

Hi,

I am trying to get a copy of Graham Heye's port of tcl7.3  and dp-3.2
for vxWorks.  Does anybody no where I might find it?

	Thanks,


+====================================================================+
|       __     ____         __     __                                |
|      /\ \   /  \ \       /\_\__ /\ \      Johns Hopkins University |
|     /  \_\ | /\ \ \     / / /\_\\ \ \     Applied Physics Lab.     |
|    / /\ | |\ \/  \ \   / / / / / \ \ \                             |
|   /  \/ |_| \  /\ \_\ / / / / /   \ \ \   Paul R. Bade             |
|  / /\__/_/   \ \ \/_// / / / /    / / /   (301)-953-6000 x8681     |
| / / /         \ \_\  \ \/ / /    / / /    prb@aplexus.jhuapl.edu   |
| \/_/           \/_/   \__/_/     \/_/                              |
|               __     ____         __       __                      |
|              /\ \   /  \ \       /\ \     /\ \                     |
|             /  \_\ | /\ \ \     /  \_\   /  \ \                    |
|            / /\ | |\ \/  \ \   / /\ |_| / /\ \ \                   |
|           /  \/ |_| \  /\ \_\ / / / | | \/ /  \ \                  |
|          / /\  / /   \ \ \/_// / / / /    / /\ \_\                 |
|          \ \/ / /     \ \_\  \ \/ / /     \/ / / /                 |
|           \__/_/       \/_/   \__/_/        /_/_/                  |
|                                                                    |
+====================================================================+


From mea@mclean.sparta.com  Mon Aug  8 11:59:52 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Aug  8 12:00:00 PDT 1994
Subject: Re: VxWorks FAQ and related files
Greetings!

  After much wrangling with our site security types, I have finally managed
to get an anonymous FTP account set up on our system (we are also working
to link it into our new Mosaic WWW home page) :-).  It took a *lot* of 
convincing that at least most of you were reasonable and wouldn't try
to crash our system.  Please don't make a liar out of me ;-).  You can 
now access the FAQ and it's related files via anonymous FTP at:

teacher.mclean.sparta.com     (157.185.32.10)

You will find all of the VxWorks FAQ files as well as a copy of the
VxWorks User's Group archives as of 8/8/94.  I figured that it wouldn't
hurt to have a backup archive site :-).  We have a 56KB line to the
Internet so access should be reasonably quick.  (Hey Rich, is there any
way to make updates between the two sites automagic?) Since the FAQ is
now 80+ KBytes, I'm trying to figure out how best to split it into
pieces so that most mailers won't choke.  Anyone with FAQ experience
that knows how to do this, please contact me so we can start sending
out copies of the FAQ again.  I could just arbitrarily split it into
two pieces and send it to the exploder for the time being.  If there is
sufficient interest from the group, I'll do that in the next day or
so.

Thanks for your patience in this hand-off from Hwajin to me.  

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From howard@sidney.nosc.mil  Mon Aug  8 13:14:31 1994
From: howard@sidney.nosc.mil (Mike Howard)
Date: Mon Aug  8 13:14:39 PDT 1994
Subject: RE: Phone Number
Thanks for the Rapid response from all who answered
FYI Force's new corporate number is (408) 369 6000
              __  __  __                     
             /  \/  \/  \  o    /_          /^\    /
                /   /   /      /__)  __       /   /
               /   /   /  /   / \   /__)     /---/
              /   /   /__/\__/  /___\___    /   / o

------------------------------------------------------------------
                                |
 G. "Mike" Howard               |      _/      _/_/_/_/  _/_/_/_/_/_/_/
 NCCOSC RDT&E Div Code 714      |     _/_/    _/      _/      _/     _/
 Rm 234, Bldg 106, Bayside      |    _/ _/   _/      _/  _/_/_/      _/
 Ph: (619) 553-1524             |   _/  _/  _/_/_/_/        _/      _/
 Fax: (619) 553-5229            |  _/   _/ _/  _/      _/_/_/      _/
 e-mail: howard@sidney.nosc.mil | _/    _/_/    _/   _/   _/     _/
                                |_/      _/      _/  _/_/_/_/_/_/
                                |
------------------------------------------------------------------


From legoas_marco_a@space.honeywell.com  Mon Aug  8 14:56:29 1994
From: "Legoas Marco A" <legoas_marco_a@space.honeywell.com>
Date: Mon Aug  8 14:56:36 PDT 1994
Subject: Tape drives

I am Looking for high throughput (1.5 Meg/Sec) tape drive with drivers
for VxWorks. Has anybody had any experience with 8mm drives (Cybernetics,
Exabyte, etc..)?. My concern is that we need to write a tape using a format
that can be read across plataforms (i.e. written by a VME cpu with VxWorks, and
read by a Vax or Unix system). Any suggestions?







Marco A. Legoas
mlegoas@space.honeywell.com



From lerible@raptor.sandia.gov  Tue Aug  9 08:05:16 1994
From: lerible@raptor.sandia.gov (Loren E. Riblett)
Date: Tue Aug  9 08:05:23 PDT 1994
Subject: remote file access
Hello,

We have a system with multiple VxWorks crates tied together with ethernet.  The
main control computer has several pcmcia file systems that we would like to
access from the other crates.  

Currently we are using a rsh daemon to essentially 'cat' the files to the remote
chassis, but would like to access the files directly (kind'uv like nfs access
to a SUN host).  What is the best way to accomplish this?

Thanks in advance.

Loren

      _/_/_/_/   _/      _/   _/         Loren E. Riblett
     _/         _/_/    _/   _/         Email:  lerible@sandia.gov
    _/_/_/_/   _/  _/  _/   _/         (505) 845-8841  FAX  844-4157
         _/   _/    _/_/   _/         Senior Member of the Technical Staff
  _/_/_/_/   _/      _/   _/_/_/_/   Image & Signal Processing Department 9137
    Sandia National Laboratories   Albuquerque, NM 87185     



From mike@imatron.com  Wed Aug 10 15:22:54 1994
From: "Mike Morrison[Software Eng]" <mike@imatron.com>
Date: Wed Aug 10 15:23:00 PDT 1994
Subject: mvme167/5.1.1 -  MMU and slooooow booting

I am trying to get around the problem of slow boot time on
my mvme167 running 5.1.1.
The more VME memory I add to the system and to the
sysPhysMemDesc table in sysLib.c the longer the boot time.
Our system has to support over 640MB of VME memory and boot time
takes around 10 minutes in this configuration.  
I attempted to turn off the MMU by #undefing INCLUDE_MMU_BASIC 
in mv167/config.h but got error messages from eiattach bitching
about cache coherency problems.  Everything booted up fine in
about 15 seconds when I turned off both MMU and cacheing.

I talked to WRS but didn't get anywhere.  I got the impression that
they really didn't want to deal with the problem (I didn't even get
a TSR for my trouble).  They basically told me that if I turned off 
the MMU I would also have to turn off the cache.  They also told 
my they are doing what Motorola says they must do in terms of
MMU initialization. 

I talked to a system engineer at Motorola who told me that this kind
of boot time is not nesessary to initialize the tables that the MMU
uses.
  
Does anyone have this problem solved?  I want fast booting AND cacheing.

Any pointers on getting around this problem will be appreciated.

Thanks,

Michael Morrison
Imatron Ultrafast CT.
(415) 583-9964
mike_morrison@imatron.com



From legoas_marco_a@space.honeywell.com  Thu Aug 11 05:24:06 1994
From: "Legoas Marco A" <legoas_marco_a@space.honeywell.com>
Date: Thu Aug 11 05:24:12 PDT 1994
Subject: DLT tape drives
I am looking for information related to DLT tape drives. (ie. DEC TZ87, Cipher,
DLT2000, DLT2700, etc..). Has anybody use them under VxWorks?.Information on
possible VxWorks drivers would be appreciated.
 
We need to be able to write to a DLT tape using VxWorks on a Heurikon 3500, and
then read the tape using a Vax with VMS...yack!. This means that the formats
have to be compatible between the VxWorks and the DEC systems.

Any information will be appreciated.



Marco A. Legoas
malegoas@space.honeywell.com



From rec@yin.ucsd.edu  Thu Aug 11 09:00:17 1994
From: rec@yin.ucsd.edu (Richard E. Currier)
Date: Thu Aug 11 09:00:25 PDT 1994
Subject: unsubscribe
unsubscribe


From ddavies@xmission.com  Thu Aug 11 09:48:36 1994
From: ddavies@xmission.com (Doug Davies)
Date: Thu Aug 11 09:48:43 PDT 1994
Subject: Re: mvme167/5.1.1 -  MMU and slooooow booting
> I am trying to get around the problem of slow boot time on
> my mvme167 running 5.1.1.
> The more VME memory I add to the system and to the
> sysPhysMemDesc table in sysLib.c the longer the boot time.
> Our system has to support over 640MB of VME memory and boot time
> takes around 10 minutes in this configuration.  
> I attempted to turn off the MMU by #undefing INCLUDE_MMU_BASIC 
> in mv167/config.h but got error messages from eiattach bitching
> about cache coherency problems.  Everything booted up fine in
> about 15 seconds when I turned off both MMU and cacheing.

Get a Motorola 68040 book and read up on the DTTR (Data Transparent
Translation Registers).  You can use the DTTR's to get around the
need of adding entries to the sysPhysMemDesc table.  And, you are
correct about adding to the boot time of the mv167.  The more
address space that you add to the sysPhysMemDesc table, the longer
it takes the 68040 to build page descriptors when it boots.  The
DTTR's "transparently translate" the address, thus saving the MMU
from having to walk the page descriptor table.  Realize that anything
(address space) that you enable using the DTTR's will supercede
any entry in the sysPhysMemDesc table that may cover the same address
range (taking on the attributes given by the DTTR definition).

Using the DTTR's can be a little bit tricky in that their resolution
is limited to 16M chunks, plus the mask that is used to ignore specified
address bits can get you into trouble if you are not careful.

I am giving you this explaination from memory, since I don't have
a 68040 book handy.  If you are unable to figure out the DTTR's you
can either call Wind River and get their App. note on setting up
DTTR's (yes they do have one, why they did not give that information
to you when you called, I don't know...) or get back with me direct
and I will try and scare up an example.  I recently changed companies
that I work for and don't have my old examples handy...

> I talked to WRS but didn't get anywhere.  I got the impression that
> they really didn't want to deal with the problem (I didn't even get
> a TSR for my trouble).  They basically told me that if I turned off 
> the MMU I would also have to turn off the cache.  They also told 
> my they are doing what Motorola says they must do in terms of
> MMU initialization. 

<big grin> ...

> I talked to a system engineer at Motorola who told me that this kind
> of boot time is not nesessary to initialize the tables that the MMU
> uses.

I have had this complaint since 5.1 was released.  I don't see what
is so hard about taking the sysPhysMemDesc table and seeing how much
of it could be done with a DTTR, it would greatly enhance the booting
time of all 68040 based boards.  Or...  providing DTTR support with
an explaination as standard issue.

-Doug

---- no fancy sig yet ----
Douglas Davies
ddavies@xmission.com


From mike@imatron.com  Thu Aug 11 11:52:08 1994
From: "Mike Morrison[Software Eng]" <mike@imatron.com>
Date: Thu Aug 11 11:52:14 PDT 1994
Subject: Re: mvme167/5.1.1 -  MMU and slooooow booting


Thanks for the info...

I have already configured the TTRs so I have fixed the boot time
problem and still see all the VME memory.  My problem is the cache.
I understand that device drivers call upon the MMU to get 
"cache-safe" buffers (somebody help me here). Since the MMU is 
disabled, they can't do this.  
If cacheing is enabled (MMU off), I get cache coherency problems from 
device drivers that do DMA.   How can I have a cache and no MMU
and still have the vxworks drivers work?  Is this possible?

If I set [DI]TTR0 to cover local memory and enable the cache
by setting the CM bits, then #undefing USER_I_CACHE_ENABLE and 
USER_D_CACHE_ENABLE in config/all/configAll.h, will cacheing still
be enabled? or will it be disabled when the cacheLib is initialized.


I indend to test all this out so I may be able to answer my own 
questions, but if anyone knows, I'd sure like to here about it.

Thanks again



********************************************************************
*	Michael Morrison	      	mike_morrison@imatron.com  *
********************************************************************



From force-c!fci.COM!dorlow@uunet.uu.net  Thu Aug 11 12:37:11 1994
From: dorlow@fci.com (Operator)
Date: Thu Aug 11 12:37:18 PDT 1994
Subject: Register for exploder

Please register me for the exploder.

Name:		Dennis Orlow
Company:	Force Computers Inc.
Address:	601 Lakeshore Parkway
		Suite 710
		Minnetonka, MN 55305
Telephone #:	(612) 449-4224
Email Address:	dorlow@fci.com

I am a Field Applications Engineer with Force Computers. The hardware platforms
I am interested in are Force Computers IBC-20, CPU-30, CPU-40, CPU-2CE, CPU-3CE,
CPU-5CE, CPU-10.	

Thank You.

Sincerely

Dennis Orlow					FORCE COMPUTERS Inc.
Field Applications Engineer			601 Lakeshore Parkway, Suite 710
EMAIL: dorlow@fci.com				Minnetonka, MN 55305
Phone: (612) 449-4224				Fax: (612) 449-4230


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



From tsb@mclean.sparta.com  Thu Aug 11 13:10:57 1994
From: tsb@mclean.sparta.com (Todd S. Brackett)
Date: Thu Aug 11 13:11:03 PDT 1994
Subject: newsgroup cross feed
Hi!

I just noticed that I haven't seen a cross feed from the newsgroup to the
exploder in over a week.  Does this just mean it hasn't been used, or is 
it "broken"?

Regards,

-----------------------------------------------------------
|Todd S. Brackett         |  Voice -> 703 448 1683 x249   |
|tsb@mclean.sparta.com    |  FAX   -> 703 734 3323        |
|_________________________________________________________|
|                                                         |
|     /\\     SPARTA, Inc.                                |
|    ///\\    7926 Jones Branch Drive                     |
|   /////\\   Suite 900                                   |
|  /////  \\  McLean, VA 22102                            |
| / \\\\\  \\                     "Life is like baseball, |
| \  \\\\\ //                      some days you win,     |
|  \  //////                       some days you lose,    | 
|   \//////  SPARTA                some days it rains..." |
|    \////   Pride In Performance                         |
|     \//                                                 |
___________________________________________________________



From legoas_marco_a@space.honeywell.com  Thu Aug 11 15:18:36 1994
From: "Legoas Marco A" <legoas_marco_a@space.honeywell.com>
Date: Thu Aug 11 15:18:43 PDT 1994
Subject: Exabyte drivers


 I was checking to see if anyone out there has a vxWorks driver for the Exabyte
8500. If you are willing to share it, I would really appreciate it.

Marco A. Legoas
(813)539-4167
malegoas@space.honeywell.com


From SB06684%MSGATE!AMGATE.HEPNET@csa4.lbl.gov  Wed Aug  3 23:05:21 1994
From: "MSGATE!AMGATE::SB06684"@hac2arpa.hac.com
Date: Wed Aug  3 23:05:28 PDT 1994
Subject: mvme167 & MMU
From: Iveland, Scott T
Date: Fri, Aug 12, 1994 12:12 PM
Subject: mvme167 & MMU
To: vxexpolder
Re the following:

>I am trying to get around the problem of slow boot time on
>my mvme167 running 5.1.1.
>The more VME memory I add to the system and to the
>sysPhysMemDesc table in sysLib.c the longer the boot time.
>Our system has to support over 640MB of VME memory and boot time
>takes around 10 minutes in this configuration.  
>I attempted to turn off the MMU by #undefing INCLUDE_MMU_BASIC 
>in mv167/config.h but got error messages from eiattach bitching
>about cache coherency problems.  Everything booted up fine in
>about 15 seconds when I turned off both MMU and cacheing.

>I talked to WRS but didn't get anywhere.  I got the impression that
>they really didn't want to deal with the problem (I didn't even get
>a TSR for my trouble).  They basically told me that if I turned off 
>the MMU I would also have to turn off the cache.  They also told 
>my they are doing what Motorola says they must do in terms of>
>MMU initialization. 

>I talked to a system engineer at Motorola who told me that this kind
>of boot time is not nesessary to initialize the tables that the MMU
>uses.
  
>Does anyone have this problem solved?  I want fast booting AND cacheing.

>Any pointers on getting around this problem will be appreciated.

>Thanks,

>Michael Morrison
>Imatron Ultrafast CT.
>(415) 583-9964
>mike_morrison@imatron.com

We have one system with about 500Mbytes and another that will have over 1Gbyte 
of memory. I found the same delay problem when booting up. The way we got 
around the problem was to use the Transparent Translation Registers of the 
68040. The 040 has 4 TTR's. Two for data and two for instructions. We only 
used the data registers (DTT0 & DTT1). The 040 users manual has a description 
of the registers and how they work (see sections 6.3 and 6.6.3)
The following is an example of the type of code we use to program the 
registers.


***************************************************************************

 /* VME memory 0x20000000-0x3fffffff,enabled,ignore sup/user mode,cache 
Inhibited-Serialzed */
#define DTT0_VALUE  0x301fc040 

 /* VME memory 0x40000000-0x7fffffff,enabled,ignore sup/user mode,cache 
Inhibited-Serialzed */
#define DTT1_VALUE  0x403fc040

unsigned int  dtt0Value= DTT0_VALUE,dtt1Value=DTT1_VALUE

asm("movec %0,dtt0": :"d"(dtt0Value));
asm("movec %0,dtt1": :"d"(dtt1Value));

***************************************************************************

After this code executes the VME space from 0x20000000 to 0x7fffffff will be 
visable to the 040. Do not list these areas in sysLib.c.


If you have any questions you can E-mail me at siveland@msmail3.hac.com



From satish@ltis.loral.com  Fri Aug 12 17:44:25 1994
From: Satish Mali <satish@ltis.loral.com>
Date: Fri Aug 12 17:44:32 PDT 1994
Subject: Memory problems with VxWorks

I am forwarding this message for John

Subject: memory usage problem with vxworks

I am sure that this problem has come up before, so I am looking for any 
information that may have been learned by others.

Our current board has a rather restrictive amount of memory (512K).
As such, we are concerned with the amount that VxWorks itself is using. 
What can we do to 'slim down' VxWorks? Code is not the problem, as we are 
running ROM_RESIDENT.  But the size of the data and bss areas for the simple 
kernel I am building is still around $3e000, before we start allocating 
memory for stacks, buffers, queues, etc.  What can we do to free up memory? 
How much memory do the various sub-systems use?

On the same subject, the RAM_LOW_ADRS value we use is $10000. This represents 
12% of our available memory space. What can I do to reduce this limit? I have 
tried to change it to some other, lower, value, and those lernels fail to 
start up. What is going on below this address? Am I not doing something when 
I change the value that I should be doing? Why can't I set it to zero? Or, 
more likely, some address above the hardware fault address of $80? i would 
probably set it to $800 if I could. Any ideas?

john

Thanks
-satish

********************************************************************************
* Satish Mali                            email : satish@ltis.loral.com         *
********************************************************************************



From BRIDGERUNNER@delphi.com  Sat Aug 13 00:44:53 1994
From: BRIDGERUNNER@delphi.com
Date: Sat Aug 13 00:45:01 PDT 1994
Subject: subsription request
I would like to subscribe to the vxPerts forum (group). I have used vxWorks
since 1986 on three or four different projects and would like to keep abreast
of issues and projects involving this technology. I would also like to meet
other vxWorks users. My name is William (Bill) Gibbons and my internet address
is Bridgerunner@Delphi.com. Thank you.


From morriss@smtplink.indigo.co.il  Sun Aug 14 02:07:19 1994
From: Steve Morris <morriss@smtplink.indigo.co.il>
Date: Sun Aug 14 02:07:27 PDT 1994
Subject: Re: mvme167/5.1.1 -  MMU and slooooow booting

Text item: Text_1

        
Re:mvme167/5.1.1 -  MMU and slooooow booting

> I am trying to get around the problem of slow boot time on my mvme167 running 
> 5.1.1.
> The more VME memory I add to the system and to the sysPhysMemDesc table in
> sysLib.c the longer the boot time.
> Our system has to support over 640MB of VME memory and boot time takes around 
> 10 minutes in this configuration.

The problem is the time taken to build large MMU translation tables. I had this 
problem using both the mv147 and mv167 boards. I got round it by using the 
transparent translation registers of the CPU. The problem also existed in 5.1, 
except then the tables also seriously fragmented memory.

The reason to use the transparent translation registers directly is that you can
access large areas of memory without generating correspondingly large MMU 
translation tables (the 4 areas of 128 MBytes each that I need to cover require 
either ~300 KBytes of MMU table or a single DTT/TT register) and there is no 
translation time overhead. The disadvantage is that there are only two DTT/TT 
registers and they have limited usage.

The top 8 bits, the Logical Address Base, are compared with address bits A31-A24
(i.e. multiples of 16 Mbyte). Addresses that match are transparently translated.
The next 8 bits, the Logical Address Mask, contain a mask for the Logical 
Address Base, set bits cause the corresponding bit in the Logical Address Base 
field to be ignored. Other bits set the access modes, cache mode, etc., and are 
different for the 68030 and the 68040. You must be careful that the areas 
covered do not clash with those defined by the MMU tables.

For future referance, this is what you do :-


/**************************/
/* for 68030 (e.g. mv147) */
/**************************/

/* 2 large areas, R/W, cache disabled */
#define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */ #define 
TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */

test_tt ()
{
register int *pVal;
int ttVal;

pVal = &ttVal;

ttVal = TT0_VALUE;
asm ("pmove %0,tt0" : : "g" (*pVal)); ttVal = TT1_VALUE;
asm ("pmove %0,tt1" : : "g" (*pVal));
}

/**************************/
/* for 68040 (e.g. mv167) */
/**************************/

/* 2 large areas, R/W, cache disabled */
#define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */ #define 
TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */

test_dtt ()
{
asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); asm ("movec %0,dtt1" : : "r" 
(DTT1_VALUE));
}
        
----------------------------------------------------------------------
        
Steve Morris                        voice: (972)-8-381055 
Software Team Manager                      (972)-8-381818 
Indigo Graphic Systems              Fax:   (972)-8-408091
P.O. Box 150, Rehovot, Israel       e-mail: morriss@indigo.co.il
        
----------------------------------------------------------------------

        



From mike@imatron.com  Mon Aug 15 10:18:05 1994
From: "Mike Morrison[Software Eng]" <mike@imatron.com>
Date: Mon Aug 15 10:18:12 PDT 1994
Subject: Re: mvme167/5.1.1 -  MMU and slooooow booting
Thanks to everyone who responded... 

    Scott Ivelane <siveland@msmail3.hac.com>
    Ed Gamble <ebg@hip.atr.co.jp> 
    Steve Morris <morriss@indigo.co.il>
    Douglas Davies <ddavies@xmission.com>
    Jerry Pendleton <jerald@wrs.com> 
 
My problem is now solved.  

I believe I was quick to harshly jump on Wind River when in fact
It was I who didn't understand how things worked.  

>>I talked to WRS but didn't get anywhere.  I got the impression that
>>they really didn't want to deal with the problem (I didn't even get
>>a TSR for my trouble).

In fact I did get a TSR  (#18383).  

Im sure the folks at support@wrs.com hear only bitching and not enough
thanks. 


Thanks again everyone.

********************************************************************
*	Michael Morrison	      	mike_morrison@imatron.com  *
********************************************************************


From bordua@csg.lbl.gov  Mon Aug 15 11:27:38 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Mon Aug 15 11:27:45 PDT 1994
Subject: Re: unsubscribe
Unsubscribed.

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory



From lenny@den.mcd.mot.com  Mon Aug 15 11:36:51 1994
From: Lenny Bates <lenny@den.mcd.mot.com>
Date: Mon Aug 15 11:36:59 PDT 1994
Subject: Register
I would like to register for the VxWorks Exploder.

Lenny Bates
Motorola Inc.
8055 E. Tufts Ave. Suite 350
Denver, Co 80237
(303) 770-5900 (Voice)
(303) 770-0725 (Fax)

Hardware;
Motorola 8640
88K RISC Dual Processor

I am a Systems Engineer and frequently assist with design-ins on Motorola
single board computers in a RealTime app using VxWorks as the OS.

Thanks,

Lenny


        	My motherboard just had daughter cards!


**************************************************************************
* Lenny Bates			      | VOICE: 303-770-5900              *
* Systems Engineer 		      | FAX  : 303-770-0725              *
* Motorola Computer Group	      |  		     		 *
* 8055 E. Tufts Ave Pkwy Ste 350      | lenny_bates@den.mcd.mot.com      * 
* Denver, Colorado 80237	      | SkyTalk 800-759-8255 Pin 2625275 *
**************************************************************************


From christ@ostar.pen.tek.com  Mon Aug 15 13:51:36 1994
From: christ@ostar.pen.tek.com (Chris Tilt)
Date: Mon Aug 15 13:51:42 PDT 1994
Subject: unsubscribe
unsubscribe

Sorry for the traffic, but the -request address seems vacant.

Chris Tilt


From dstaples@milton.viasat.com  Tue Aug 16 06:15:15 1994
From: dstaples@milton.viasat.com
Date: Tue Aug 16 06:15:21 PDT 1994
Subject: control C with vxgdb -t 68k++

     
     When using vxgdb -t 68k++, the standard interrupt character (control 
     C) has no effect.  But it works fine if I use vxgdb -t 68k to invoke 
     the debugger.  I have tried adding 
     
     #define INCLUDE_VXMON_BREAK_QUERY
     
     to configAll.h but that didn't help.
     
     Any ideas?
     


From visicom!VisiCom.COM!trest@lbl.gov  Tue Aug 16 09:03:57 1994
From: Mike Trest <trest@visicom.com>
Date: Tue Aug 16 09:04:09 PDT 1994
Subject: Re: Network interface drivers
Raj:

>>I'm trying to write a network interface for VxWorks to talk over a proprietry
>>network which has a max. packet data length of 128 bytes.  

Dana:
> Actually, it is better to let IP handle this sort of fragmentation,
> since this is part of IP's purpose.  When you call ether_attach(),
> this sets the mtu (maximum transfer unit) to ETHER_MTU (= 1500 bytes).
> If you set (struct ifnet *)xx->if_mtu to a smaller size just after
> the ether_attach() call, IP will fragment to this smaller size....

Dana your suggestion is usually correct. . . In this case, however,
Raj should consider its impact on performance.

If the MTU is revised down to fit the 128 limit then, the ratio of 
headers to data would be inappropriate.  It would be the SLIP/PPP 
issue all over again.  The transport would need to be at least and 
order of magnitude faster than ENET to compensate for replicating
ENET/IP headers in every frame.

A more appropriate approach is to write the driver using the ATM 
approach.  Setup  driver to use a large MTU for better processor 
efficiency. Then driver then would fragment the IP frames to down 
to use the existing transport.  At the other end, re-assemble the 
fragments into a whole IP frame. 

Raj will have to make the same kinds of decisions as in ATM AAL 
[ATM Adaptation Layer].  In addition to data frame size, you must 
put some attention to address resolution.  Your transport addresses 
need to be mapped so the VxWorks ARP tables, netmasks, etc will work 
properly.  You may even need to keep a table of all active addresses 
on the transport so you can simulate UDP behaviour if transport
does not support broadcast.

Hopefully, the transport is reliable and delivers all frames in sequence.  
If not, then some error checking or out-of-order assembly needs to be done.  
Hopefully, the transport is faster than ENET, you will need it to overcome 
the fragmentation/re-assembly software overhead.  Hopefully, the transport 
has enough addresses for the number of units you wish to attach.

If it were my task, I would write a small protocol layer which would
manage the movement of IP frames to/from the driver.  The new protocol 
layer would deal with all of these issues.  [Funny, isn't this what
the AAL is?]

I have written enough of these kinds of things to always consider the 
exact opposite of the common wisdom.  In Raj's example, the common
wisdom is guaranteed to produce both low thruput and high CPU usage.

..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 chris@efi.com  Wed Aug 17 15:11:22 1994
From: "Chris Phoenix" <chris@efi.com>
Date: Wed Aug 17 15:11:28 PDT 1994
Subject: Multiple interrupts crash
We're using VxWorks 5.1.1 on an R4000.  When we have lots of interrupts from
several different sources, the system crashes in any of several interesting
ways.  It seems that kernel memory in .bss, such as workQHead, is getting
trashed, and then later in the interrupt handler this causes TLB misses, which
makes the system try to reboot.  The worst part is that if we change the code a
little (eg. to monitor the location that's getting trashed) the location
changes!

1) Has anyone else had a bug like this?

2) Can anyone suggest debugging techniques?  We have a logic analyzer, but with
a write-back cache that's not too helpful.

Chris Phoenix
chris@efi.com
415-286-8581




From Keith_Zhang.LAX1B@xerox.com  Wed Aug 17 18:07:21 1994
From: Keith_Zhang.LAX1B@xerox.com
Date: Wed Aug 17 18:07:28 PDT 1994
Subject: Information about WINDC++
hi everyone,

I am involved in designing an application in VxWorks o.s. for an i960 embedded
system.  I am considering about using C++ for programming, but don`t know how
reliable is the WINDC++ compiler.  I am also concerned about the efficiency
since it is a cfront not a pure C++ compiler.  If you have developed your
application using WINDC++, or know anyone had experience with it,  please share
with me any opinions, comments, or suggestions that you may have.

Please reply to me directly since I am not in the exploder user group yet (just
applied).  Many thanks!

 Following is information about me.

Name:		Keith Zhang
Company:	Xerox Corp.
Address:	101 E Continental Blvd  Mail stop: ESC1-14D
		El Segundo 	CA 90245
Tel:		310 - 333 - 3372
Fax:		310 - 333 - 6442
email:		kzhang.lax1b@xerox.com

application:	  i960 processor embedded system for high speed laser printers.

/Keith


From franks@se01.wg2.waii.com  Thu Aug 18 05:47:56 1994
From: franks@se01.wg2.waii.com (Jeffrey L. Franks)
Date: Thu Aug 18 05:48:09 PDT 1994
Subject: Re: Multiple interrupts crash
In response to your question:

 1) Has anyone else had a bug like this?

I've had a similar experience on a VME147 board which had to do with
a stack that was undersized for one task.

Everything was fine for a while. Then as the project progressed, additional
calls were made using NFS.  Things got erratic in unpredictable ways.

Many time when this happens it is due to a "loose pointer", stack corruption,
or an interrupt routine that doesn't always do the right thing (usually due
to a coding error).

If things fail in unpredicatable ways, increase the sizes of the stacks.
If the stack is violated, its already too late, unless of course you have
additional tools to sort these types of problems out.  Use the stackCheck()
feature of vxWorks to determine before system crash if stacks are dangerously
close to being compromised. 

Maybe you can determine that a particular type of call is getting you into
trouble, like an open() over an NFS connection, or something else.

Hope this helps a little

----------------
Jeff Franks                    Western Geophysical Exploration Products
                               a division of Western Atlas International Inc.
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                               Internet  :  franks@wg2.waii.com
  WESTERN                      Voice     :  (713) 964-6199
      ATLAS                    Fax       :  (713) 964-6218




From atl@adaclabs.com  Thu Aug 18 07:30:48 1994
From: atl@adaclabs.com (Anthony Le)
Date: Thu Aug 18 07:30:55 PDT 1994
Subject: Re:  Multiple interrupts crash
>> We're using VxWorks 5.1.1 on an R4000.  When we have lots of interrupts from
>> several different sources, the system crashes in any of several interesting
>> ways.

I have the system crash and reboot by itself if sometime my jumpers are not
installed correctlly on the VME backplan.
I hope this is not the case.

Anthony Le
ADAC LABS, INC.
atl@adaclabs.com



From atl@adaclabs.com  Thu Aug 18 07:52:14 1994
From: atl@adaclabs.com (Anthony Le)
Date: Thu Aug 18 07:52:21 PDT 1994
Subject: Setup the modem on the sun /dev/ttya to debug VxWorks remotely.

Dear VxPerts:

Does anyone know how to set the /etc/ttytab file and any other files
on the SUN to connect to the MODEM. I like to set the modem as dial in
so I can use my local SUN to remotely debug the VxWorks code.

Thanks.
Anthony Le
Sr. Software Engr.
ADAC LABS INC.
408-321-9699
atl@adaclabs.com



From dwampl@atl.com  Thu Aug 18 08:59:34 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Thu Aug 18 08:59:42 PDT 1994
Subject: Re: Information about WINDC++

> >From Keith_Zhang.LAX1B@xerox.com  Wed Aug 17 18:07:21 1994
> >From: Keith_Zhang.LAX1B@xerox.com
> Date: Wed Aug 17 18:07:28 PDT 1994
> Subject: Information about WINDC++
> hi everyone,
> 
> I am involved in designing an application in VxWorks o.s. for an i960 embedded
> system.  I am considering about using C++ for programming, but don`t know how
> reliable is the WINDC++ compiler.  I am also concerned about the efficiency
> since it is a cfront not a pure C++ compiler.  If you have developed your
> application using WINDC++, or know anyone had experience with it,  please share
> with me any opinions, comments, or suggestions that you may have.
> 

I've used WindC++ on the 68K.  For the most part, the compiler and libraries are
solid.  The beta version had problems with multiple inheritance (which broke the
file stream classes), in complete support in the debugger, and bugs in the 
mechanism for constructing static, global objects, but these problems are solved
now, for the most part.  Also, we decided to avoid the template mechanism, as it
seemed cumbersome, slow, not very accurate at error detection, etc.

Compilations are SLOW, due to the two-pass approach.  Also, I suspect that object
code sizes are larger than for comparable c files, but this is just conjecture.
I also don't have any data on run-time speed penalties.

Keep in mind that the underlying c compiler is still gcc, so you can use all of
its optimizations; the efficiency of the resulting code dependS a lot on the
quality of the c output from c-front, which seems "adequate".


I would suggest exercising an evaluation copy.  Try various test programs that
exercise features like the file streams library, the debugger, run-time 
construction of static, global objects (a tricky thing to configure correctly),
etc.  Keep in mind that my experience is in 68K-land.

Also, consider using ObjectCenter for debugging.  It is much nicer than vxgdb,
although it is slower starting up and does crash occasionally.  If you do initial
code check-out on your Sun or HP, it is particularly valuable.

On the whole, I think WindC++ is a viable, if imperfect, option.

dean

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|  Dean Wampler, Ph.D.                   email:  dwampl@atl.com   |
|  Advanced Technology Laboratories                               |
|  MS: 264                               office: (206) 487-7871   |
|  22100 Bothell Highway S.E.            fax:    (206) 486-5220   |
|  Bothell, WA  98041-3003                                        |
|-----------------------------------------------------------------|
|                 "I feel your pain...."  =:O]                    |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


From prb@aplexus.jhuapl.edu  Thu Aug 18 09:44:57 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Thu Aug 18 09:45:03 PDT 1994
Subject: Diab compiler

Hi,

I saw an announcement from Wind that we could now purchase
a 68k compiler for vxWorks from Diab. It suggests that
you can get improvement of up to 30% in performance.
Has anyone tried this compiler and, if so, what kind
of improvement have you realized?



+====================================================================+
|       __     ____         __     __                                |
|      /\ \   /  \ \       /\_\__ /\ \      Johns Hopkins University |
|     /  \_\ | /\ \ \     / / /\_\\ \ \     Applied Physics Lab.     |
|    / /\ | |\ \/  \ \   / / / / / \ \ \                             |
|   /  \/ |_| \  /\ \_\ / / / / /   \ \ \   Paul R. Bade             |
|  / /\__/_/   \ \ \/_// / / / /    / / /   (301)-953-6000 x8681     |
| / / /         \ \_\  \ \/ / /    / / /    prb@aplexus.jhuapl.edu   |
| \/_/           \/_/   \__/_/     \/_/                              |
|               __     ____         __       __                      |
|              /\ \   /  \ \       /\ \     /\ \                     |
|             /  \_\ | /\ \ \     /  \_\   /  \ \                    |
|            / /\ | |\ \/  \ \   / /\ |_| / /\ \ \                   |
|           /  \/ |_| \  /\ \_\ / / / | | \/ /  \ \                  |
|          / /\  / /   \ \ \/_// / / / /    / /\ \_\                 |
|          \ \/ / /     \ \_\  \ \/ / /     \/ / / /                 |
|           \__/_/       \/_/   \__/_/        /_/_/                  |
|                                                                    |
+====================================================================+


From prb@aplexus.jhuapl.edu  Thu Aug 18 09:48:21 1994
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Thu Aug 18 09:48:28 PDT 1994
Subject: Graham Heye's port of tcl7.3

Hi,

I have not been able to locate Graham Heye's port of TCL 7.3
I suppose I could use Joe Van Andel's port of TCL 7.0,
but I thought I would ask about TCL 7.3 one more time.

	Thanks,



+====================================================================+
|       __     ____         __     __                                |
|      /\ \   /  \ \       /\_\__ /\ \      Johns Hopkins University |
|     /  \_\ | /\ \ \     / / /\_\\ \ \     Applied Physics Lab.     |
|    / /\ | |\ \/  \ \   / / / / / \ \ \                             |
|   /  \/ |_| \  /\ \_\ / / / / /   \ \ \   Paul R. Bade             |
|  / /\__/_/   \ \ \/_// / / / /    / / /   (301)-953-6000 x8681     |
| / / /         \ \_\  \ \/ / /    / / /    prb@aplexus.jhuapl.edu   |
| \/_/           \/_/   \__/_/     \/_/                              |
|               __     ____         __       __                      |
|              /\ \   /  \ \       /\ \     /\ \                     |
|             /  \_\ | /\ \ \     /  \_\   /  \ \                    |
|            / /\ | |\ \/  \ \   / /\ |_| / /\ \ \                   |
|           /  \/ |_| \  /\ \_\ / / / | | \/ /  \ \                  |
|          / /\  / /   \ \ \/_// / / / /    / /\ \_\                 |
|          \ \/ / /     \ \_\  \ \/ / /     \/ / / /                 |
|           \__/_/       \/_/   \__/_/        /_/_/                  |
|                                                                    |
+====================================================================+


From chris@efi.com  Thu Aug 18 10:50:34 1994
From: "Chris Phoenix" <chris@efi.com>
Date: Thu Aug 18 10:50:41 PDT 1994
Subject: Re: Multiple interrupts crash
Thanks for your reply.  I don't think it's the stack this time--we're running
the task with a 200K stack!




From mitchell@harpo.aaec.com  Thu Aug 18 13:25:05 1994
From: mitchell@harpo.aaec.com
Date: Thu Aug 18 13:25:12 PDT 1994
Subject: Re: Multiple interrupts crash
>Submitted-by chris@efi.com  Thu Aug 18 10:50:34 1994
>Submitted-by: "Chris Phoenix" <chris@efi.com>
>
>Thanks for your reply.  I don't think it's the stack this time--we're running
>the task with a 200K stack!
>
>
What about other task's stacks?  They can "grow" past their end and into
your stack or data or program space.

The workQ holds interrupt processing requests, so it looks like your PCU is
being overlaoded with interrupts.  Usually this is because the interrupter
is not removing its interrupt request, (ie. broken VME daisy chain on IACK
or ISR not clearing bits as required).  There could be other vagaries in
the H/W or interrupt handling S/W that lead to this effect.  Try turning
off the interrupt sources until the problem goes away.

  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
  Time Price Quality  ... pick any two






From mea@mclean.sparta.com  Fri Aug 19 06:16:34 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Aug 19 06:16:42 PDT 1994
Subject: Status of FAQ via FTP
Greetings!

  The VxWorks FAQ has been available via anonymous FTP to 157.185.32.10
(teacher.mclean.sparta.com) for a little over a week and a half now and
many folks have successfully downloaded copies.  However, there have
been a few problems that folks have encountered related to the "dir"
command.  For some reason, the "dir" command doesn't work with our FTP
server (we're looking into it). The symptom is that when you issue a
"dir", nothing comes back.  Until we can fix that problem, use "ls"
instead.  "ls" seems to work just fine.  If your FTP implementation doen't
have "ls", simply e-mail me a request and I'll mail you back copies of
the FAQ.  BTW, I have the FAQ both compressed and uncompressed in the directory
that you're dropped into when loggin in as anonymous.  The uncompressed 
copy is split into 2 parts to facilitate e-mail (many mailers choke if
you send them more than 50K in a message and the FAQ was up to 80+ K).

The current contents of the directory are:

vxfaq-pt1       /* part 1 of the FAQ - uncompressed */
vxfaq-pt2       /* part 2 of the FAQ - uncompressed */
vxdrivers       /* vxWorks device drivers list - uncompressed */
vxbsp           /* list of VxWorks BSPs - uncompressed */
vxworkers       /* vxWorks consultant list - uncompressed */
vxfaq.gz        /* gnu compressed FAQ */
vxbsp.gz        /* gnu compressed BSP listing */
vxdrivers.gz    /* gnu compressed device driver list */
vxworkers.gz    /* gnu compressed consultant list */
ppp-1.3.tar.gz  /* async PPP implementation for VxWorks - gnu compressed */
archives        /* directory for the User's Group Archive stuff */

Thanks for your patience,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

    


From lerible@raptor.sandia.gov  Fri Aug 19 11:52:18 1994
From: lerible@raptor.sandia.gov (Loren E. Riblett)
Date: Fri Aug 19 11:52:25 PDT 1994
Subject: vxWorks vi
Hello:

Can anyone tell me of a vxWorks vi utility?  I thought there was reference to
one in the FAQ list but can't seem to find it.

Thanks.

Loren

      _/_/_/_/   _/      _/   _/         Loren E. Riblett
     _/         _/_/    _/   _/         Email:  lerible@sandia.gov
    _/_/_/_/   _/  _/  _/   _/         (505) 845-8841  FAX  844-4157
         _/   _/    _/_/   _/         Senior Member of the Technical Staff
  _/_/_/_/   _/      _/   _/_/_/_/   Image & Signal Processing Department 9137
    Sandia National Laboratories   Albuquerque, NM 87185     


From mea@mclean.sparta.com  Fri Aug 19 12:43:34 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Aug 19 12:43:41 PDT 1994
Subject: Re: vxWorks vi
Greetings!

  The VxWorks version of vi is called stevie and can be found either at
the User's Group Archives at thor.atd.ucar.edu or at my FTP server at
teacher.mclean.sparta.com.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      


From mkrokosz@astro.ge.com  Tue Aug 23 06:54:04 1994
From: Matthew Krokosz <mkrokosz@astro.ge.com>
Date: Tue Aug 23 06:54:10 PDT 1994
Subject: Memory Alignment

I am encountering some intermittent problems with an application being
developed under Vxworks.  I suspect it may be the result of mis-aligned
memory.  We are using the gnu compiler.  

Would something like this be correct in terms of alignment?

void	myFunction(void)
{
   int      x;
   char     a;
   char*    pAddr;

   ...

}

My guess is that pAddr would not be aligned because the char before it
causes it not to be aligned on a half-word boundary.  Or would the 
compiler pad it?


*************************************************************************
|  Matthew Krokosz			email: mkrokosz@astro.ge.com	|
|  Martin Marietta Astro Space		phone: (609) 490-7194		|  	
|  Princeton, NJ							|
|     									|
*************************************************************************


From mitchell@harpo.aaec.com  Tue Aug 23 08:32:11 1994
From: mitchell@harpo.aaec.com
Date: Tue Aug 23 08:32:18 PDT 1994
Subject: Re: Memory Alignment
>I am encountering some intermittent problems with an application being
>developed under Vxworks.  I suspect it may be the result of mis-aligned
>memory.  We are using the gnu compiler.
>
>Would something like this be correct in terms of alignment?
>
>void    myFunction(void)
>{
>   int      x;
>   char     a;
>   char*    pAddr;
>
>   ...
>
>}
>
>My guess is that pAddr would not be aligned because the char before it
>causes it not to be aligned on a half-word boundary.  Or would the
>compiler pad it?
>

Assumptions about structure alignment are bound to cause problems, but are
hard to avoid sometimes.  In general atomic types are aligned on their
sized boundries (shorts will be aligned to 16 bits etc.) up to the "native"
size of the CPU data path, but this depends on the compiler, cpu, and
compiler flags.  I got burned when passing a double from a 680x0 to a sparc
because it was padded to a 64 bit boundry on the sparc but not the 680x0.
I was also burned way back with vxWorks 4.0.2 (possibly using Sun's cc on a
sun-3) when a shared memory structure had an odd sized character array in
it.  All accesses to longs after the array required multiple VME cycles to
avoid unaligned transfers, which turned out to be a substanial performance
hit.

I suggest digging up the gcc manual and checking on the alignment flags,
then checking the intermediate assembly code listings to be sure.  Its best
to arrange your strucure and add unused characters (or shorts) to force all
elements to be aligned for improved performance rather than having the
compiler do the padding.  If you rely on the compiler, be sure to comment
heavily.

  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
  Time Price Quality  ... pick any two






From mitchell@harpo.aaec.com  Tue Aug 23 08:43:05 1994
From: mitchell@harpo.aaec.com
Date: Tue Aug 23 08:43:13 PDT 1994
Subject: Re: Memory Alignment (whoops)
Maybe I better get my eyes checked!  That's a function, not a structure!

>void    myFunction(void)
>{
>   int      x;
>   char     a;
>   char*    pAddr;
>
>   ...
>
>}
>
>My guess is that pAddr would not be aligned because the char before it
>causes it not to be aligned on a half-word boundary.  Or would the
>compiler pad it?
>

Unless you to an explicit address of (&) operator, there is no reason to
think that the variable will ever be put in memory. With gcc optimization
(there is NEVER a good reason to turn it off unless you're vxGdb'ing and
you can't follow some flow optimizations), the compiler will figure out
which variables should be used as "register" types and optimize
accordingly.  If you care about how the locals are stored in the frame
pointer, then you are doing something wrong (ethically if nothing else).
Maybe what you want to do is have a local structure holding the data you
want to access as a group, and reference the structure with the "address
of" operator.  Then the variables will be stored in a consistent way (see
my last posting) somewhere in the stack frame.

  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
  Time Price Quality  ... pick any two






From william.mallet@srs.gov  Tue Aug 23 08:48:24 1994
From: "WILLIAM R. MALLET" <william.mallet@srs.gov>
Date: Tue Aug 23 08:48:33 PDT 1994
Subject: vxWorks Exploder registration
Please add me to the vxWorks Exploder

Bill Mallet
william.mallet@srs.gov
Westinghouse Savannah River Company
Bldg 773-A, Rm D1108
(803) 725-1481
(803) 725-7369 (FAX)
Application: Robot controllers




From franks@se01.wg2.waii.com  Tue Aug 23 13:13:11 1994
From: franks@se01.wg2.waii.com (Jeffrey L. Franks)
Date: Tue Aug 23 13:13:18 PDT 1994
Subject: Re: Memory Alignment
Structs are not considered portable between machine types, i.e.: don't assume
that they are packed on same boundaries.

The compiler takes care of this for you.  If you try to "bend" the rules,
you might be able to generate hardware exceptions.  Bending the rules means
attempting to use a char pointer for word accesses that are condsidered by
the hardware to be non-aligned.

Some compilers will allow non-standard keywords to allow you to specify a
packed struct, but this will not be portable.

RISC machines have been famous for finding non-portable code that violates
these rules.

----------------
Jeff Franks                    Western Geophysical Exploration Products
                               a division of Western Atlas International Inc.
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                               Internet  :  franks@wg2.waii.com
  WESTERN                      Voice     :  (713) 964-6199
      ATLAS                    Fax       :  (713) 964-6218



From mike@imatron.com  Tue Aug 23 15:53:17 1994
From: "Mike Morrison[Software Eng]" <mike@imatron.com>
Date: Tue Aug 23 15:53:25 PDT 1994
Subject: Motorola/vxworks boot roms
There was a thread not long ago discussing how to
set up the the MVME167 to have both Motorola and
vxworks proms installed. I guess this set up
will allow one to boot vxworks and still have the
motorola diagnostics/debug available.
If anyone kept this info could you please forward?  

Thanks


mike_morrison@imatron.com


From cpd@one.one.com  Tue Aug 23 20:38:05 1994
From: cpd@one.com (Chris P. Domin)
Date: Tue Aug 23 20:38:12 PDT 1994
Subject: Re: Memory Alignment
[Jeff Franks Wrote]
> Structs are not considered portable between machine types, i.e.: don't assume
> that they are packed on same boundaries.
> 
> The compiler takes care of this for you.  If you try to "bend" the rules,
> you might be able to generate hardware exceptions.  Bending the rules means
> attempting to use a char pointer for word accesses that are condsidered by
> the hardware to be non-aligned.
> 
> Some compilers will allow non-standard keywords to allow you to specify a
> packed struct, but this will not be portable.
> 
> RISC machines have been famous for finding non-portable code that violates
> these rules.
> 
One way to make sure that all the structures are aligned is to make sure
each element resides on a dword boundary (a 32 bit boundary), e.g.,

typedef struct
{
   char c;
   short s;
   long l;
}UNALIGNED_EXAMPLE;

could be made 'portable' by using bit fields:

typedef struct
{
   char c;
   int :24; /* padding */
   short s;
   int :16; /* padding */
   long l;
}ALIGNED_EXAMPLE;

Those structures which are NOT passed from CPU board to CPU board should be
a non-issue, unless objects are being linked which have been built using
different compilers.  If the same compiler is being used (with the same
compile options for the same target), alignment is pretty much assured.

Also, on a side note, some RISC processors treat structures differently
than integers,  that is, if sizeof(yourstruct)==sizeof(int), you still may
get exceptions:  The Motorola 88K processors are optimized to treat structures
differently than integers.

Regards,

Chris Domin


================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================
Open Networks Engineering (ONE)         Fax:       (313) 996-9908  
777 Eisenhower Pkwy, Suite 650          Voice:     (313) 996-9900 ext. (1) 232
Ann Arbor, Michigan 48108               Internet:  cpd@one.com
================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================


From stan@lassen.rti.com  Tue Aug 23 23:21:09 1994
From: stan@lassen.rti.com (Stan Schneider)
Date: Tue Aug 23 23:21:16 PDT 1994
Subject: Re: Memory Alignment
>> Submitted-by cpd@one.one.com  Tue Aug 23 20:38:05 1994

>> > Structs are not considered portable between machine types, i.e.: don't
>> > assume that they are packed on same boundaries.
>> > 

>> < ...>

>> could be made 'portable' by using bit fields:
>> 
>> typedef struct
>> {
>>    char c;
>>    int :24; /* padding */
>>    short s;
>>    int :16; /* padding */
>>    long l;
>> }ALIGNED_EXAMPLE;
>> 

My $0.02:

This is already a mess even for this trivial example.  What about complex
structures?  What if a "short" isn't 16 bits?  What about nested structures?
What about simple changes for maintenance?  What about byte order?

This is why things like xdr were invented.  There's no clean way to send
structures between architectures without serialization of some sort.  It just
doesn't pay to try to make the two memory images exactly match.

        -- 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 vdbent@rulrol.leidenuniv.nl  Wed Aug 24 05:23:09 1994
From: vdbent@rulrol.leidenuniv.nl (Kees van der Bent)
Date: Wed Aug 24 05:23:15 PDT 1994
Subject: Re: Memory Alignment
Hi there,

> I am encountering some intermittent problems with an application being
> developed under Vxworks.  I suspect it may be the result of mis-aligned
> memory.  We are using the gnu compiler.
>
> Would something like this be correct in terms of alignment?
>
> void    myFunction(void)
> {
>    int      x;
>    char     a;
>    char*    pAddr;
>
>    ...
>
> }
>
> My guess is that pAddr would not be aligned because the char before it
> causes it not to be aligned on a half-word boundary.  Or would the
> compiler pad it?

As was said earlier, there nothing wrong with this code.  I think you're 
looking in the wrong direction if you're talking about *intermittent*
problems.

I'd rather look for stack/heap overflows, dangling pointers or things like
that.

Good luck!

 |   ### ## | ####   ###  ## #  |	       Kees van der Bent
 | #### ### | ## ## # ### ##### |   Space Research Organisation Netherlands
 | ####  ## | ####  ## ## ## ## |	 P.O. Box 9504  2300 RA Leiden
 |   ####   | ## ##  ###  ## ## |		The Netherlands
 | ##  #### |			|
 | ### #### |			|		 +31-71-275805
 | ## ###   |			|	  vdbent@rulrol.LeidenUniv.nl




From cpd@one.one.com  Wed Aug 24 07:53:38 1994
From: cpd@one.com (Chris P. Domin)
Date: Wed Aug 24 07:53:45 PDT 1994
Subject: Re: Memory Alignment(last reprise)
> 
> Submitted-by stan@lassen.rti.com  Tue Aug 23 23:21:09 1994
> 
> My $0.02:
> 
> This is already a mess even for this trivial example.  What about complex
> structures?  What if a "short" isn't 16 bits?  What about nested structures?
> What about simple changes for maintenance?  What about byte order?
> 
> This is why things like xdr were invented.  There's no clean way to send
> structures between architectures without serialization of some sort.  It just
> doesn't pay to try to make the two memory images exactly match.
> 

Of course you are correct in stating that not using a common transfer
syntax does have limitations.  The alternative is to use something like
xdr to translate from a machine representation to a common syntax.

But gee, xdr (and the like) performs data copies, which does require more cpu 
processing than having aligned structures. This may not be acceptable for 
some applications (multiprocessor systems sharing a bus).  (I am not knocking 
xdr: You have to have a common transfer syntax for big-endian machines to 
communicate with little-endian machines).  

SO, if you need every ounce of performance your CPU can offer, and 
if you know the architectures of your machines which will communicate with
each other, and the machines are the same endian, and you know what the
elementary data types look like for your compiler, you CAN define portable 
structures (my company does so with SPARC, 68K, 88K  processors). 

Regards,

Chris Domin


================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================
Open Networks Engineering (ONE)         Fax:       (313) 996-9908  
777 Eisenhower Pkwy, Suite 650          Voice:     (313) 996-9900 ext. (1) 232
Ann Arbor, Michigan 48108               Internet:  cpd@one.com
================-=-=-=--=--=---=-----=-----=---=--=--=-=-=-=-=================


From buchanan@argus.lowell.edu  Wed Aug 24 08:02:07 1994
From: Thomas Keith Buchanan <buchanan@argus.lowell.edu>
Date: Wed Aug 24 08:02:14 PDT 1994
Subject: Re: Memory Alignment
> This is already a mess even for this trivial example.  What about complex
> structures?  What if a "short" isn't 16 bits?  What about nested 
> structures?
> What about simple changes for maintenance?  What about byte order?

> This is why things like xdr were invented.  There's no clean way to send
> structures between architectures without serialization of some sort.  It 
> just doesn't pay to try to make the two memory images exactly match.

>         -- Stan

Stan is absolutely right!!  Stay away from bit fields, packed structures 
and all the other advice you have gotten.  If you are concerned about 
optimal code and hardware memory alignment problems, just use some common 
sense.  Put the ints, floats & pointers first in a structure and/or pad the 
16-bit and 8-bit members.

typedef struct BIG_GUYS_FIRST
{
	int iA;
	float fB;
	double dfC;
	unsigned short uD;
	char sE;
}

typedef struct PAD_LITTLE_GUYS
{
	char sA;
	char sSpare1[3];
	int iB;
	unsigned short uC;
	char sSpare2[2];
	float fC;
}

Simple habits will make your code a little faster, especially on 68k 
machines.  If you have to pass structures between machines, there are 
bigger fish to fry.  I recommend something like xdr for big jobs but if 
you are careful, you can do it using the simple habits above.  The 
structures above would look the same to a SPARC, though you should pad 
the end of the first structure.  Floating point formats in that case are all 
IEEE stamdards and the byte order is the same.  I am currently 
integrating a system with around 1000 structure-oriented messages passing 
between SPARCs & 68ks with no problems.  If you are writing something 
with possible universal application, heed Stan's advice.  Even in that 
case, good alignment habits can't hurt.

--------------------------------------------------------------
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 tsb@mclean.sparta.com  Wed Aug 24 08:43:14 1994
From: tsb@mclean.sparta.com (Todd S. Brackett)
Date: Wed Aug 24 08:43:22 PDT 1994
Subject: Broken Exploder

Hi folks!

I asked about this a few weeks ago and didn't get much of a response.
I have checked with a couple of users and the newsgroup to exploder
connection is DEFINITELY broken.  No one on the exploder side has seen
a newsgroup message since August 2.  (It seems to me that was around the same
time as that "bounce back" problem was annoying us all.) Since my original
post didn't result in a correction I am sending this out again.  If you have
an "in" with the folks at LBL let them know you want your newsgroup feed back.
:)

Regards,

-----------------------------------------------------------
|Todd S. Brackett         |  Voice -> 703 448 1683 x249   |
|tsb@mclean.sparta.com    |  FAX   -> 703 734 3323        |
|_________________________________________________________|
|                                                         |
|     /\\     SPARTA, Inc.                                |
|    ///\\    7926 Jones Branch Drive                     |
|   /////\\   Suite 900                                   |
|  /////  \\  McLean, VA 22102                            |
| / \\\\\  \\                     "Life is like baseball, |
| \  \\\\\ //                      some days you win,     |
|  \  //////                       some days you lose,    | 
|   \//////  SPARTA                some days it rains..." |
|    \////   Pride In Performance                         |
|     \//                                                 |
___________________________________________________________





From mitchell@harpo.aaec.com  Wed Aug 24 09:19:28 1994
From: mitchell@harpo.aaec.com
Date: Wed Aug 24 09:19:36 PDT 1994
Subject: Re: Memory Alignment (again)
>> This is why things like xdr were invented.  There's no clean way to send
>> structures between architectures without serialization of some sort.  It
>> just doesn't pay to try to make the two memory images exactly match.
>
>>         -- Stan

I'll keep that in mind while a pass .5Mbyte/sec from 68K to Sparc :-)

>
>Stan is absolutely right!!  Stay away from bit fields, packed structures
>and all the other advice you have gotten.  If you are concerned about
>optimal code and hardware memory alignment problems, just use some common
>sense.  Put the ints, floats & pointers first in a structure and/or pad the
>16-bit and 8-bit members.
>
>typedef struct BIG_GUYS_FIRST
>{
>        int iA;
>        float fB;
>        double dfC;
>        unsigned short uD;
>        char sE;
>}
>

I agree, but you'll want the doubles first, SPARC gcc pads doubles to 64
bit boundries, 68K doesn't.  Maybe ALPHA and i860 might pad double to 64
too.  The above struct would work only because of the even number of 32 bit
fields before the double.

  Andrew Mitchell                |  Internet: mitchell@aaec.com
  Atlantic Aerospace             |  tel: (617) 890-4200
  470 Totten Pond Road           |  fax: (617) 890-0224
  Waltham MA 02154 USA           |
  Time Price Quality  ... pick any two






From blair@wyeth.ds.boeing.com  Wed Aug 24 10:30:56 1994
From: blair@wyeth.ds.boeing.com (rick blair)
Date: Wed Aug 24 10:31:03 PDT 1994
Subject: Allen Bradley Data Highway

Fellow Vxers,

I am working on a project that requires communication between an
Allen-Bradley PLC-5 and a VME rack via Data Highway.  The processors in 
the VME rack run VxWorks (of course).  

Anyone know of a VME Data Highway interface card with VxWorks support?


Any opinions, words of wisdom, etc would be more than welcome.

Thanks in advance

Rick Blair


***************************************************
* email:     blair@elvis.ds.boeing.com            *
* voice:     (206)657-6582                        *
* usSnail:   P.O. Box 3707 M/S 9F-61              *
*            Seattle, Wa 98124                    *
*                                                 *
*Disclaimer: The contents of this message in no   *
*            way reflects the Opinions either real*
*            or imaginary of the Boeing Company.  *
*            All Opinions/rantings are my own and * 
*            only I am responsible for them.      *
***************************************************



From bordua@csg.lbl.gov  Wed Aug 24 12:20:17 1994
From: bordua@csg.lbl.gov (Michael Bordua)
Date: Wed Aug 24 12:20:24 PDT 1994
Subject: Re: Broken Exploder
Todd,

I'm sending this to you and the exploder.

I just checked the vxworks newsgroup and saw articles posted as late as 
1030 PDT Today.  I would suggest that you check your systems newsfeed as it my
be the problem.  I had 114 unread articles in the newsgroup that ranged as far
back as Aug 6.  (This was the last time I checked it).  I don't normally read
the newsgroup unless there is a problem.  I hope this helps.  If there are any
other users out there that are seeing this same problem please let me know at
my E-Mail address and I'll have my netnews guy check it out.

Thanks,

    Mike Bordua
    MGBordua@lbl.gov
    VxWorks Exploder Administrator
    Computer Systems Group
    Lawrence Berkeley Laboratory

>From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
>Subject: Broken Exploder
>Content-Length: 1830
>
>Submitted-by tsb@mclean.sparta.com  Wed Aug 24 08:43:14 1994
>Submitted-by: tsb@mclean.sparta.com (Todd S. Brackett)
> 
>
>Hi folks!
>
>I asked about this a few weeks ago and didn't get much of a response.
>I have checked with a couple of users and the newsgroup to exploder
>connection is DEFINITELY broken.  No one on the exploder side has seen
>a newsgroup message since August 2.  (It seems to me that was around the same
>time as that "bounce back" problem was annoying us all.) Since my original
>post didn't result in a correction I am sending this out again.  If you have
>an "in" with the folks at LBL let them know you want your newsgroup feed back.
>:)
>
>Regards,
>
>-----------------------------------------------------------
>|Todd S. Brackett         |  Voice -> 703 448 1683 x249   |
>|tsb@mclean.sparta.com    |  FAX   -> 703 734 3323        |
>___________________________________________________________


From stan@lassen.rti.com  Wed Aug 24 12:47:13 1994
From: stan@lassen.rti.com (Stan Schneider)
Date: Wed Aug 24 12:47:20 PDT 1994
Subject: Re: Memory Alignment (again)

>> This is why things like xdr were invented.  There's no clean way to send...
                                                          ^^^^^
>> 
>> I'll keep that in mind while a pass .5Mbyte/sec from 68K to Sparc :-)
>> 
No-one said that was a constraint.  We all do things for efficiency that aren't
"clean" sometimes.  Still, self-padding is something that should be
really-well-commented (one of my favorite euphemisms) in "portable" code.

On the other hand, I think I may have addressed the wrong question.  The
original poster said:

> Submitted-by mkrokosz@astro.ge.com  Tue Aug 23 06:54:04 1994
>
> I am encountering some intermittent problems with an application being
> developed under Vxworks.  I suspect it may be the result of mis-aligned
> memory.  We are using the gnu compiler.
>
> Would something like this be correct in terms of alignment?
>
> void    myFunction(void)
> {
>    int      x;
>    char     a;
>    char*    pAddr;
>
>    ...
>
> }
>
> My guess is that pAddr would not be aligned because the char before it
> causes it not to be aligned on a half-word boundary.  Or would the
> compiler pad it?

Were it not for the "intermittent" claim, I'd bet my $0.02 that myFunction()
contains a cast of pAddr to/from some other type later in this code.  That's
asking for alignment errors.  On the other hand, I wouldn't expect this to be
an intermittent problem...  (I suppose it could be load-dependent).

Kees van der Bent suggested a stack or heap error; that's certainly a
possibility.  Heap errors can cause almost anything to happen.  That's why we
wrote HeapCheck.


        -- 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 tsb@mclean.sparta.com  Wed Aug 24 13:12:12 1994
From: tsb@mclean.sparta.com (Todd S. Brackett)
Date: Wed Aug 24 13:12:19 PDT 1994
Subject: Re: Broken Exploder
> Submitted-by: bordua@csg.lbl.gov (Michael Bordua)
>  
> Todd,
> 
> I'm sending this to you and the exploder.
> 
> I just checked the vxworks newsgroup and saw articles posted as late as 
> 1030 PDT Today.  I would suggest that you check your systems newsfeed as it my
> be the problem.  I had 114 unread articles in the newsgroup that ranged as far
> back as Aug 6.  (This was the last time I checked it).  I don't normally read
> the newsgroup unless there is a problem.  I hope this helps.  If there are any
> other users out there that are seeing this same problem please let me know at
> my E-Mail address and I'll have my netnews guy check it out.
> 
> Thanks,
> 
>     Mike Bordua
>     MGBordua@lbl.gov
>     VxWorks Exploder Administrator
>     Computer Systems Group
>     Lawrence Berkeley Laboratory
> 

Sorry Mike but I think you missed the point.  When the newsgroup was created 
there was a "daemon" set up to copy the newsgroup output, on a daily basis, and 
cross-feed it to the exploder and vice-versa. This was done for the poor souls 
who only have mail and no newsfeed. (Self included).  This way the entire community 
sees the messages of both exploder and newsgroup.  This has been working fine for 
years and stopped working at the beginning of August.  This means that hundreds of 
messages have been lost on either side.  Please fix this ASAP.  I think Alan Biocca
set this up originally.  Thanks......

Regards,

-----------------------------------------------------------
|Todd S. Brackett         |  Voice -> 703 448 1683 x249   |
|tsb@mclean.sparta.com    |  FAX   -> 703 734 3323        |
|_________________________________________________________|
|                                                         |
|     /\\     SPARTA, Inc.                                |
|    ///\\    7926 Jones Branch Drive                     |
|   /////\\   Suite 900                                   |
|  /////  \\  McLean, VA 22102                            |
| / \\\\\  \\                     "Life is like baseball, |
| \  \\\\\ //                      some days you win,     |
|  \  //////                       some days you lose,    | 
|   \//////  SPARTA                some days it rains..." |
|    \////   Pride In Performance                         |
|     \//                                                 |
___________________________________________________________


From guthrie@power.amasd.anatcp.rockwell.com  Wed Aug 24 14:44:41 1994
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Wed Aug 24 14:44:47 PDT 1994
Subject: VxWorks newsgroup
Mike Bordua:

I have stopped getting the newsdigest also. I used to get something
like the following:

> From root@vxw.ee.lbl.gov Tue Jun 14 05:33:42 1994
> Return-Path: <root@vxw.ee.lbl.gov>
> Received: from vxw.ee.lbl.gov by power.amasd.anatcp.rockwell.com (4.1/SMI-4.1)
>       id AA26237; Tue, 14 Jun 94 05:33:19 PDT
> Errors-To: vxwexplo-errs@lbl.gov
> Received: by vxw.ee.lbl.gov (4.1/s2.2)
>       id AA05433; Tue, 14 Jun 94 04:00:40 PDT
> Date: Tue, 14 Jun 94 04:00:40 PDT
> Message-Id: <9406141100.AA05433@vxw.ee.lbl.gov>
> Errors-To: vxwexplo-errs@lbl.gov
> To: vxworks_users@vxw.ee.lbl.gov
> From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
> Subject: comp.os.vxworks newsdigest
> Status: R

> Submitted-by daemon@vxw.ee.lbl.gov  Tue Jun 14 04:00:24 1994
> Submitted-by: daemon@vxw.ee.lbl.gov
 
> Comp.Os.Vxworks Daily Digest    Tue Jun 14 04:00:14 PDT 1994

>       Subject: Test coverage tool?
>       Subject: malloc problem

This mail message came from "vxwexplo@lbl.gov" just like all of the 
VxWorks exploder stuff. It looked just like another exploder message.
Our site had a newsfeed, but I was not hooked up to it. We have since
lost that newsfeed, so I can't get the information that way.

	Robert Guthrie


From daemon@vxw.ee.lbl.gov  Thu Aug 25 04:00:43 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Aug 25 04:00:54 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Aug 25 04:00:31 PDT 1994

        Subject: Re: Motorola/vxworks boot roms
        Subject: Re: Self host kernel, NFS automount
        Subject: Re: Self host kernel, NFS automount
        Subject: re: Memory Alignment
        Subject: mbufs
        Subject: Re: Self host kernel, NFS automount
        Subject: Symbol Table Lookup <Q>
        Subject: Re: Excluding Network services
        Subject: VxWorks driver for Fore ATM board
        Subject: Re: Memory Alignment

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

Newsgroups: comp.os.vxworks
Subject: Re: Motorola/vxworks boot roms
Date: 24 Aug 1994 14:05:39 GMT
From: minyard@crchh7b9 (Corey Minyard)
Organization: Bell-Northern Research, Richardson, TX
Message-ID: <33fk3j$sda@crchh327.bnr.ca>
References: <9408232253.AA28157@imatron.com>
Reply-To: minyard@bnr.ca

Mike Morrison[Software Eng] (mike@imatron.com) wrote:
: There was a thread not long ago discussing how to
: set up the the MVME167 to have both Motorola and
: vxworks proms installed. I guess this set up
: will allow one to boot vxworks and still have the
: motorola diagnostics/debug available.
: If anyone kept this info could you please forward?  

: Thanks

: mike_morrison@imatron.com

I have MVME167s booting from the net using only the Motorola boot
PROMs.  I hate making PROMs (especially the huge number I would have
had to make if I didn't get this working).  I have also booted from
disk and tape.  There are some bugs in the BSP for the 167 that I had
to work on to make it boot this way, but they have been reported to
Wind River and hopefully they will be fixed in the next release.

Theoretically, you would have to make the same fixes to boot vxWorks
in secondary PROMs.  After that, its just a matter of making a binary
image (aoutToBin <load >raw_load), putting it in a PROM, and setting
up the board to boot from PROM.  Of course, it may be more difficult,
I've never done it.  Like I said, I hate making PROMs.

Corey
minyard@bnr.ca

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

Newsgroups: comp.os.vxworks
Subject: Re: Self host kernel, NFS automount
Date: 24 Aug 1994 14:16:56 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.94Aug24101656@oats.frc.ri.cmu.edu>
References: <1994Aug23.211252.16389@news.dfrf.nasa.gov>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

In article <1994Aug23.211252.16389@news.dfrf.nasa.gov> binkley@xavier.dfrf.nasa.gov (Rob -Not from Bloom County- Binkley, EIT) writes:

>I am trying to build a set of vxWorks 5.1.1 PROMs that
>will self host the vxWorks kernel (w/symbol table) without
>FTPing from a UNIX host.  BUT...I still need the CPU to
>initialize the network software, automount any/all exported
>NFS disks from the UNIX host that is configured in the
>NVRAM and execute a startup script.

>Is this a do-able configuration?

If your CPU board supports large enough PROMs, you can configure just
about anything if you're willing to hack on the config files a little.
I built a system recently that, depending on a front panel switch
setting, either ran the standard boot monitor or jumped directly into
VxWorks and then my application. 

In particular, usrConfig.c and configAll.h probably contain most of
what you'll need. Also, look in src/config/usr*.c for specific
subsystem configuration. I believe if you just define STANDALONE_NET,
you'll get the network initialization. If INCLUDE_STARTUP_SCRIPT is
defined, you'll get that, too - but be careful to check that things
are not being #undefined "behind your back" by the standard config
code (e.g. in usrDepend.c).

So at some point you get it all to compile into the compressed ROM
image, go find the chips, discover they're not blank and wait while
they're being erased; then you burn them, plug them in and nothing
happens. As Homer Simpson would say: D'oh! Now what?
Well, one thing I've found helpful is to suspend the compilation
process before the compression step - the whole linked and
uncompressed system is then in a file called tmp.1 (or was it tmp.2?),
and you can at least run nm on it to check for specific symbols and
addresses. If that doesn't shine any light on it, here's another
trick: Modify the Makefile to leave the whole thing relocatable but
internally all linked together, i.e. no unresolved symbols. You can
then download that module to your standard-configured running target
and poke around. Of course, things will probably go haywire if you try
to run it all the way from the top (sysInit()), but judicious use of
VxGDB and the shell disassembler can be quite helpful there.

Good luck,

- -Henning
- --
Henning Pangels           |hmp@cs.cmu.edu        |     Field Robotics Center
Senior Research Programmer|(412) 268-7088        |Carnegie-Mellon University
- ------------------------------------------------------------------------------
		    Do you really know what time it is?

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

Newsgroups: comp.os.vxworks
Subject: Re: Self host kernel, NFS automount
Date: 24 Aug 1994 14:50:47 GMT
From: dat85715@indirect.com (D'Anne Thompson)
Organization: Internet Direct, Inc.
Message-ID: <33fmo8$4db@herald.indirect.com>
References: <1994Aug23.211252.16389@news.dfrf.nasa.gov>
Sender: dat85715@id1.indirect.com

Rob,

  You didn't mention how you plan to 'self-host' the vxWorks image and
symbol
table.  However, what is possible and very practical is to add a static
ram
board into the VME crate.  You can then create a ram disk with a file
system
and boot from that.  Vxworks, vxWorks.sym, and startup.cmd would be on
the
ram disk.  You would build a new set of boot roms with the ram disk
driver
included and the NVRAM parameters would direct the boot program to the
ram
disk.  The file 'startup.cmd' on the ramdisk would call 'usrNetInit'
and
specify the network parameters you wanted for the crate.

  It's not precisely what you wanted, but it works very well.  The boot
roms
are easily modified for this and will still boot over the ethernet
should
you need it.  There's no problem putting new VxWorks images onto the
ram disk
since you can just "copy <net.file >ram.disk.file".  Modifying the
startup.cmd file is just as easy.  Just copy it to your host, modify it
with
your favorite editor, and then copy it back to ramdisk.


D'Anne Thompson
Synergy Miscrosystems, Inc.
dee@ioinc.tucson.az.us
dee@synergy.encinitas.ca.us

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

Newsgroups: comp.os.vxworks
Subject: re: Memory Alignment
Date: 24 Aug 1994 15:10:15 GMT
From: singer@osfrt.mro1.dec.com (Matt Singer)
Organization: Digital Equipment Corporation
Message-ID: <33fnsn$jrl@mrnews.mro.dec.com>
References: <m0qd8fD-0001r5C@one.one.com>
Reply-To: singer@osfrt.mro1.dec.com (Matt Singer)


In article <m0qd8fD-0001r5C@one.one.com>, cpd@one.com (Chris P. Domin) writes:

|>One way to make sure that all the structures are aligned is to make sure
|>each element resides on a dword boundary (a 32 bit boundary), e.g.,
|>
|>typedef struct
|>{
|>   char c;
|>   short s;
|>   long l;
|>}UNALIGNED_EXAMPLE;
|>
|>could be made 'portable' by using bit fields:
|>
|>typedef struct
|>{
|>   char c;
|>   int :24; /* padding */
|>   short s;
|>   int :16; /* padding */
|>   long l;
|>}ALIGNED_EXAMPLE;
|>
|>Those structures which are NOT passed from CPU board to CPU board should be
|>a non-issue, unless objects are being linked which have been built using
|>different compilers.  If the same compiler is being used (with the same
|>compile options for the same target), alignment is pretty much assured.
|>
|>Also, on a side note, some RISC processors treat structures differently
|>than integers,  that is, if sizeof(yourstruct)==sizeof(int), you still may
|>get exceptions:  The Motorola 88K processors are optimized to treat structures
|>differently than integers.
|>
|>Regards,
|>
|>Chris Domin
|>

You can still run into trouble if your RISC machine is 64 bits...

For example, on an Alpha/AXP

main()
{
   struct {
        char x;
        long y;
   } z;

   printf("sizeof z = %d\n", sizeof(z));
}

The size of the structure is 16 bytes as longs are 64 bits. In this
case you need to make sure things are aligned on quad word boundries.

 
- -------------------------------------------------------------------------------
Matthew R. Singer                       LM Technology
Systems Engineer                        Systems & Software Consulting
singer@osfrt.mro1.dec.com               VxWorks/Unix/MS-DOS/X Window/Motif
508-467-9108                            508-877-8736
- -------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: mbufs
Date: Wed, 24 Aug 1994 15:53:35 GMT
From: gerlach@netcom.com (Matthew H. Gerlach)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <gerlachCv1qtC.Gn2@netcom.com>

Raj Gawera was asking about mbufs so I thought I would offer my simplistic
view of the structure.

One of the main design issues when delevoping networking software is 
to determine the amount of memory to allocate to a "packet".  If
you are an ethernet only router, one could allocate 1500 bytes foreach
packet because thats the max ethernet packet size.  This can be wasteful
if most packets are small.  The other trick is that networking software
must usually strip off a few bytes and/or prepend a packet.  Back
to the router example, a routed IP packet comes in one interface and
gets shipped out another serial interface.  The enternet header is stripped
and a PPP or SLIP header is put on.  The mbuf data structure deals
with these two issues.

An mbuf chain is a single packet broken into 128 (I think) byte chunks.
A simple way to prepend a header is to get another single mbuf, fill, and
then stick in front of the chain.  The size of the packet is the sum
of all the datalengths of the individual mbufs.  

One last interesting note about mbufs is related to performance. Many
device drivers have a received packet DMAd directly into a single
piece of ram and then copy the received packet to an mbuf chain before
handing it off to the networking software.  If the hardware can break up
a packet and the mbuf memory pool is DMAble, then the driver can be 
written so that hardware reads and writes directly into mbuf chains. 

I hope this helps,
Matthew H. Gerlach

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

Newsgroups: comp.os.vxworks
Subject: Re: Self host kernel, NFS automount
Date: Wed, 24 Aug 1994 17:23:48 GMT
From: jfinley@netcom.com (John Finley)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Message-ID: <jfinleyCv1uzo.K3L@netcom.com>
References: <1994Aug23.211252.16389@news.dfrf.nasa.gov>

Rob -Not from Bloom County- Binkley, EIT (binkley@xavier.dfrf.nasa.gov) wrote:
: I am trying to build a set of vxWorks 5.1.1 PROMs that
: will self host the vxWorks kernel (w/symbol table) without
: FTPing from a UNIX host.  BUT...I still need the CPU to
: initialize the network software, automount any/all exported
: NFS disks from the UNIX host that is configured in the
: NVRAM and execute a startup script.

: Is this a do-able configuration?
...
: Rob Binkley

My current system (MVME167) boots from SCSI, then inits the
network and automounts everything from boot host, which is
not used for anything else, if the 'other' boot parameter is
the name of the network interface. It figures this out in
...vw/src/config/usrNetwork.c, function usrNetInit(). I would
think you could do something similar with a standalone config.

John Finley
jfinley@netcom.com

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

Newsgroups: comp.os.vxworks
Subject: Symbol Table Lookup <Q>
Date: Wed, 24 Aug 1994 19:04:12 GMT
From: calvin@netcom.com (John Calvin)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Keywords:  sysFindByName
Message-ID: <calvinCv1zn0.Jpu@netcom.com>


Greetings Vx users:

Could somebody who is familiar with the symbol table lookup utilities
provide a code fragment to look up a global shell variable name and return
its address and type.  Ive been working on this on my own, but Im always
getting a not found return code for symFindByName, for values I know are
in the symbol table. Or possibly Im searching the wrong table( sysSymTbl).
Are data elements posibly loaded elsewhere?
 
Any assistance would be appreciated,  Thanks in advance. 
 
John Calvin 
Calvin@netcom.com 

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

Newsgroups: comp.os.vxworks
Subject: Re: Excluding Network services
Date: 24 Aug 1994 20:28:42 GMT
From: billr@saab.CNA.TEK.COM (Bill Randle)
Organization: Tektronix, Inc., Redmond, OR
Message-ID: <33gahq$d5p@marlyn.cna.tek.com>
References: <1994Aug23.205925.29367@micom.com>
Reply-To: billr@saab.CNA.TEK.COM

In article <1994Aug23.205925.29367@micom.com>, davem@micom.com (David Monachello) writes:
|> hi,
|> 
|> I'm trying to build a rom version of vxworks for the mb930 sparc eval board
|> which does not have the wind river networking code in it. I've excluded
|> the network facilities from usrConfig.h but I get the following errors:
|> <list of errors deleted>
|> If I define INCLUDE_NETWORK these error go away (but I get all the code
|> I don't want). I'm running vxworks version 5.1.

I found a similar thing when I tried to build a romable 68k VxWorks. What ended
up doing was starting with INCLUDE_NETWORK undefined, then look for the conflicts
(like you did), then go in with 'ar' and remove those obj files from the library
archive. This will generate some more link errors, which you track down and
eliminate. I also #undef'd everything that I didn't need. Don't forget to udef
STANDALONE_NET also, along with INCLUDE_NETWORK. Here's what part of my config.h
looks like:

#undef INCLUDE_BOOTP            /* bootp */
#undef INCLUDE_DEBUG            /* native debugging */
#undef INCLUDE_ENV_VARS /* unix compatable environment variables */
#undef INCLUDE_HW_FP            /* no hardware fpp */
#undef INCLUDE_LOADER           /* object module loading */
#undef INCLUDE_LOGGING          /* logTask logging facility */
#undef INCLUDE_NETWORK         /* network subsystem code */
#undef INCLUDE_NET_INIT        /* network subsystem initialization */
#undef INCLUDE_NET_SHOW        /* network info and status facilities */
#undef INCLUDE_NET_SYM_TBL     /* load symbol table from network */
#undef INCLUDE_PIPES            /* pipe driver */
#undef INCLUDE_RLOGIN          /* remote login */
#undef INCLUDE_RPC              /* rpc package */
#undef INCLUDE_SELECT           /* select() facility */
#undef INCLUDE_SHELL            /* interactive c-expression interpreter */
#undef INCLUDE_SIGNALS          /* software signal library */
#undef INCLUDE_STARTUP_SCRIPT   /* execute start-up script */
#undef INCLUDE_STAT_SYM_TBL     /* create user-readable error status */
#undef INCLUDE_SYM_TBL  /* symbol table package */
#undef INCLUDE_TFTP_CLIENT      /* tftp client */
#undef INCLUDE_TIMEX            /* timexLib for exec timing */
#undef INCLUDE_UNLOADER /* object module unloading */

#undef INCLUDE_ANSI_LOCALE      /* ANSI-C locale library functionality */
#undef INCLUDE_ANSI_TIME        /* ANSI-C time library functionality */
 
#undef INCLUDE_AOUT                     /* a.out object modules */

#undef STANDALONE_NET           /* include net init when building stand alone */
#undef INCLUDE_SLIP             /* include the slip network interface */
#undef INCLUDE_EX               /* remove unnecessary driver */
#undef INCLUDE_ENP              /* remove unnecessary driver */
#undef INCLUDE_LN               /* remove unnecessary driver */
#undef INCLUDE_SM_NET           /* remove unnecessary driver */
#undef INCLUDE_BP               /* remove unnecessary driver */

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

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

Newsgroups: comp.os.vxworks
Subject: VxWorks driver for Fore ATM board
Date: Wed, 24 Aug 1994 20:22:39 GMT
From: heyes@codahp.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.94Aug24162239@codahp.cebaf.gov>
Followup-To: comp.os.vxworks
Sender: usenet@murdoch.acc.Virginia.EDU

Does anyone know of a VxWorks driver for the Fore VME ATM card?
I know someone at the Brookhaven lab who is working on one but
I am interested in anything working NOW. I have to advise several
people on hardware to buy, FDDI  working now, or ATM working next
year.
	Alternatively are there any compatible boards with VxWorks
drivers on the market?
- --

		Graham

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

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

Newsgroups: comp.os.vxworks
Subject: Re: Memory Alignment
Date: Thu, 25 Aug 1994 04:08:27 GMT
From: ericr@vcd.hp.com (Eric Ross)
Organization: Hewlett-Packard VCD
Message-ID: <Cv2ou4.F5x@vcd.hp.com>
References: <199408231349.JAA03245@a9926>
Sender: news@vcd.hp.com (News user)

You can explicitely set the alignment by using the #pragma align
directive in the compiler.  Also, it is simple to look at the assy
output from the same.

- --
Eric Ross, WB7SDE  |  Hewlett-Packard Company, VPR
ericr@vcd.hp.com   |  Vancouver, WA, USA

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

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


From stan@lassen.rti.com  Thu Aug 25 11:20:39 1994
From: stan@lassen.rti.com (Stan Schneider)
Date: Thu Aug 25 11:20:46 PDT 1994
Subject: Re: Symbol Table Lookup <Q>
>> Date: Wed, 24 Aug 1994 19:04:12 GMT
>> From: calvin@netcom.com (John Calvin)
>> 
>> Could somebody who is familiar with the symbol table lookup utilities
>> provide a code fragment to look up a global shell variable name and return
>> its address and type.  Ive been working on this on my own, but Im always
>> getting a not found return code for symFindByName, for values I know are
>> in the symbol table. Or possibly Im searching the wrong table( sysSymTbl).
>> Are data elements posibly loaded elsewhere?
>>  

We've never had a problem with this.  Sometimes compiler-generated symbols have
a leading underscore, but you shouldn't have problems with shell-generated
symbols.  This code should work (paraphrased from other code):

    public 
    /* Returns the value of the symbol, if found, else NULL */
    void *SymbolConvertSym2Addr(char *sym)
    {
	int inc;
	char *symaddr;
	SYM_TYPE type;
    
	/* VxWorks symbol access */
	if (symFindByName(sysSymTbl, sym, &symaddr, &type) == ERROR) {
	    return (NULL);
	}
	return((void *) symaddr);
    }


{vx@thresher} ->fish = 4;
new symbol "fish" added to symbol table.
fish = 0x7fdb00: value = 4 = 0x4
{vx@thresher} ->SymbolConvertSym2Addr "fish"
value = 8379136 = 0x7fdb00 = fish

Here's one that tries for an underscore too:

    public
    /* Convert symbolic name to an address.  Finds the symbol with our without a
       leading underscore. */
    void *SymbolConvertVariable2Addr(char *varname)
    {
	char _str[256];
	char *str;
	void *symloc;
    
	str = &_str[1];
	strncpy(str, varname, 254);   /* Not fast, but lookup is slow anyways */
	_str[255] = '\0';
    
	if((symloc = SymbolConvertSym2Addr(str)) == NULL) {
	    /* Not found.  Try it with a '_' pre-pended. */
	    _str[0] = '_';
	    if((symloc = SymbolConvertSym2Addr(_str)) == NULL) {
		return(NULL);
	    }
	}
	return(symloc);
    }
    
        -- 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 mpc@globesat.lanl.gov  Thu Aug 25 13:05:32 1994
From: mpc@globesat.lanl.gov (Michael Caffrey)
Date: Thu Aug 25 13:05:38 PDT 1994
Subject: framegrabbers

Does anyone have advice on choosing framegrabbers for integration into VME
with a 167 running vx?  I am particularly interested in reliable vendors
that include drivers for vxWorks and maybe, SPOX?, (dream on, I know).

Thanks,
Michael


----------------------------------------------------------------
Michael Caffrey                             PHONE:(505) 667-2422
MS: D440                                       FAX:(505)665-4197
Los Alamos National Laboratory               EMAIL: mpc@lanl.gov
Los Alamos, NM 87545                                GROUP: NIS-3


From ihw@rtp.co.uk  Fri Aug 26 01:22:26 1994
From: ihw@rtp.co.uk (Ian Willats)
Date: Fri Aug 26 01:22:33 PDT 1994
Subject: framegrabbers; SPOX and VxWorks

Michael Caffrey (mpc@globesat.lanl.gov) wrote: 

> Does anyone have advice on choosing framegrabbers for integration into VME
> with a 167 running vx?  I am particularly interested in reliable vendors
> that include drivers for vxWorks and maybe, SPOX?, (dream on, I know).

Well, no particular advice on framegrabbers, I'm afraid, but RTP are the UK
distributors for both VxWorks and SPOX, and have done quite a lot of work
with combined SPOX/VxWorks systems (including the MVME-167).  There are
existing off-the-shelf SPOX support packages for some VME-based DSP boards to
use in conjunction with VxWorks.

We think we're a "reliable vendor" too ;-)  Let us know if we can help!

Ian

-----------------------------------------------------------------------
Ian Willats

Real Time Products Ltd.,		e-mail: ihw@rtp.co.uk
Unit 8, Holt Court,			tel:	+44 21 333 6955
Aston Science Park, Jennens Road,	fax:	+44 21 333 5433
Birmingham. B7 4EJ
England.
-----------------------------------------------------------------------


From has@snmy.info.kobelco.co.jp  Fri Aug 26 03:53:14 1994
From: Sigeo Hasegawa <has@snmy.info.kobelco.co.jp>
Date: Fri Aug 26 03:53:22 PDT 1994
Subject: DAT & MO Drive
I'd like to use DAT(Digital Audio Tape) and MO(Magnetic Optical)
with SCSI of VxWorks.

Anyone who had used DAT(Digital Audio Tape) Drive,
and anyone who had used MO(Magnetic Optical) Disk Drive,

please tell me the Drive Equipment's trade name.

---------------------------------------------------
Electronics & Information Division
KOBE STEEL, LTD.	Shigeo Hasegawa
TEL: 81-78-261-6460 FAX: 81-78-261-6499
E-mail: has@info.kobelco.co.jp
---------------------------------------------------


From daemon@vxw.ee.lbl.gov  Fri Aug 26 04:00:31 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Aug 26 04:00:40 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Aug 26 04:00:20 PDT 1994

        Subject: POSIX 1003.1b SPEC?
        Subject: Re: Allen Bradley Data Highway
        Subject: Re: Allen Bradley Data Highway
        Subject: Re: Allen Bradley Data Highway
        Subject: Re: Allen Bradley Data Highway

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

Newsgroups: comp.os.vxworks
Subject: POSIX 1003.1b SPEC?
Date: Thu, 25 Aug 1994 15:31:21 GMT
From: pfulghum@boi.hp.com (Pat Fulghum)
Organization: Hewlett-Packard / Boise, Idaho
Message-ID: <Cv3KGA.166@boi.hp.com>
Sender: news@boi.hp.com (Boise Site News Server)

In the August copy of WindWord, it states the VxWorks supports the POSIX
1003.1b real time extensions.

Where can I find a copy of the spec for 1003.1b?

pfulghum@boi.hp.com
208-396-2667

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

Newsgroups: comp.os.vxworks
Subject: Re: Allen Bradley Data Highway
Date: Thu, 25 Aug 1994 14:11:27 GMT
From: tinker@mksol.dseg.ti.com (Douglas F Tinker)
Organization: Texas Instruments Inc
Message-ID: <1994Aug25.141127.1934@mksol.dseg.ti.com>
References: <9408241731.AA09824@wyeth.ds.boeing.com>

rick blair (blair@wyeth.ds.boeing.com) wrote:

: Fellow Vxers,

: I am working on a project that requires communication between an
: Allen-Bradley PLC-5 and a VME rack via Data Highway.  The processors in 
: the VME rack run VxWorks (of course).  

: Anyone know of a VME Data Highway interface card with VxWorks support?


: Any opinions, words of wisdom, etc would be more than welcome.

: Thanks in advance

: Rick Blair


: ***************************************************
: * email:     blair@elvis.ds.boeing.com            *
: * voice:     (206)657-6582                        *
: * usSnail:   P.O. Box 3707 M/S 9F-61              *
: *            Seattle, Wa 98124                    *
: *                                                 *
: *Disclaimer: The contents of this message in no   *
: *            way reflects the Opinions either real*
: *            or imaginary of the Boeing Company.  *
: *            All Opinions/rantings are my own and * 
: *            only I am responsible for them.      *
: ***************************************************

- -- 
Subject: Re: Allen Bradley Data Highway
Newsgroups: comp.os.vxworks
References: <9408241731.AA09824@wyeth.ds.boeing.com>


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

Newsgroups: comp.os.vxworks
Subject: Re: Allen Bradley Data Highway
Date: Thu, 25 Aug 1994 14:29:04 GMT
From: tinker@mksol.dseg.ti.com (Douglas F Tinker)
Organization: Texas Instruments Inc
Message-ID: <1994Aug25.142904.3900@mksol.dseg.ti.com>
References: <9408241731.AA09824@wyeth.ds.boeing.com>

rick blair (blair@wyeth.ds.boeing.com) wrote:

: Fellow Vxers,

: I am working on a project that requires communication between an
: Allen-Bradley PLC-5 and a VME rack via Data Highway.  The processors in 
: the VME rack run VxWorks (of course).  

: Anyone know of a VME Data Highway interface card with VxWorks support?


Vxers,
  First of all an apology - I hit a couple of errant keystrokes and
reposted the original message.  From the Dept of Redundancy Dept.

But I did have a question in mind.

What is the Data Highway mentioned?  I'm working a VME project
and looking at alternate data i/o options.  Any descriptions
would be appreciated.
Thanks,

Doug Tinker           tinker@lobby.ti.com


- -- 
Subject: Re: Allen Bradley Data Highway
Newsgroups: comp.os.vxworks
References: <9408241731.AA09824@wyeth.ds.boeing.com>


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

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


From jpc@ssd.ray.com  Fri Aug 26 08:11:18 1994
From: Carissimi <jpc@ssd.ray.com>
Date: Fri Aug 26 08:11:24 PDT 1994
Subject: Remote device access

I have two MVME167's, both of which are executing vxWorks (V5.0.2), and
both communicate via Enet. The first M167 (called terra) has attached
to it a DOS formatted disk (named /sd0/).   From this processor, I am
able to "cd /sd0/", obtain a listing of the files (via "ls /sd0/"), and
read files.

From the second CPU, I have created a network device (using
netDevCreate "terra:", "terra", 1).  I am able to 'cd "terra:/sd0/" '
to the device and read files from the device 'copy "xyz", but I am 
unable to obtain a listing of the files on the disk (directory) via "ls"
in any form.  When I do the "ls", I receive the message "File "sd0" not
found or permission problem" from the second processor, and "sd0: No
such file OR directory" from the first processor.

Am I missing something here, or is this not possible with this version
(or any versions)??


From mea@mclean.sparta.com  Fri Aug 26 08:39:31 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Aug 26 08:39:39 PDT 1994
Subject: Re: Remote device access
Greetings!

> 
> Submitted-by jpc@ssd.ray.com  Fri Aug 26 08:11:18 1994
> Submitted-by: Carissimi <jpc@ssd.ray.com>
>  
> 
> I have two MVME167's, both of which are executing vxWorks (V5.0.2), and
> both communicate via Enet. The first M167 (called terra) has attached
> to it a DOS formatted disk (named /sd0/).   From this processor, I am
> able to "cd /sd0/", obtain a listing of the files (via "ls /sd0/"), and
> read files.
> 
> >From the second CPU, I have created a network device (using
> netDevCreate "terra:", "terra", 1).  I am able to 'cd "terra:/sd0/" '
> to the device and read files from the device 'copy "xyz", but I am 
> unable to obtain a listing of the files on the disk (directory) via "ls"
> in any form.  When I do the "ls", I receive the message "File "sd0" not
> found or permission problem" from the second processor, and "sd0: No
> such file OR directory" from the first processor.
> 
> Am I missing something here, or is this not possible with this version
> (or any versions)??
> 
> 

What you're trying to do is not possible in 5.0.X.  There's a bug in the 
FTP daemon in that version that precludes the "ls" command.  It's fixed
in 5.1.X.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      



From mike@imatron.com  Fri Aug 26 09:23:21 1994
From: "Mike Morrison[Software Eng]" <mike@imatron.com>
Date: Fri Aug 26 09:23:28 PDT 1994
Subject: Re: framegrabbers; SPOX and VxWorks

What is SPOX?


From dowling@cub.kscorp.com  Fri Aug 26 11:57:04 1994
From: Bob Dowling <dowling@cub.kscorp.com>
Date: Fri Aug 26 11:57:10 PDT 1994
Subject: SPOX

Mike Morrison <mike@imatron.com> asked what SPOX is.  From a SPOX manual I had
on my bookshelf:

"SPOX is an integrated system of portable software components targeted for
high-end DSP['s].... SPOX presents a high-level software interface to the
underlying DSP hardware, improving the productivity of application developers
as well as enhancing program portability from one hardware platform to the
next."

It's from Spectron Microsystems, 5266 Hollister Ave, Santa Barbara CA 93111.
Phone # is (805) 967-0503.

Disclaimer:  I've only _read_ about it, and have not used it.

Bob Dowling
Software Engineer
KineticSystems Corp.


From daemon@vxw.ee.lbl.gov  Sat Aug 27 04:00:29 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Aug 27 04:00:39 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Aug 27 04:00:13 PDT 1994

        Subject: Ping
        Subject: broadcast interrupt
        Subject: Re: DAT & MO Drive
        Subject: Re: mbufs in network driver code
        Subject: Re: Thanks...but my broadcast still doesn't work...
        Subject: Re: mbufs
        Subject: Re: Network interface drivers
        Subject: Need VME cage and cpu

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

Newsgroups: comp.os.vxworks
Subject: Ping
Date: Fri, 26 Aug 1994 09:15:18 GMT
From: rsgawera@wg.icl.co.uk (Raj Gawera)
Organization: International Computers Limited
Keywords: ping, network, grope
Message-ID: <Cv4xpJ.KFG@oasis.icl.co.uk>
Reply-To: rsgawera@wg.icl.co.uk
Sender: news@oasis.icl.co.uk

Hi all,
	Is there a ping command available for vxworks ?

		cheers,
		  Raj

Raj Gawera
ICL CSD
email  : rsgawera@wg.icl.co.uk




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

Newsgroups: comp.os.vxworks
Subject: broadcast interrupt
Date: Fri, 26 Aug 1994 18:52:44 GMT
From: kirchner@acts02.psf.ge.com (bruce kirchner)
Organization: Martin-Marietta Defense Systems
Message-ID: <1994Aug26.185244.4690@knight.vf.ge.com>
Sender: news@knight.vf.ge.com

I have Ada applications running under TartanWorks OS on several MVME166/167 68040 processor boards on a common VMEbus backplane. 
 
I need to generate an interrupt from an application on one board, to be received
simultaneously by the applications on all remaining boards on the VME backplane.
I had thought to use the shared memory semaphore capability to 'broadcast' a interrupt over the VMEbus.  This leads to several questions.

1. It appears that there is no direct way to 'broadcast'
   interrupts over the bus using the shared memory semaphore beyond
   counting or daisy-chaining.  Is this true?

2. If shared memory semaphores is the way to go, does the board need to be 
   configured with the type of interrupt set for VMEbus interrupts (SM_INT_BUS) 
   or mailbox interrupts (SM_INT_MAILBOX)?  

3. Since the shared memory mechanisms are also used for the network driver,
   which is default configured for mailbox interrupts, what effect will
   changing this default to SM_INT_BUS have on the local network?  What other
   effects of this change need to be considered?

4. Am I totally off base and out to lunch on this? Any alternatives for what
   I'm trying to do that don't require additional hardware?


Thanks for your assistance,

Bruce Kirchner
kirchner@acts02.psf.ge.com

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

Newsgroups: comp.os.vxworks
Subject: Re: DAT & MO Drive
Date: 26 Aug 1994 19:20:23 GMT
From: singer@osfrt.mro1.dec.com (Matt Singer)
Organization: Digital Equipment Corporation
Message-ID: <33lf9n$77s@mrnews.mro.dec.com>
References: <9408260943.AA12108@proton.snmy.info.kobelco.co.jp>
Reply-To: singer@osfrt.mro1.dec.com (Matt Singer)


In article <9408260943.AA12108@proton.snmy.info.kobelco.co.jp>, Sigeo Hasegawa <has@snmy.info.kobelco.co.jp> writes:
|>I'd like to use DAT(Digital Audio Tape) and MO(Magnetic Optical)
|>with SCSI of VxWorks.
|>
|>Anyone who had used DAT(Digital Audio Tape) Drive,
|>and anyone who had used MO(Magnetic Optical) Disk Drive,
|>
|>please tell me the Drive Equipment's trade name.
|>
|>---------------------------------------------------
|>Electronics & Information Division
|>KOBE STEEL, LTD.	Shigeo Hasegawa
|>TEL: 81-78-261-6460 FAX: 81-78-261-6499
|>E-mail: has@info.kobelco.co.jp
|>---------------------------------------------------
|>

I've used MaxOptix Tahihi MO drives with no problems...
Actually, I got better performance with the drives on a MV 162 than
on the two Risc workstations I used them with.

- -- 
- -------------------------------------------------------------------------------
Matthew R. Singer                       LM Technology
Systems Engineer                        Systems & Software Consulting
singer@osfrt.mro1.dec.com               VxWorks/Unix/MS-DOS/X Window/Motif
508-467-9108                            508-877-8736
- -------------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: mbufs in network driver code
Date: Fri, 26 Aug 1994 20:25:03 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCv5sps.JK2@netcom.com>
References: <CuxsJq.Kpz@oasis.icl.co.uk>

Raj Gawera (rsgawera@ss11.wg.icl.co.uk) wrote:
: Hi,
: 	Can anyone point me to some useful words on mbufs ?
:	Are they also a unix thing or is it just vxWorks ?  

mbufs are from BSD UNIX.  vxWorks mbufs are based on 4.3 tahoe, with
a lot of custom modifications to support clustering without using
VM/page-flipping.  you can get a copy of tahoe mbuf code from various
places, including gatekeeper.dec.com, ftp.uu.net, etc.  source code
is really the best documentation.

:	Documentation is sparse and just mentions copy_from_mbufs etc.  

copy_from_mbufs () was written for vxWorks to be compatible with
SunOS kernel routine of the same name.  BSD tahoe did not have this
routine, but BSD net-2 and 4.4 releases do.  copy_from_mbufs() will
copy all the data from a given mbuf chain into a contiguous buffer
space.  the way i implemented copy_from_mbufs() for vxWorks was
via a macro, for which the source is available in h/net/mbuf.h


- -- 
hwajin
PEACEFUL STAR

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

Newsgroups: comp.os.vxworks
Subject: Re: Thanks...but my broadcast still doesn't work...
Date: Fri, 26 Aug 1994 20:36:31 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCv5t8v.L1o@netcom.com>
References: <1994Aug23.184501.1054@enterprise.rdd.lmsc.lockheed.com>

Gary Trimble (trimble@titan.rdd.lmsc.lockheed.com) wrote:
: I want to thank those people who reminded me to enable broadcasting
: (as opposed to Unix's not requiring it).

any UNIX using BSD-derived networking code will require the "enabling"
of broadcast.  vxWorks is not incompatible with UNIX in this area.

: I still can't get broadcasting
: to work. Does anyone have a good example (as opposed to the one in 
: /vw/src/demo/dg)? Thanks!

EACCESS is only generated when ip_output() detects that socket level
option for BROADCAST is not set.  are you sure you're doing setsockopt()
before sending data?
- -- 
hwajin
PEACEFUL STAR

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

Newsgroups: comp.os.vxworks
Subject: Re: mbufs
Date: Fri, 26 Aug 1994 20:40:10 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCv5tEz.LGu@netcom.com>
References: <gerlachCv1qtC.Gn2@netcom.com>

Matthew H. Gerlach (gerlach@netcom.com) wrote:

: An mbuf chain is a single packet broken into 128 (I think) byte chunks.

an mbuf chain is one or more mbufs of varying lengths (small mbuf will
be 128 bytes, clusters in vxworks 1k, loaned mbufs of varying sizes)
chained together via 'm_next'.

- -- 
hwajin
PEACEFUL STAR

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

Newsgroups: comp.os.vxworks
Subject: Re: Network interface drivers
Date: Fri, 26 Aug 1994 21:01:02 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCv5uDr.188@netcom.com>
References: <9408161612.AA23083@linda.VisiCom.COM> <CuoCsr.Kv3@oasis.icl.co.uk>

Raj Gawera (rsgawera@wg.icl.co.uk) wrote:
: My questions/concerns are :

: 1. I can do direct internet address to hardware address mapping. How do I
: stop the vxworks trying to do ARP requests ? Do I have to manually fill in
: the ARP table or when is this part of ether_output( ). ?

set IFF_NOARP in your if_flags (in your ifp).

: 2.  I don't think I need to use ether_output( ).  I can do my own address
: resolution and queue the message directly. In xxoutput, where do I take the
: destination internet address from ? Is it in the sockaddr structure ?

yes.

: 3. The proprietry network doesn't support broadcast messages directly,
: only by sending to each node sequentially. This is obviously a pain and may
: flood the network if done too often. I know ARP uses broadcast but if I'm
: doing my own address resolution I can avoid these broadcasts. Are there any
: other situations where broadcast messages are used ?

first, you can make your device driver to indicate that broadcast is
not supported -- just turn off IFF_BROADCAST flag in if_flags.

secondly, if you are going to implement driver level point-to-many-points
broadcast manually, you can still do all that transparently, in which
case your device driver appears as a real broadcast-capable device
to IP layer.

: 4. If I use do_protocol_with_type( ), what packet do I send it ? It
: appears to want an ethernet packet but I want to pass it an IP packet. Also,
: what it the 'type' and where do I get it from? I guess my real problem is
: that I do no understand how IP packets are transformed into ethernet packets
: - any pointers to RFCs on this ?

the mbuf pointer you pass to it should be pointing to the beginning
of an IP packet, not ethernet frame.   the 'type' is the ethernet type
from ethernet header.  alternatively, you can use do_protocol, which
takes a pointer to ethernet header.

w.r.t do_protocol(), which handles input side events, there is no
transformation of IP packet -> ethernet frame.

: 5. When I start testing the whole setup, I am going to want diagnostic
: info. Is there any way I can get diagnostic type information from the
: vxworks comms ?

not much other than various "Show" routines.  you could use etherHook
facility to write a network analyser.  or just use printf or logMsg.

- -- 
hwajin
PEACEFUL STAR

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

Newsgroups: comp.arch.bus.vmebus,comp.sys.m68k,comp.sys.m88k,comp.os.os9,comp.os.vxworks
Subject: Need VME cage and cpu
Date: 26 Aug 1994 22:09:12 -0400
From: krr@news.gate.net (Keith Richards)
Organization: CyberGate, Inc.  Florida
Message-ID: <33m788$25g9@inca.gate.net>

I am looking for a VME backplane and 68000 base motherboard for a project 
that 
I am working on... Preferably, I would like a Motorola 147 board or 
better.... 
 Any help will be appreciated

Thanks
Keith Richards

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

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


From magnusb@informator.se  Sat Aug 27 04:31:45 1994
From: magnusb@informator.se
Date: Sat Aug 27 04:31:53 PDT 1994
Subject: RE: Motorola/vxworks boot roms


>There was a thread not long ago discussing how to
>set up the the MVME167 to have both Motorola and
>vxworks proms installed. I guess this set up
>will allow one to boot vxworks and still have the
>motorola diagnostics/debug available.
>If anyone kept this info could you please forward?

>Thanks

I have the same problems....
Please foward it to me also.

Thanks
Magnus Bardh




From dowling@cub.kscorp.com  Sat Aug 27 08:26:59 1994
From: Bob Dowling <dowling@cub.kscorp.com>
Date: Sat Aug 27 08:27:05 PDT 1994
Subject: Ping

Raj Gawera (rsgawera@wg.icl.co.uk) asked if there's a 'ping' function for
VxWorks.  The VxWorks archive lists one such function.  To get it, send the
following line as the body of a message to vxworks_archive@ncar.ucar.edu:

send ping01 from vx

-----
Regards,

Bob Dowling            dowling@kscorp.com
Software Engineer

KineticSystems Corp.   VXI & CAMAC Data Acquisition
900 N. State St.       (800) DATA - NOW
Lockport IL 60441


From daemon@vxw.ee.lbl.gov  Sun Aug 28 04:00:21 1994
From: daemon@vxw.ee.lbl.gov
Date: Sun Aug 28 04:00:29 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Aug 28 04:00:12 PDT 1994

        Subject: bus error address in sig handler
        Subject: Re: broadcast interrupt

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

Newsgroups: comp.os.vxworks
Subject: bus error address in sig handler
Date: Sat, 27 Aug 94 20:59:33 GMT
From: erolfe@ll.mit.edu (Ed Rolfe)
Organization: MIT Lincoln Lab
Message-ID: <1994Aug27.205933.8217@ll.mit.edu>
Reply-To: erolfe@ll.mit.edu (Ed Rolfe)
Sender: news@ll.mit.edu

Greetings,

If I install a sigHandler for SIGSEGV (bus error), how
can the installed handler get access to the address
which generated the error?  I looked briefly at the
struct sigcontext, but couldn't see anything obvious.

Any help would be greatly appreciated. 

Thanks,

- -- 

+-------------------------------------------------------------+
| Edward G. Rolfe          email: erolfe@ll.mit.edu           |
| MIT Lincoln Laboratory   voice: 617/981-4013                |
| MS B-284                 fax:   617/981-0785                |
| 244 Wood Street          Division 6 Group 64                |
| Lexington, MA 02173      Satellite Communication Technology |
+-------------------------------------------------------------+


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

Newsgroups: comp.os.vxworks
Subject: Re: broadcast interrupt
Date: Sat, 27 Aug 1994 22:12:33 GMT
From: afraser@hookup.net (Andrew Fraser)
Organization: HookUp Communication Corporation, Ottawa, Ontario, CANADA
Message-ID: <afraser.58.2E5FBA50@hookup.net>
References: <1994Aug26.185244.4690@knight.vf.ge.com>

In article <1994Aug26.185244.4690@knight.vf.ge.com> kirchner@acts02.psf.ge.com (bruce kirchner) writes:
>I have Ada applications running under TartanWorks OS on several MVME166/167
>68040 processor boards on a common VMEbus backplane. 
>I need to generate an interrupt from an application on one board, to be 
received>simultaneously by the applications on all remaining boards on the VME 

>1. It appears that there is no direct way to 'broadcast'
>   interrupts over the bus using the shared memory semaphore beyond
>   counting or daisy-chaining.  Is this true?

There isn't any type of broadcast cycle or interrupt in a VME system; if you 
configured more than one card to respond to a VME interrupt, then only the 
first would succeed since it will get the bus and receive a vector from the 
interrupter.  All the other cards, if they tried to respond to the interrupt 
with an interrupt-acknowlede cycle would get no response and experience a 
spurious interrupt.
Without knowing all about Mot's vme interface, I can't suggest any tricky ways 
around this (there might be one, if all cards to be interrupted can have that 
vme interrupt configured as autovectored, but it also makes several 
assumptions about software activity and response times).

>2. If shared memory semaphores is the way to go, does the 
board need to be >   configured with the type of interrupt set for VMEbus 
interrupts (SM_INT_BUS) >   or mailbox interrupts (SM_INT_MAILBOX)?  
No data broadcast cycles, but instead, could you have whoever generates the 
interrupt, interrupt itself and the ISR would, in one short loop, do a write 
cycle to every card that needed to be notified.

- -Andy
(interested to see if anyone else has a solution)


    ----------------------------------------------------------------
   |       Andrew Fraser             ******                   ***** |
   |    Senior Hardware Designer     ***** *                 *****  |
   |                                 **** ***  ***** *****  ***** * |
   |   Tel: (613) 596-9922 ext 251   *** ****  **** *****  ***** ** |
   |   Fax: (613) 596-0574           ** *****  *** *****  ***** *** |
   | Email: andrewf@dy4.isis.org     * *****   ** *****  ***** **** |
   |        afraser@hookup.net       ******    * *****        ***** |
   | DY 4 Systems Inc.                          *****         ***** |
   | 21 Fitzgerald Rd., Nepean                 *****                |
   | Ontario, Canada K2H 9J4         CUSTOMER FIRST, QUALITY ALWAYS |
    ----------------------------------------------------------------

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

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


From daemon@vxw.ee.lbl.gov  Mon Aug 29 04:00:21 1994
From: daemon@vxw.ee.lbl.gov
Date: Mon Aug 29 04:00:29 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Aug 29 04:00:12 PDT 1994

        Subject: Re: broadcast interrupt

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

Newsgroups: comp.os.vxworks
Subject: Re: broadcast interrupt
Date: Sun, 28 Aug 1994 23:13:10 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCv9pty.DqD@netcom.com>
References: <1994Aug26.185244.4690@knight.vf.ge.com>

In article <1994Aug26.185244.4690@knight.vf.ge.com>,
bruce kirchner <kirchner@acts02.psf.ge.com> wrote:
>
>1. It appears that there is no direct way to 'broadcast'
>   interrupts over the bus using the shared memory semaphore beyond
>   counting or daisy-chaining.  Is this true?
>

mostly true, except some vendors provide mailbox interrupts that
can be set up for broadcast/multicast message passing. (some force boards
will do this).

- -- 
hwajin
PEACEFUL STAR

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

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


From leonid@rst.co.il  Mon Aug 29 07:37:17 1994
From: leonid@rst.co.il (Leonid Rosenboim)
Date: Mon Aug 29 07:37:23 PDT 1994
Subject: Cygnus G++
Dear VXperts,

One of our customers is considering using the GNU C++ cross compiler
from Cygnus Support for i960 in conjunction with VxWorks.
I am looking for users who have any experience with this configuration
to get a feeling of what kind of problems we should expect.
Also, Cygnus brochure claims they will comply with ANSI C++ language specs.
Would anyone happen to know if ANSI C++ is a final standard now ?

Any info on this subject will be greatly appreciated.
Comments from Cygnus are welcome.

-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      Cell:  +972-50-307-142
Wind River Systems Distributor             E-Mail: leonid@rst.co.il


From guthrie@power.amasd.anatcp.rockwell.com  Mon Aug 29 07:53:09 1994
From: guthrie@power.amasd.anatcp.rockwell.com (Bob Guthrie)
Date: Mon Aug 29 07:53:17 PDT 1994
Subject: VxWorks ping
Raj Gawera:
	Try the "ping01" file in the archive. I got a "ping.c" from somewhere,
I think this is where I got it.

	Robert Guthrie


From howard@sidney.nosc.mil  Mon Aug 29 11:26:42 1994
From: howard@sidney.nosc.mil (Mike Howard)
Date: Mon Aug 29 11:26:48 PDT 1994
Subject: T1 data transmission
Greetings....

We have an application where we are remoting data from a set of sensors over a T1 dedicated line.  The remote end is a VME chassis with an 80 channel A/D and a Force 68030 CPU.  The receiving end is a SUN with the Fat Wide network enhancement.  Does anyone know of an add-on high speed serial board with an existing vxWorks network driver?  Any information would be appreciated.
					Thanks
              __  __  __                     
             /  \/  \/  \  o    /_          /^\    /
                /   /   /      /__)  __       /   /
               /   /   /  /   / \   /__)     /---/
              /   /   /__/\__/  /___\___    /   / o

------------------------------------------------------------------
                                |
 G. "Mike" Howard               |      _/      _/_/_/_/  _/_/_/_/_/_/_/
 NCCOSC RDT&E Div Code 714      |     _/_/    _/      _/      _/     _/
 Rm 234, Bldg 106, Bayside      |    _/ _/   _/      _/  _/_/_/      _/
 Ph: (619) 553-1524             |   _/  _/  _/_/_/_/        _/      _/
 Fax: (619) 553-5229            |  _/   _/ _/  _/      _/_/_/      _/
 e-mail: howard@sidney.nosc.mil | _/    _/_/    _/   _/   _/     _/
                                |_/      _/      _/  _/_/_/_/_/_/
                                |
------------------------------------------------------------------


From kevinr@photon.ceco.com  Mon Aug 29 13:17:17 1994
From: kevinr@photon.ceco.com (Kevin R. Rumbaugh)
Date: Mon Aug 29 13:17:24 PDT 1994
Subject: Floating point zero compiler problem?


We recently uncovered an interesting problem with the floating
point representation of zero's when using the Wind River supplied
GNU compiler to cross compile for 68K (68040).  It seems that 
no matter how we try to represent a floating point zero, it
always is stored as if it was a -0.0.  I wrote the following
simple program to try it out, and then ran it on two platforms
with three different compilers.  Both of the native Solaris 2
compilers generated results that I expected, while the cross
compile to 68k did not. When the cross compiled code was run,
the hex representation of all three zeroes was the same, ie
the representation of -0.0.  Has anyone else seen this or know
anything about it?



Example code fragment:
----------------------
fpt()
{

   float t1,t2,t3;
   long t4;

	/* store floating point zero three different ways */
   t1 = 0.0;
   t2 = -0.0;
   t3 = +0.0;

   t4 = 0;

	/* print the hex representation of the numbers */
   printf("t1=%x\n",t1);
   printf("t2=%x\n",t2);
   printf("t3=%x\n",t3);
   printf("t4=%x\n",t4);


}

   Compiled using Sun's CC 3.0 for Solaris 2 on a 2.3 machine
---------------------------------------------------------------
marauder:/home/kevinr 257>cc t.c
marauder:/home/kevinr 258>a.out
t1=0
t2=80000000
t3=0
t4=0
 
   Compiled using GNU gcc(2.4.5) for Solaris 2 on a 2.3 machine
---------------------------------------------------------------
marauder:/home/kevinr 259>gcc t.c
marauder:/home/kevinr 260>a.out
t1=0
t2=80000000
t3=0
t4=0

   Compiled using GNU gcc(2.2.3.1) VxWorks 5.1.1 for Solaris 2 on a 2.3 machine to 68k
---------------------------------------------------------------------------------------
marauder:/home/kevinr 264>cc68k -DCPU=MC68040 -B/packs2/wind_river/v511/$ARCH.68k/lib/gcc-lib/ -I/packs2/wind_river/v511/h -traditional -g -c t.c
-> ld < t.o
-> fpt
t1=80000000
t2=80000000
t3=80000000
t4=0


-- 

                     Kevin Rumbaugh  'The Marauder'
		      --- Commonwealth Edison ---
		           A Unicom division
E-MAIL    : kevinr@ceco.com  OR   uunet!ceco!kevinr
AT&T      : (312) 394-8894        FAX	: (312) 394-4233
USMAIL    : Information Systems; Room 1135; 125 S. Clark; Chicago IL 60603


From ihw@rtp.co.uk  Tue Aug 30 01:22:27 1994
From: ihw@rtp.co.uk (Ian Willats)
Date: Tue Aug 30 01:22:38 PDT 1994
Subject: SPOX and VxWorks

Mike Morrison (mike@imatron.com) asked:

> What is SPOX?

In a nutshell, it's a real-time kernel for DSPs.  It has some similar
features to VxWorks, and can be used in conjunction with VxWorks to build
hybrid microprocessor/DSP-based systems as well as embedded systems built
entirely on DSPs.

Ian

-----------------------------------------------------------------------
Ian Willats

Real Time Products Ltd.,		e-mail: ihw@rtp.co.uk
Unit 8, Holt Court,			tel:	+44 21 333 6955
Aston Science Park, Jennens Road,	fax:	+44 21 333 5433
Birmingham. B7 4EJ
England.
-----------------------------------------------------------------------


From daemon@vxw.ee.lbl.gov  Tue Aug 30 04:00:24 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Aug 30 04:00:32 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Aug 30 04:00:13 PDT 1994

        Subject: using vxWorks.st load image with gdb 4.12
        Subject: RE: Motorola/vxworks boot roms
        Subject: RS488 Support
        Subject: Re: RS488 Support
        Subject: Re: Cygnus G++

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

Newsgroups: comp.os.vxworks
Subject: using vxWorks.st load image with gdb 4.12
Date: 29 Aug 94 10:37:52 CDT
From: u4936@fir119.cray.com (Susan Cupp)
Organization: Cray Research, Inc.
Message-ID: <1994Aug29.103752.8947@driftwood.cray.com>
Sender: u4936@fir119 (Susan Cupp)


I've been attempting to get the default gdb to utilize the vxWorks.st load
image correctly -- in our case, it's the sunec BSP.  Our testing so far
indicates that gdb doesn't understand the 0x20000 entry address specified in
the load image, and may not like the OMAGIC format.  gdb seems to like 
ZMAGIC and entry address of 0x2020.  So we modified the vxWorks.st build
to result in ZMAGIC with entry address of 0x2020, and gdb performs well
with the modified load image.  The problem is that this type of modified
load image will only load/execute on our hardware platform with a modified
BSP; modifying the default build to entry address of 0x2020 causes the
vxWorks.st load to "hang" without completion (we were simplying trying to
jump to sysInit located at 0x20000 from 0x2020).  So it looks like we are stuck
with trying to find out what about the (approximate) 0x20000 entry address
is not totally compatible with gdb.  

A sample of the modified load image working as expected with gdb -- no
core file is being used:

(gdb) file good_gdb/vxWorks.st
Reading symbols from good_gdb/vxWorks.st...done.
(gdb) print &consoleFd
$1 = (int *) 0x93304
(gdb) print consoleFd
$2 = 0

A sample of the default load image working incorrectly with gdb -- again
no core file is being used:

(gdb) file bad_gdb/vxWorks.st
Reading symbols from bad_gdb/vxWorks.st...done.
(gdb) print &consoleFd
$1 = (int *) 0x98b94
(gdb) print consoleFd
Cannot access memory at address 0x98b94.

If anyone has any input on this, it would really be appreciated.
Thanks,
Susan

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

Newsgroups: comp.os.vxworks
Subject: RE: Motorola/vxworks boot roms
Date: Mon, 29 Aug 1994 18:07:06 GMT
From: bobf@courier.hq.verdix.com (Bob Foery)
Organization: Rational Software Corporation
Message-ID: <1994Aug29.180706.10614@verdix.com>
References:  <199408271131.NAA14109@mail.swip.net>
Sender: news@verdix.com

I was under the impression that Morotola released a new rev of the
mv167 bug proms that supported booting from the network.

Has anybody tried this?

Robert F. Foery, Jr.
Rational Software Corporation
bobf@rational.com

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

Newsgroups: comp.os.vxworks
Subject: RS488 Support
Date: 29 Aug 1994 19:44:01 GMT
From: nam@crazy.esl.com (Nam N. Nguyen)
Organization: Cornell Theory Center
Message-ID: <33tdq1$bn3@gatekeeper.esl.com>

I am looking for an RS488 (?) interface hardware, preferably with VxWorks
support.  If you know one, please send me some brief info. (hardware vendor
phone number, ..., driver's vendor, ...).

Thank you very much,

Nam N.

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

Newsgroups: comp.os.vxworks
Subject: Re: RS488 Support
Date: 29 Aug 1994 21:47:35 GMT
From: gary@maple.mc.com (Gary Von Colln)
Organization: Mercury Computer Systems, Chelmsford MA 01824
Message-ID: <33tl1o$ce@jericho.mc.com>
References: <33tdq1$bn3@gatekeeper.esl.com>
Sender: gary@maple (Gary Von Colln)

I know that AP Labs resells 488 boards from National Instruments.  They also sell a VxWorks drivers for that board.  AP Lab's phone # is 619-546-8626.

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

Newsgroups: comp.os.vxworks
Subject: Re: Cygnus G++
Date: 30 Aug 1994 07:41:59 +1000
From: rjl@f111.iassf.easams.com.au (Rohan LENARD)
Organization: EASAMS (Australia) Pty Ltd
Message-ID: <33tkn7$6e9@f111.iassf.easams.com.au>
References: <9408291411.AA00576@rst.co.il>

Hi there,

In article <9408291411.AA00576@rst.co.il>,
Leonid Rosenboim <leonid@rst.co.il> wrote:
>Dear VXperts,
>
>One of our customers is considering using the GNU C++ cross compiler
>from Cygnus Support for i960 in conjunction with VxWorks.
>I am looking for users who have any experience with this configuration
>to get a feeling of what kind of problems we should expect.

I was under the impression that cygnus didn't support the i960 fully
yet (No libc).  We (EASAMS) have been using cygnus compilers for VxWorks
cross development to m68k for about 8 months now, and have few problems.
Cygnus have always been quick to fix problems.

>Also, Cygnus brochure claims they will comply with ANSI C++ language specs.
>Would anyone happen to know if ANSI C++ is a final standard now ?

Nope, a draft ANSI C++ standard was expected to be available in Septemeber
this year, however I think that has slipped.  Cygnus are doing a very
good job tracking the draft standard (for instance)
eg.

  class foo {
    static const int x = 10;
  }

  const int foo::x;

The following was allowed at the last (or was it second last) committee
meeting.  We requested and had a patch to make this work within a week
of the meeting.

On the whole they are tracking the standard well.  Expect to see exceptions
and RTTI by the end of this year.  Namespaces are a long way off.  Template
code will improve very quickly now that the Standard Template Library has
been released by HP (although a few cygnus members have developed / are
developing there own version).


IMHO the cygnus compiler tools leave the WRS ones for dead.  As an example
compare the compiler age -

wrs cc68k is cygnus-2.2.3		(equivalent to gcc-2.2.3)

cygnus gcc is cygnus-progressive94q2	(equivalent to gcc-2.5.90)

I remember using gcc-2.2.3 about three years ago, and it had quite a lot of
faults then.


Regards,
	Rohan
- -- 
- ----------------------------------------------------------------------------
rjl@iassf.easams.com.au	| All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...

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

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


From daemon@vxw.ee.lbl.gov  Wed Aug 31 04:00:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Aug 31 04:00:31 PDT 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Aug 31 04:00:11 PDT 1994

        Subject: Scsi-III and VxWorks
        Subject: String Symbol Problems (Long)

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

Newsgroups: comp.os.vxworks
Subject: Scsi-III and VxWorks
Date: 31 Aug 1994 05:01:43 GMT
From: dat85715@indirect.com (D'Anne Thompson)
Organization: Internet Direct, Inc.
Message-ID: <3412rn$3u@herald.indirect.com>
Sender: dat85715@bud.indirect.com

!!! Warning - Crass Commercial Announcement !!!

Synergy Microsystems has just released a new daughterboard combining
Ethernet
and Scsi-III capabilities.  Named the 'EWSE' (pronounced 'Uzi')  the
hardware
board uses the new NCR-720 scsi chip to implement fast-wide scsi with a
max
burst transfer rate of 20MB/sec.  This daughterboard is compatible with
the 
full line of Synergy CPU products using 68020, 68030, or single/dual
68040 products.  Both differential and single-ended driver adaptors are
available for the EWSE. 

The VxWorks driver is based on WRS's original NCR710 driver with
disconnect/reconnect activated.  We have plans to make further
improvements
on this driver.  Beta release software is already available, with first
full release scheduled for the end of September.

In-house testing has been limited to a single evaluation disk unit that
is
limited to a max burst transfer rate of about 14MB/sec and a sustained
rate
of only 3MB/sec, using about 30 percent of available scsi bus
bandwidth. 
Customers are needed to help qualify and quantify the capabilities of
this
neat little toy.

Sales inquiries should be directed to (619) 452-0020. 

D'Anne Thompson
(Proud Software Engineer)
dee@synergy.encinitas.ca.us
dee@ioinc.tucson.az.us
dat85715@indirect.com

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

Newsgroups: comp.os.vxworks
Subject: String Symbol Problems (Long)
Date: Wed, 31 Aug 1994 07:17:10 GMT
From: calvin@netcom.com (John Calvin)
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Keywords: Symbol table
Message-ID: <calvinCvE1KM.HpJ@netcom.com>


Greetings again Vx'rs
Thanks to everyone who helped me out a few days ago trying to figure
out the symbol table search utility (symFindByname).  Ive go another
another problem, which I believe a few of you may be able to help with.
sorry about the length :-(

What Im trying to do:
Basically read in a line of text, as would be found in a regular script
file and interpret it.  This involves hunting for the symbol, and stuffing
the address returned from symFindByName with the desired contents.  This
all works fine for doubles and ints but handling strings isnt happening.

Q's:
1-What is the proper way to look up strings in the symbol table and
provided you locate it, update it's value with a new value.

2-Does anyone have a clear understanding of why symbol types have no
correlation to the type of storage allocation required.  I would have
thought the doubles, string and integer symbols would have had dis-similar
symbol types but they dont, they are all "9" whatever this means.

3-When doing a symAdd, is the group number really important.  Ive been
putting my new entries into group 1 for lack of any place else to put it.
Who defines the group ID's.

4-Why does the following piece of code which does this..

           statReturn = symFindByName (sysSymTbl,szStrVar, 
                                      (char **) strAddress, &Type);

screw up my stack? If there is a way to do this without the double de-
referenced pointer please show me. ;-)


the following in an excerpt from an equate module.  It handles input
lines such as iInteger = 5 and dDouble = 4.5 and szTemp = "hello".
Ive removed the portions dealing with everthing except strings as Ive
isolated my stack problems to string variable types, and in particular the
line which does the symFindByName for the string symbol.

STATUS EqualsOper (char *ptrInputLine)
{
    STATUS    statReturn  = ERROR;
    STATUS    statParse   = ERROR;
    char      ***strAddress;
    char      *ptrStr;
    SYM_TYPE  Type;
                    
    /* Input String Parsing Buffers */
    char      szStrVar[IN_LINE_LEN];
    char      szStrValue[IN_LINE_LEN];
    char      szTemp[IN_LINE_LEN];
    char      *ptrTokFind;
    char      *cpLast=(char*)NULL;


    /* Make sure bufers are cleared */
    bzero (szStrVar,strlen(szStrVar));
    bzero (szStrValue,strlen(szStrValue));
    bzero (szTemp,strlen(szTemp));


    /*
     * Check for Asci String Operations.
     * Break up a line like szTemp = "hello there" into three tokens.
     */ 
    if  (strstr(ptrInputLine,"\""))
    {
        /*
         * Isolate the inputs string lvalue.
         */ 
        if ((ptrTokFind = strtok_r ( ptrInputLine," ",&cpLast)) != NULL)
        {
            strcat (szStrVar,"_");
            strcat (szStrVar,ptrTokFind);
            ptrInputLine = (char *) NULL;

        /*
         * We know its a "=" so just toss this token.
         */
        if ((ptrTokFind = strtok_r ( ptrInputLine,"\"",&cpLast)) != NULL)
        {    
           /*
            * Isolate the rvalue.
            */
            if ((ptrTokFind = strtok_r ( ptrInputLine,"\"",&cpLast)) != NULL
            {    
                strcat (szStrValue, ptrTokFind);
                statParse = OK;
            }
         }

      }

       if (statParse != OK)
       {
            printf  ("String Parsing Error\n");
            printf  ("String %s\n", ptrInputLine);
            printf  ("String lvalue = %s rvalue = %s\n", 
                                szStrVar,szStrValue);
        }
       else
       {
           
/* If I remark out this next line, clearly my symbol lookup doesnt happen
 * but the stack doesn't get missaligned either.
 */
           statReturn = symFindByName (sysSymTbl,szStrVar, 
                                      (char **) strAddress, &Type);
           if ( statReturn != OK )
           {
               printf ("Symbol %s  not found: Creating New Symbol\n", 
                        szStrVar);
               if (((ptrStr = (char *) malloc (strlen(szStrValue)+ 1 )))
                         == NULL)
               {
                   printf ("Unable to allocate new storage space for %s\n",
                        szStrVar);
               }    
               else
               {
                   /* Whoa, this doesnt work!! Were 1 level of indirection 
                    *  off. Ive got to work on this.
                    */
/*
                   symAdd (sysSymTbl,szStrVar,(char *) ptrStr ,
                                (SYM_TYPE) 9,(UINT16) 1);

                   strcpy( ptrStr, szStrValue );
*/
               printf ("Cannot Currently handle new String Allocations \n");

                   statReturn = OK;
               }   
       
           }
           else
           {
               /*
                * Stuff the address returned from symfindByName with
                * the new string.
                */
               strcpy( **strAddress, szStrValue );

           }
        }
}

System dialog outlining what I believe is a stack miss-alignment, or
maybe its just squashing the input line.:

VXW->instr = "szTemp = \"this is a test\""

VXW->printf ("%s\n",instr)
szTemp = "this is a test"

VXW->EqualsOper (instr)                   
Symbol _szTemp  not found: Creating New Symbol  << This is actually ok 
Cannot Currently handle new String Alocations   << since its not handling
value = 0 = 0x0                                 << new symbols, properly

VXW->printf ("%s\n",instr)   
szTemp                          << Part of the input string is now gone. 

VXW->EqualsOper (instr) << Cant re-run this as input is now corrupt.
value = -1 = 0xffffffff = _semUiFormLock + 0xffc026ff

As usual, any advice (including RTFM if you tell me where) would be greatly
appreciated.

Thanks in Advance..

- ---------------------------------------------------------------------------
John Calvin
Calvin@netcom.com
- ---------------------------------------------------------------------------

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

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


From mulder@sdmis.nswses.navy.mil  Wed Aug 31 11:55:27 1994
From: mulder@sdmis.nswses.navy.mil
Date: Wed Aug 31 11:55:34 PDT 1994
Subject: DOS2UNIX
Hello vxers, first time in vxnetland !

I'm using a NETMANAGE product(TCP/IP for Windows) to download my files, 
over ethernet, from a laptop running DOS/WINDOWS.  My problem is when I
change my startup script file using the DOS editor,  the file is saved
in DOS format and vxworks will not load the files specified in the 
script file.  So, I need a dos2unix command which runs under DOS.  Does
anyone know where I can get this from.  Thanks in advance.

Ted Mulder
mulder@sdmis.nswses.navy.mil


From ss@spacenet.lanl.gov  Wed Aug 31 16:07:40 1994
From: ss@spacenet.lanl.gov (Steven Schramm)
Date: Wed Aug 31 16:07:47 PDT 1994
Subject: Re: DOS2UNIX
 
> Submitted-by mulder@sdmis.nswses.navy.mil  Wed Aug 31 11:55:27 1994
> Submitted-by: mulder@sdmis.nswses.navy.mil
>  
> Hello vxers, first time in vxnetland !
> 
> I'm using a NETMANAGE product(TCP/IP for Windows) to download my files, 
> over ethernet, from a laptop running DOS/WINDOWS.  My problem is when I
> change my startup script file using the DOS editor,  the file is saved
> in DOS format and vxworks will not load the files specified in the 
> script file.  So, I need a dos2unix command which runs under DOS.  Does
> anyone know where I can get this from.  Thanks in advance.
> 
> Ted Mulder
> mulder@sdmis.nswses.navy.mil

Ted,
I have had the same problem and ended up writing two little programs to go from
DOS-to-UNIX and vice versa.  They could be combined into one with a flag to
indicate direction.  Good luck :-)

===================================================================
Steven W. Schramm                      |Email: sschramm@lanl.gov
Los Alamos National Laboratory         |Voice: (505) 665-3865
NIS-3 Space Data Systems               |Fax  : (505) 665-4197
MS-D440                                |
Los Alamos, NM 87545                   |
===================================================================

#include <stdio.h>

#define CR 13
#define LF 10

void usage()
{
	printf("\n");
	printf("dtou - DOS to UNIX text file conversion program\n\n");
	printf("Usage:  dtou <infile> [<outfile>]\n");
	printf("   If no outfile is specified, the converted file will\n");
	printf("   overwrite the input file\n");
}

void main(argc, argv)
int argc;
char **argv;
{
	FILE *in, *out;
	char buff[256], *p, infile[64], outfile[64];

	if (argc < 2)
	{
		usage();
		exit(0);
	}

	strcpy(infile, *(++argv));

	in = fopen(infile, "r");
	if (argc > 2)
		strcpy(outfile, *(++argv));
	else
		strcpy(outfile, "junk");
	out = fopen(outfile, "w");

	while (fgets(buff, 256, in))
	{
		if (p = (char *)strchr(buff, CR))
		{
			*p = LF;
			*(++p) = '\0';
		}
		fprintf(out, "%s", buff);
	}

	close(in);
	close(out);
	if (argc < 3)
	{
		sprintf(buff, "mv %s %s\n", outfile, infile);
		system(buff);
	}
}
*****************************************************************************

#include <stdio.h>

#define CR 13
#define LF 10

void usage()
{
	printf("\n");
	printf("utod - UNIX to DOS  text file conversion program\n\n");
	printf("Usage:  utod <infile> [<outfile>]\n");
	printf("   If no outfile is specified, the converted file will\n");
	printf("   overwrite the input file\n");
}

void main(argc, argv)
int argc;
char **argv;
{
	FILE *in, *out;
	char buff[256], *p, infile[64], outfile[64];

	if (argc < 2)
	{
		usage();
		exit(0);
	}

	strcpy(infile, *(++argv));

	in = fopen(infile, "r");
	if (argc > 2)
		strcpy(outfile, *(++argv));
	else
		strcpy(outfile, "junk");
	out = fopen(outfile, "w");

	while (fgets(buff, 256, in))
	{
		if (p = (char *)strchr(buff, LF))
		{
			*p = CR;
			*(++p) = LF;
			*(++p) = '\0';
		}
		fprintf(out, "%s", buff);
	}

	close(in);
	close(out);
	if (argc < 3)
	{
		sprintf(buff, "mv %s %s\n", outfile, infile);
		system(buff);
	}
}



From thor@thor.atd.ucar.edu  Wed Aug 31 23:00:10 1994
From: thor@thor.atd.ucar.edu (Rich Neitzel)
Date: Wed Aug 31 23:00:18 PDT 1994
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
------------------------------------------------
VxWorks sources:

total 9794
-rw-r--r--   1 thor     staff      22132 Jun 18  1990 ansi.p1
-rw-r--r--   1 thor     staff      22717 Jun 18  1990 ansi.p2
-rw-r--r--   1 thor     staff      24174 Jun 18  1990 ansi.p3
-rw-r--r--   1 thor     staff       8108 Jun 18  1990 ansi.patch1
-rw-r--r--   1 thor     staff      37126 Jun 12  1992 ansilib01
-rw-r--r--   1 thor     staff      18913 Jun 12  1992 ansilib02
-rw-r--r--   1 thor     staff       2671 Jan  2  1990 benchmarks
-rw-r--r--   1 thor     staff       7168 Jul 13  1989 bitcnt
-rw-r--r--   1 thor     staff      11437 Feb 15  1991 c++builtin.shar
-rw-r--r--   1 thor     staff      22330 Apr  4  1990 c++headers.p1
-rw-r--r--   1 thor     staff      22775 Apr  4  1990 c++headers.p2
-rw-r--r--   1 thor     staff      29052 Dec  6  1989 camaclib1
-rw-r--r--   1 thor     staff      25095 Dec  6  1989 camaclib2
-rw-r--r--   1 thor     staff      31005 Dec  6  1989 camaclib3
-rw-r--r--   1 thor     staff      37770 Dec 21  1989 cbench.shar
-rw-r--r--   1 thor     staff       7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--   1 thor     staff       5853 May 31  1989 crc.shar
-rw-r--r--   1 thor     staff       8917 Oct  9  1990 deadman.shar
-rw-r--r--   1 thor     staff      41669 Dec  6  1991 dhrystones01
-rw-r--r--   1 thor     staff      19170 Apr  1  1993 dirlib01
-rw-r--r--   1 thor     staff      25681 Aug 29  1989 dt1451
-rw-r--r--   1 thor     rsf         4905 Aug 19 16:54 dup.shar
-rw-r--r--   1 thor     staff       5944 Apr 26  1989 fcompress.shar
-rw-r--r--   1 thor     staff      11561 Nov  1  1991 flags_class.shar
-rw-rw-r--   1 thor     rsf        88109 Jul 11 12:36 flash.zip
-rw-r--r--   1 thor     staff      44762 Jul 18  1990 force.p1
-rw-r--r--   1 thor     staff      40154 Jul 18  1990 force.p2
-rw-r--r--   1 thor     staff      80491 May  8  1989 force.shar
-rw-r--r--   1 thor     staff       2453 Mar 10  1993 gcc+68040
-rw-r--r--   1 thor     staff       6106 Oct 10  1989 getdate
-rw-r--r--   1 thor     staff       9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--   1 thor     rsf        13699 Aug 22 11:08 index
-rw-r--r--   1 thor     staff       2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--   1 thor     staff      35245 Oct  9  1990 joblib2.p1
-rw-r--r--   1 thor     staff      18110 Oct  9  1990 joblib2.p2
-rw-r--r--   1 thor     staff       9079 Apr  2  1990 lclflag.shar
-rw-r--r--   1 thor     rsf       174829 Dec  3  1993 lexyacc.tar.gz
drwxr-xr-x   2 thor     staff        512 Mar 21 12:15 libX11
-rw-r--r--   1 thor     staff      10747 Nov  3  1993 libg++-2.5-src.patch
lrwxrwxrwx   1 root     other         20 Mar 19 19:08 libg++-2.5.1-src.patch -> libg++-2.5-src.patch
lrwxrwxrwx   1 root     other         20 Mar 19 19:08 libg++-2.5.2-src.patch -> libg++-2.5-src.patch
-rw-r--r--   1 thor     staff       1568 Nov  3  1993 libgcc2-2.5.0.patch
-rw-r--r--   3 thor     staff       1545 Nov  3  1993 libgcc2-2.5.2.patch
lrwxrwxrwx   1 root     other         19 Mar 19 19:08 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch
-rw-r--r--   3 thor     staff       1545 Nov  3  1993 libgcc2-2.5.5.patch
-rw-r--r--   3 thor     staff       1545 Nov  3  1993 libgcc2-2.5.6.patch
lrwxrwxrwx   1 root     other         15 Mar 19 19:07 libio-2.5.1.patch -> libio-2.5.patch
lrwxrwxrwx   1 root     other         15 Mar 19 19:08 libio-2.5.2.patch -> libio-2.5.patch
-rw-r--r--   1 thor     staff       1228 Dec 29  1993 libio-2.5.patch
lrwxrwxrwx   1 root     other          6 Mar 19 19:07 libx11 -> libX11
-rw-r--r--   1 thor     staff       3515 Mar 16  1993 loadmeter.shar
-rw-r--r--   1 thor     staff      10399 May  4  1989 math.shar
-rw-r--r--   1 thor     staff      11950 May 30  1989 math2
-rw-r--r--   1 24       40         26655 Nov 15  1990 monitor.shar
-rw-r--r--   1 thor     staff      18733 Jun 14  1990 msgque_class.shar
-rw-r--r--   1 thor     staff     829713 Dec 17  1993 ntpv3.1.tar.gz
-rw-r--r--   1 thor     staff    1010176 Nov  8  1993 ntpv3.tar.gz
-rw-r--r--   1 thor     staff       1082 Dec 14  1993 objc.patch
-rw-r--r--   1 thor     staff      19422 Mar  1  1994 ping01
-rw-r--r--   1 thor     staff      20494 Oct 31  1991 pipe.shar
-rw-r--r--   1 thor     staff      15418 May 30  1989 poolLib
lrwxrwxrwx   1 root     other          7 Mar 19 19:07 poollib -> poolLib
-rw-r--r--   1 thor     staff      13204 Oct 31  1991 ring.shar
-rw-r--r--   1 thor     staff       6614 May 31  1989 semCnt
lrwxrwxrwx   1 root     other          6 Mar 19 19:07 semcnt -> semCnt
-rw-r--r--   1 thor     staff       2308 Jan  2  1990 ss1.bnch
-rw-r--r--   1 thor     staff      41196 Oct 16  1992 stevie01
-rw-r--r--   1 thor     staff      35279 Oct 16  1992 stevie02
-rw-r--r--   1 thor     staff      35278 Oct 16  1992 stevie03
-rw-r--r--   1 thor     staff      35012 Oct 16  1992 stevie04
-rw-r--r--   1 thor     staff      34502 Oct 16  1992 stevie05
-rw-r--r--   1 thor     staff      37476 Oct 16  1992 stevie06
-rw-r--r--   1 thor     staff      30073 Oct 16  1992 stevie07
-rw-r--r--   1 thor     staff      31562 Oct 16  1992 stevie08
-rw-r--r--   1 thor     staff      37360 Oct 16  1992 stevie09
-rw-r--r--   1 thor     staff      20662 Oct 16  1992 stevie10
-rw-r--r--   1 thor     staff      25717 Oct 16  1992 stevie11
-rw-r--r--   1 thor     staff      28075 Oct 16  1992 stevie12
-rw-r--r--   1 thor     staff      31852 Oct 16  1992 stevie13
-rw-r--r--   1 thor     staff      16225 Oct 10  1989 string.shar
-rw-r--r--   1 thor     staff       8424 Apr  1  1992 syslog.shar
-rw-r--r--   1 thor     staff      15096 Oct  2  1991 task_class.shar
-rw-r--r--   1 thor     staff      16171 Oct  9  1990 taskmon.shar
-rw-rw-r--   1 root     other     416642 Jan  7  1994 tclvx7.0v4.tar.gz
-rw-r--r--   1 thor     staff      10523 May 31  1989 tod.shar
-rw-r--r--   1 thor     staff      19912 Aug 27  1992 tp41.shar
-rw-r--r--   1 thor     staff      25790 Nov  8  1990 ty335.shar
-rw-r--r--   2 thor     rsf        44504 May  2 11:03 usrTime.shar
-rw-r--r--   2 thor     rsf        44504 May  2 11:03 usrtime.shar
-rw-r--r--   1 thor     rsf         4945 Apr 28 11:31 veclist01
-rw-r--r--   1 thor     staff      25814 Apr 26  1989 vtape.shar
-rw-r--r--   1 thor     staff      43671 Nov 22  1991 vwcurses01
-rw-r--r--   1 thor     staff      40180 Nov 22  1991 vwcurses02
-rw-r--r--   1 thor     staff      38308 Nov 22  1991 vwcurses03
-rw-r--r--   1 thor     staff      31181 Nov 22  1991 vwcurses04
-rw-r--r--   1 thor     staff      31798 Nov 22  1991 vwcurses05
-rw-r--r--   1 thor     staff      31459 Nov 22  1991 vwcurses06
-rw-r--r--   1 thor     staff      24279 Nov 22  1991 vwcurses07
-rw-r--r--   1 thor     staff       5491 Dec  8  1993 vx_cplusplus
-rw-r--r--   1 thor     rsf        40485 Aug  1 12:59 vxrouted01
-rw-r--r--   1 thor     rsf        40512 Aug  1 12:59 vxrouted02
-rw-r--r--   1 thor     rsf        40482 Aug  1 12:59 vxrouted03
-rw-r--r--   1 thor     rsf        40472 Aug  1 12:59 vxrouted04
-rw-r--r--   1 thor     rsf        40526 Aug  1 12:59 vxrouted05
-rw-r--r--   1 thor     rsf        40540 Aug  1 12:59 vxrouted06
-rw-r--r--   1 thor     rsf        40552 Aug  1 12:59 vxrouted07
-rw-r--r--   1 thor     rsf        22675 Aug  1 12:59 vxrouted08
-rw-r--r--   1 thor     staff      29720 Aug 28  1991 vxrsh.p1
-rw-r--r--   1 thor     staff      26002 Aug 28  1991 vxrsh.p2
-rw-r--r--   1 thor     staff      13713 Aug 28  1991 vxrsh.p3
-rw-r--r--   1 thor     staff       4702 Jan 16  1992 wdog_class
-rw-r--r--   1 thor     rsf        40860 Aug 22 11:03 xmodem.01
-rw-r--r--   1 thor     rsf        40463 Aug 22 11:03 xmodem.02
-rw-r--r--   1 thor     rsf        40403 Aug 22 11:03 xmodem.03
-rw-r--r--   1 thor     rsf        40451 Aug 22 11:03 xmodem.04
-rw-r--r--   1 thor     rsf        40721 Aug 22 11:03 xmodem.05
-rw-r--r--   1 thor     rsf         9333 Aug 22 11:03 xmodem.06