HDTenEightyP/NetNews huggingface dataset:
From: bri@pegasus.mit.edu (Brian D. Carlstrom)
Subject: Need Disk Parameters for a MSD-170M Drive
Organization: Massachusetts Institute of Technology
Date: Tue, 8 Sep 1992 03:33:04 GMT

I'm trying to bring a DN3010 back to life that sat on the shelf
for about a year. i need to invol the disk, which is a 170mg 
drive, nodestat -config of a similar machine says its a MSD-170M.
when i run invol on it, it says its unknown disk type 507(?) and
asks if it should read the parameters from the pv label. i say sure
and it fails to read the pv label and asks if i want to manual 
enter the parameters.

What are the parameters of the MSD-170M or where can i find them out?

this drive was running some version SR9.x when it was taken offline
so i assumne the drive is still ok and just needs to be invol'ed to
run SR10.x

-bri

Newsgroups: comp.sys.apollo
From: huston@mksol.dseg.ti.com (william a huston)
Subject: ? sendmail: daemon owner of /usr/spool/mail entries
Organization: Texas Instruments
Date: Wed, 9 Sep 1992 17:50:04 GMT

I've got one for you sendmail gurus:

Yesterday at noon sendmail started (intermittantly!) creating
/usr/spool/mail entries owned by "daemon.daemon.none" instead
if the usual "$USER.mail.none", thus $USER does not have 
rights to read his/her mail. Our administrator is stumped.

Acl on /usr/spool/mail has UP for initial files, owner and group.
Sendmail on gateway is running as root.wheel.none .
Admin says that nothing in the registry has changed. /etc/passwd
files are all 0 length of type "passwd" 

Ideas please! (email if you don't mind). Thanks.

-- 
Bill Huston      214-480-4610 
Texas Instruments (Dallas/Forest Ln), ICC
MSG: ZAPA    email: huston@ap040.csc.ti.com
Newsgroups: comp.sys.apollo
From: hpeyerl@novatel.cuc.ab.ca (Herb Peyerl)
Subject: Re: Strange packaging technique
Organization: "NovAtel Communications Ltd. Calgary, Alberta, Canada"
Date: Fri, 4 Sep 1992 13:29:22 GMT

Mike Kelley (kelley@kelley.nist.gov) wrote:
: In article <1992Sep2.234048.18002@u.washington.edu>, davidb@zeus.ce.washington.edu (David W. Barts) writes: 
: |> The accessory kit box contains two plastic SIMM card guides, a
: |> metal backplane cover, and three machine screws.  These are packed in
: |> -- you guessed it -- a specially-made piece of anti-static bubble
: |> wrap marked "CAUTION:  Contents subject to damage by static
: |> electricity.  DO NOT OPEN except at approved static-free workstations."
: ed by peanuts.  This box contained, most delicately held between two sheets of foam, the software license for a program we had been using for the past two years.

That's cute... On May 24, 1991, I got a letter from HP announcing that
since HP is ranked as a world class leader in support services, they
were enhancing their existing support services by installing a new version
of HP SupportLine...  They go on to describe the various features offered
by the new SupportLine etc... The letter itself is perfectly normal except
that it was sent "Postage Due". I figured if HP couldn't afford postage on
outgoing propoganda, there must be even more problems supplying toilet-
paper in staff washrooms...

--
"I was early to finish | hpeyerl@novatel.cuc.ab.ca <Reply-To>   | I brew |
I was late to start, I | peyerlh@cuug.ab.ca                     | there- | 
might be an adult, but | #define JANITOR "Network Administrator"| fore I | 
I'm a minor at heart." |    JANITOR, NovAtel Communications Ltd.|   AM.  |
From: dma@cs.bham.ac.uk (Denis Martin Anthony)
Newsgroups: comp.sys.apollo
Subject: X Kernel for Apollos
Date: 8 Sep 92 14:14:31 GMT
Organization: School of Computer Science, Birmingham University. Great Britain

I wish to make some Apollo workstations X terminals to a new HP
network. Has anyone out there already done this? Do you perchance have
an X Kernel available?

Any info welcomed.



-- 
Denis
From: bsmith@caldwr.water.ca.gov (Bill Smith)
Newsgroups: comp.sys.apollo
Subject: Re:DSEE and f77 problems
Keywords: DSEE, FORTRAN
Date: 8 Sep 92 20:11:21 GMT
Followup-To: comp.sys.apollo
Distribution: na
Organization: Calif. Dept. of Water Resources, Sac.


I recently posted a query about a problem I was having with the f77
compiler and DSEE.  The problem was basically that the f77 compiler
would not accept both the -c and -o options at the same time at SR 10.3.
The problem has been fixed at SR 10.4 and the f77 compiler WILL accept
both options at the same time which allows my original model to work OK.
I had not switched to SR 10.4 at the time of the problem as I was having
another problem with DDE.  However that too has been fixed by a patch
from HP/Apollo so that I could upgrade my system and fix both problems
at once.

Thanks to the two people who send replys on how to get around the
problem.  Also HP/Apollo  came through for me and gave me the same work
around as well as the tip that the f77 compiler worked at SR 10.4.

Don't you just love a happy ending

Bill Smith
From: philip@cel.cummins.com (Philip D. Pokorny)
Newsgroups: comp.sys.apollo
Subject: Strange program behavior
Date: 9 Sep 92 15:19:33 GMT
Distribution: world
Organization: The Internet

I just ported a new application to the Apollo and it's showing some odd behavior
interacting with the VT100 emulator.  If I don't start the vt100 emulator first,
then the program starts, the screen clears and is replaced with the 'vt100' window
However, no output appears in the vt100 screen.  If I 'cc' the pad, then I can
see that all the output is still being sent to the pad!  However, if I start
vt100 first, and then the program, the output all appears in the vt100 window
correctly.  What would cause this behavior?  I suspect that they aren't using
curses to output the text and thus the output is going to the original output
stream.  Since I know little or nothing about curses on the Apollo or otherwise
I am looking for a quick confirmation of my hypothisis so I can go back to the
vendor with some suggestions on how to fix the problem.

Thanks,

Sincerely,
Philip D. Pokorny
philip@cel.cummins.com
:)

Xref: sparky comp.sys.apollo:3495 comp.sys.ibm.pc.hardware:23758
From: svaldez@sdcc13.ucsd.edu
Newsgroups: comp.sys.apollo,comp.sys.ibm.pc.hardware
Subject: Apollo color monitors = VGA ?
Date: 9 Sep 92 03:31:12 GMT
Article-I.D.: sdcc12.37831
Followup-To: poster


    Does anyone know what the specs are on Apollo color monitors?  I
don't have any exact model numbers so if there are differences
please let me know.  The Apollo large-screen color monitor's that
I used over the summer had the three BNC connectors for the RGB
signal.  I assume then that they are all the same?

    I'm asking because I'd like to try and interface my PC's S-VGA
card with an Apollo monitor if possible.  Would a 15-pin to BNC
cable be all I need?  Could someone with the specs tell me what 
the maximum horiz/verti frequencies, sync, and resolution for these
are?   

    A lot of questions but any kind of help would be very
appreciated!

svaldez@sdcc13.ucsd.edu 
Newsgroups: comp.sys.m68k
From: hrm@engr.ucf.edu (Dr. Harley Myler)
Subject: ECB's wanted
Keywords: Tutor, M68K
Organization: engineering, University of Central Florida, Orlando
Date: Sat, 5 Sep 1992 14:27:50 GMT

Anyone out there with Motorola ECB's that need a good home? We can
fix and we are non-profit (will be used for instruction).


--------------------------------------------------------------------------
Harley R. Myler               "A little learning is a dang'rous thing;
Dept. of Elec. & Comp. Engr.  Drink deep, or taste not the Pierian spring:
Univ. of Central Florida      There shallow draughts intoxicate the brain
Orlando, Florida 32816-0450   And drinking largely sobers us again."
407.823.5098                              -Alexander Pope
Newsgroups: comp.sys.m68k
From: eric@telebit.com (Eric Smith)
Subject: Re: 68060?????
X-Disclaimer: Everything I write is false.
Organization: Telebit Corporation
Date: 15 Sep 92 13:54:02

>>On 15 Sep 92 16:52:11 GMT, green@eniac.seas.upenn.edu (Bradley Green ) said:
> I read in Infoworld that a release of the 68060 was due in late 1993.  
...
> With the delay of Intel's P5, Motorola has a great opportunity to catch
> up here,

Since the P5 is due in 1Q92 a late 93 intro for the 68060 isn't going to do
Motorola much good (IMHO).

> especially with Windows NT due out soon.

How does this help Motorola?  Seems like a hindrance to me, unless Microsoft
has announced WNT for the 68K.

I still think having the part number skip 68050 is a stupid idea.  From
"Our 68000 Line", Motorola literature number BR917/D, Copyright 1990 Motorola,
quoted without permission:

> Future generations of the 68000 family beyond the 68040 are now on the
> drawing board - specifically the 68050 microprocessor.  The 050 will
> continue to deliver on Motorola's promise of offering ever higher
> performance with continued 68000 family compatability.

Sounds to me like one promise they're not keeping (the 050 that is)  :-)
At least they didn't show one of those dumb pictures of a package with "050"
markings added by their graphic arts people, they way they did for all the
parts that were in production.  Are they too ashamed to show real parts in
their marketing literature?  I suppose the pretty pictures are supposed to
appeal to technically illiterate management types, but as an engineer it
offends me.

Eric
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.sys.m68k
Subject: Re: problems with m68882
Keywords: m68882
Date: 9 Sep 92 21:32:14 GMT
Organization: Taniwha Systems Design

In article <92Sep08.184615.11893@acs.ucalgary.ca> norm@enel.ucalgary.ca (Norm Bartley) writes:
>In article <219@F_HOME.ahwau.ahold.nl> leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:

>>I am getting coprocessor protocol violations at random but especially
>>when a lot of interrupts occur (i.e. during disk accesses).
>
>I have had similar problems on my Amiga while trying to add 68882
>support to Amiga Minix. I followed the exact same procedure as you for
>saving/restoring/initializing the 68882 context. I would get coprocessor
>protocol violations at random -- a process might bomb immediately, or it
>might run for a few seconds and then bomb.

This is a common 68k/FPU problem - the CPU can take an interrupt while the
FPU is halfway through an instruction - if your ISR can cause an FP instruction
to occur (even if your compiler generates fmovem.l instructions with null masks
in procedure headers) in an ISR or by causing a process switch, you have to
save the FPU's state and clear it then restore it as you return from the
interrupt.

It's called a coprocessor protocol violation because the FPU thinks it's 
stalled halfway through an instruction and the CPU will feed it a new
instruction before it's done the one it's working on

	Paul


-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P

       "Most American's day to day experience of 'Family Values' is found in
	brightly colored fliers from such organisations as Target and K-Mart."
From: leo@ahwau.ahold.nl (Leo Weppelman)
Newsgroups: comp.sys.m68k
Subject: Re: problems with m68882
Keywords: m68882
Date: 10 Sep 92 14:03:28 GMT

In <92Sep08.184615.11893@acs.ucalgary.ca> norm@enel.ucalgary.ca (Norm Bartley) writes:

>In article <219@F_HOME.ahwau.ahold.nl> leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:
>>I am working on an multi-tasking kernel on my Atari-TT. It contains an
>>68030 main processor and an 68882 coprocessor on 33Mhz.
>>
>>I am getting coprocessor protocol violations at random but especially
>>when a lot of interrupts occur (i.e. during disk accesses).

>I have had similar problems on my Amiga while trying to add 68882
>support to Amiga Minix. I followed the exact same procedure as you for
>saving/restoring/initializing the 68882 context. I would get coprocessor
>protocol violations at random -- a process might bomb immediately, or it
>might run for a few seconds and then bomb.

>I was never been able to resolve this problem. I, too, suspected
>interrupts from various things, but I added code to the kernel to
>catalogue and report all interrupts -- nothing had anything to do
>with the 68882.
I got responses indicating that is was probably a hardware problem
on the first TT series. So I contacted Atari and they confirmed having
the same problem with their Unix V4 implementation. They had a fix for it
and I hope that I can apply it this weekend.
Maybe the Amiga has a simular problem!?
I don't plan to let the problem rest and have a useless coprocessor
in my system.

>Best wishes,
>Norm Bartley, norm@enel.ucalgary.ca

I will post the result of the hardware patch. Thanks to every body who
replied.

To be continued...., Leo.
-- 
Leo Weppelman @ Albert Heijn  bv,          UUCP: ....!hp4nl!leo@ahwau.ahold.nl
Winkelautomatisering                       Internet: leo@ahwau.ahold.nl
Ebbehout 31, 1507 EA Zaandam.              Phone: +31 75 593938 Fax: 351240
Newsgroups: comp.sys.m68k
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: C++ for the 68332 and tools ?
Date: Tue, 8 Sep 1992 12:57:43 GMT
Organization: TH-Darmstadt

In article <james.715393321@ee.uts.EDU.AU> james@ee.uts.edu.au (A. James Boswell) writes:

>   We would also like information on low level development systems. What
>   are people using to control the on chip monitor, etc ?

At "cs.washington.edu" someone made a backend for GDB-3.5 driving the
onchip [micro-coded] monitor. Ask Archie!

best, adams
Newsgroups: comp.sys.m68k
From: seimet@rhrk.uni-kl.de (Uwe Seimet)
Subject: Re: problems with m68882
Keywords: m68882
Organization: University of Kaiserslautern, Germany
Distribution: eunet
Date: Mon, 7 Sep 1992 08:57:09 GMT

leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:

>I am working on an multi-tasking kernel on my Atari-TT. It contains an
>68030 main processor and an 68882 coprocessor on 33Mhz.

>I am getting coprocessor protocol violations at random but especially
>when a lot of interrupts occur (i.e. during disk accesses).

I'm working with the Atari System VR4 on the TT. I encountered a problem
similar to yours when I tried to boot up UNIX the first time. Atari said
there was a problem with some older TT models and a wrongly programmed GAL
that has something to do with the coprocessor. They sent me a plan how to
fix it (easily) and it worked, indeed. So if you have a TT that still has a
daughterboard contact me and tell me the revision number of the board. If it
is the same as in my plan I'll mail it so you can fix it yourself.

***************************************
*        Uwe Seimet                   *
*        seimet@rhrk.uni-kl.de        *
*        seimet@chemie.uni-kl.de      *
*-------------------------------------*
* I really hate this damned machine,  *
*     I wish that they would sell it. *
* It never does that what I mean      *
*     but only what I tell it.        *
***************************************
Newsgroups: comp.sys.m68k
From: norm@enel.ucalgary.ca (Norm Bartley)
Subject: Re: problems with m68882
Date: Tue, 08 Sep 92 18:46:15 GMT
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Keywords: m68882

In article <219@F_HOME.ahwau.ahold.nl> leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:
>I am working on an multi-tasking kernel on my Atari-TT. It contains an
>68030 main processor and an 68882 coprocessor on 33Mhz.
>
>I am getting coprocessor protocol violations at random but especially
>when a lot of interrupts occur (i.e. during disk accesses).

I have had similar problems on my Amiga while trying to add 68882
support to Amiga Minix. I followed the exact same procedure as you for
saving/restoring/initializing the 68882 context. I would get coprocessor
protocol violations at random -- a process might bomb immediately, or it
might run for a few seconds and then bomb.

I was never been able to resolve this problem. I, too, suspected
interrupts from various things, but I added code to the kernel to
catalogue and report all interrupts -- nothing had anything to do
with the 68882.

Best wishes,
Norm Bartley, norm@enel.ucalgary.ca
Newsgroups: comp.sys.m68k
From: kevin@kestrel.kestrel.edu (Kevin Ow-Wing)
Subject: How much is this 68K emulator worth?
Organization: Kestrel Institute, Palo Alto, CA
Distribution: na
Date: Tue, 15 Sep 1992 22:34:51 GMT

I have 2 Applied Microsystems ES1800 series emulators, and I am considering
selling one of them, but I don't know how much they are worth?  Includes
POD for 12Mhz 68000, timestamp module, and logic state analyzer, 256K (or
512K) overlay memory...  About 2-1/2 years ago, we paid ~13,000 to 15,000
dollars.   What's it worht now?  And would any one like to buy one?

Thanks,
Kevin
From: ahansfor@realsoon.wpi.edu (Andrew L. Hansford)
Newsgroups: comp.sys.m68k
Subject: Re: 68060?????
Date: 15 Sep 92 20:45:54
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
NNTP-Posting-Host: realsoon.wpi.edu
In-reply-to: eric@telebit.com's message of 15 Sep 92 17:54:02 GMT

>>>>> On 15 Sep 92 17:54:02 GMT, eric@telebit.com (Eric Smith) said:

eric> Since the P5 is due in 1Q92 a late 93 intro for the 68060 isn't
eric> going to do Motorola much good (IMHO).

Late 93?  Is that shipping first production parts or general
availability?

Motorola is scheduled to talk about the 68060 next month at the
Microprocessors Forum in San Francisco.  Obviously showing some slides
is not a product announcement, but at least they will be there with
something to say. (As will Intel and the P5)

I'm eager to hear some details on the 060.

-- Andrew Hansford
   ahansfor@wpi.wpi.edu
From: leo@ontnix2.ahwau.ahold.nl (Leo Weppelman)
Newsgroups: comp.sys.m68k
Subject: problems with m68882
Keywords: m68882
Date: 4 Sep 92 06:29:49 GMT

I am working on an multi-tasking kernel on my Atari-TT. It contains an
68030 main processor and an 68882 coprocessor on 33Mhz.

I am getting coprocessor protocol violations at random but especially
when a lot of interrupts occur (i.e. during disk accesses).

I added the the following functions to the kernel to support floating
point support:
   - when a process is created, an frestore is performed on a null frame
     (a long value of 0). This should reset the coprocessor for that process.
   - Just before I switch to a new process context, I carry out the following
     instruction sequence:
   	move	#proc_fpu_save, a0
   	fsave (a0)
   	btst	(a0)
   	beq	no_more
   	fmove	fp0-fp7, x(a0) /* I don't know the exact offset */
   	fmove	fpcr/fpiar/fpsr, x2(a0)
     nomore:
   	rts
   - when a process resumes executing, the fpu context is restored with
     code simular to the above code fragment.

Is there somebody out there who can tell me what I am doing wrong here.
I am pretty sure that my kernel code does not use floating point (exept
for the above mentioned fragments).
I don't understand the exact problem I am having. According to the manuals
interrupts shouldn't be a problem.

I also have a second question, the manual (as contained in the 68000 family
reference) says that when handling floating point exeptions I should
sometimes set (or reset) bit 27 of the BUI in the save-context. Does 
anybody know why and when I should set this bit and the location of the
BIU in the saved context.

Thanks in advance, Leo (email: leo@ahwau.ahold.nl)

Newsgroups: comp.sys.m68k
From: floydg@oakhill.sps.mot.com (Floyd Goodrich)
Subject: Re: problems with m68882
Keywords: m68882
Organization: Motorola Inc., Austin Tx.
Date: Wed, 9 Sep 1992 13:28:55 GMT

norm@enel.ucalgary.ca (Norm Bartley) writes:
>leo@ontnix2.ahwau.ahold.nl (Leo Weppelman) writes:
>>I am working on an multi-tasking kernel on my Atari-TT. It contains an
>>68030 main processor and an 68882 coprocessor on 33Mhz.
>>
>>I am getting coprocessor protocol violations at random but especially
>>when a lot of interrupts occur (i.e. during disk accesses).
>
>I have had similar problems on my Amiga while trying to add 68882
>support to Amiga Minix. I followed the exact same procedure as you for
>saving/restoring/initializing the 68882 context. I would get coprocessor
>protocol violations at random -- a process might bomb immediately, or it
>might run for a few seconds and then bomb.
>
>I was never been able to resolve this problem. I, too, suspected
>interrupts from various things, but I added code to the kernel to
>catalogue and report all interrupts -- nothing had anything to do
>with the 68882.

I don't know if this is your problem or not, but a poorly designed
hardware handshake between the 68882 and 68030 can cause spurious
PV.  To determine if it's a HW or SW problem, you may be able to 
slow down the clock and see if it goes away (==> HW problem).  It
sounds like you're doing the right thing in software.  It is important
to do an FSAVE in your ISR prior to executing any F-line instructions.


---
Floyd Goodrich
Motorola 68K Applications
floydg@oakhill.sps.mot.com

Xref: sparky comp.sys.m68k:1103 comp.os.vxworks:809 comp.realtime:1063
From: r2c@icf.hrb.com (Robert J. Cole)
Newsgroups: comp.sys.m68k,comp.os.vxworks,comp.realtime
Subject: 167BUG Diagnostics and VxWorks
Summary: Running 167BUG Diags under VxWorks
Keywords: 167BUG, VxWorks, Diagnostics
Date: 11 Sep 92 13:53:04 GMT
Expires: 1 Oct 92 08:55:11 EST
Followup-To: comp.os.vxworks
Organization: HRB Systems, Inc.


	I am attempting to write c diagnostic routines for the Motorola
167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
board and on power-up, boots and passes control to vxWorks.  167BUG
exists in the first two PROMS and VxWorks in the second set.  VxWorks
boot ok in this configuration.  The intention is to run the user diagnostic 
routines on the 167 board which will make use of the resident Motorola 
diagnostic routines already in ROM, however this effort seems to be rife
with difficulty.	
	
	Has anyone done anything similar to what I am attempting and is
able to offer any advice?
 
Rob Cole.  r2c@icf.hrb.com
From: green@eniac.seas.upenn.edu (Bradley Green )
Newsgroups: comp.sys.m68k
Subject: 68060?????
Date: 15 Sep 92 16:52:11 GMT
Organization: University of Pennsylvania

I read in Infoworld that a release of the 68060 was due in late 1993.  
Any word on what the capabilities/specifications of this chip will be?
With the delay of Intel's P5, Motorola has a great opportunity to catch
up here, especially with Windows NT due out soon.


--
*----------------------------------------------------------------------------*
* Bradley S. Green				University of Pennsylvania   *
* green@eniac.seas.upenn.edu			Dept. Of Systems Engineering *
*----------------------------------------------------------------------------*
From: ted@telematics.com (Ted Goldblatt)
Newsgroups: comp.sys.m68k
Subject: Which type of `040 (was: Re: Which processor? )
Date: 15 Sep 92 16:57:55 GMT
Organization: Telematics Intl., Inc.; Ft. Lauderdale, FL

Along the lines of this thread, I need to be able to distinguish
between a 68040, 68LC040, and (ideally) a 68EC040.

Having determined that the processor is _some_ type of `040 (by
the scheme earlier in this thread), is it reasonable to:

try a FNOP; if it doesn't generate a line-F, I'm a (real :-)) 68040
else try a MOVEC MMUSR,d0; if it doesn't generate an illegal, I'm a
68LC040, else I'm a 68EC040

Is this correct? Is there a better approach (or better choice of
instructions to use)?

Does anyone know why Moto didn't bother to put a configuration 
register into the 68k architecture so you could find these
things out easily?  :-)

Thanx!

ted
-- 
Ted Goldblatt    ted@telematics.com     (305) 351-4367
    Telematics Intl., Inc.   Ft. Lauderdale, FL
Newsgroups: comp.sys.m68k