HDTenEightyP/NetNews huggingface dataset:
From: vancleef@netcom.com (Henry van Cleef)
Subject: Re: Thanks for all who responded
Date: Fri, 04 Sep 92 05:08:28 GMT
Organization: Netcom--posted from Andover, Mass.
Distribution: comp

In article <Bu0Art.Fn4@cs.psu.edu> plu@math.psu.edu (Todo Simpson) writes:
>should have been using /dev/fp021.... When I did this, I was able to


>read the contents of the disk.  (I hadn't been clear on the
>distinction between filesystems and cpio archives; evidently this one
>had a filesystem on it, which was what I expected.)  One respondent
>observed that the Office program uses /mnt to mount the floppy
>filesystem, which should explain why it didn't work: I had deleted
>/mnt because I didn't know what was the point of it and wanted to save
>space.  Now I'm a UNIX system administrator, I ought to be more
>careful....
>
Todd, I am glad things have worked out OK for you.  One of the joys of
owning a Unix PC is that you can learn the ros of Unix system
administration fairly easily with it.  You should be familiar with the
basic file layout of Unix systems---the root directory, /etc /usr /bin
/dev /lib /tmp and /mnt.  Also the use of /usr/local, /usr/ucb (Berkeley
and SysV4).  Virtually all Unix software has religion about those
directories and what's in them.

For systems that load from floppy disks (this includes the 386 PC Unixes
as well as the Unix PC) the first disk with data on it is a minimum file
system.  That is the floppy filesystem in the Unix PC set, N1 in the SCO
sets, etc.  Make a copy of that disk, mount it, and see what's on it.
If you are doing serious administration, you might want to build
yourself a boot and root floppy set so that you can mount the hard disk
and edit and restore basic files.  

Another thing a lot of people forget is that when writing C, what is in
the headers in /usr/include is what's going to compile, and reading your
header set to see what's in them is productive study.  

The 'editor of choice' for your floppy file system will be ed, because
of size.  You'll also want to know yor way around vi, because every Unix
system after system 7 comes with it.  

The Unix PC may be a real antique.  I "play" with SunOS, Ultrix, and SCO
for bread and butter, and have taken a fall or two with AIX.  But the
old Unix PC is a pretty solid and respectable machine, and you can
really learn your way around Unix with it.
-- 
Hank van Cleef---The Union Institute---History of Science and Technology
Unix, X11, networked systems  vancleef@netcom.com, vancleef@tmn.com
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: batteries
Keywords: lithium battery
Date: 4 Sep 92 00:25:53 GMT
Organization: D & D Data

In article <1992Sep2.214628.12005@tc.fluke.COM> vince@tc.fluke.COM (Craig Johnson) writes:
>The original battery installed was a 3V lithium button (or "coin") cell
>with solder tabs.  In later production they changed to a higher

	[ ... ]

>I'm pretty sure the RTC chip is a Toshiba TC8250 and a quick look in a
>data book says the battery voltage can be anything in the range 1.8 -
>5.0V.

	[ ... ]

>Its no big deal.  You can use just about anything.  May as well do what
>you can to keep it cheap and easy to service.

	In this case, the next one that I modify, I will probably put in a
trio of nicads (3.6V total) and a resistor to trickle-charge them from the
system's +5V.

-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <nichols@nvl.army.mil>
	--- Black Holes are where God is dividing by zero ---
Newsgroups: comp.sys.3b1
From: res@colnet.cmhnet.org (Rob Stampfli)
Subject: Re: Lack of libPW.a module
Keywords: libPW PW alloca xmalloc
Organization: Little to None
Date: Tue, 25 Aug 1992 23:50:36 GMT

Here is a version of alloca that I snarfed off the net a few years ago.
I like it because it is specific to the 3B1 and works quite efficiently,
although it looks to me like it sometimes (when the size is a multiple
of 4) allocates more memory then needed.

Save what follows the "===" below in the file alloca.s, and feed it into
cc.
-- 
Rob Stampfli  rob@colnet.cmhnet.org      The neat thing about standards:
614-864-9377  HAM RADIO: kd8wk@n8jyv.oh  There are so many to choose from.
===============================================================================
# This is optimized for the Unix PC, it won't work on some other 68k systems.
# The "and.l &-4" could be changed to "and.l &-2" if you're only running the
# code on the Unix PC.  I use this same code when cross-compiling to a 68020
# system, thus the longword alignment.

	global	alloca
alloca:
	mov.l	(%sp)+,%a0	# pop return addr
	mov.l	(%sp),%d0	# get size argument
	and.l	&-4,%d0		# round size down to long word
	sub.l	%d0,%sp		# allocate by moving stack pointer
	mov.l	%sp,%d0		# return pointer in d0
	lea	-4(%sp),%sp	# allow caller to pop the arg
	jmp	(%a0)		# return

# Alloca relies on the fact that the compiler-generated code in the calling
# function exclusively uses the frame pointer (rather than the stack pointer)
# for accessing stack-relative storage.  Basically, alloca(N) is equivalent
# to (SP -= N), aside from adjusting N to prevent address errors, etc.  The
# result is that the return value points to N bytes of new space on the stack,
# %fp hasn't changed (still points to the local storage) and %sp is set up so
# that future function calls will not touch the allocated area.  When the
# calling function exits, it does an unlk %fp, pointing the stack pointer
# back where it was when the function began, and making the alloca'd area
# free for use again.
# 
# An important limitation of alloca is that it must never be called when the
# compiler has something temporarily on the stack (such as arguments to an
# outer function call, or intermediate results from an outer expression).
# For example, you can't say:
# 
# 	puts(strcpy(alloca(100), string));
# 
# you must do:
# 
# 	char *tmp = alloca(100);
# 	puts(strcpy(tmp, string));
# 
# Generally, alloca must only be called with a simple argument (a constant
# or a single variable) and the return value must be placed directly into a
# variable.
# -- 
# 					-=] Ford [=-
# 
# "The number of Unix installations	(In Real Life:  Mike Ditto)
# has grown to 10, with more expected."	ford@kenobi.cts.com
# - The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
#   2nd Edition, June, 1972.		ditto@cbmvax.commodore.com
Newsgroups: comp.sys.3b1,comp.sys.apollo,comp.sys.atari.st,comp.sys.sequent,comp.unix.aix,comp.unix.amiga,comp.unix.cray,comp.unix.sysv386,comp.unix.ultrix
From: d-lewart@uiuc.edu (Daniel S. Lewart)
Subject: CFV: comp.graphics.gnuplot
Originator: dslg0849@uxa.cso.uiuc.edu
Summary: Approved by tale@uunet.uu.net (David C Lawrence)
Reply-To: gnuplot-vote@uiuc.edu (Gnuplot Vote)
Followup-To: poster
Organization: University of Illinois at Urbana
Date: Tue, 1 Sep 1992 21:37:04 GMT

This is a Call For Votes (CFV) for the comp.graphics.gnuplot newsgroup.
The newsgroup would be unmoderated and its charter is given below.

To vote *for* the creation of comp.graphics.gnuplot, reply to
gnuplot-vote@uiuc.edu with either of the following:
        1) A subject of "Yes"
        2) Text of "I vote for the group comp.graphics.gnuplot".

To vote *against* the creation of comp.graphics.gnuplot, reply to
gnuplot-vote@uiuc.edu with either of the following:
        1) A subject of "No"
        2) Text of "I vote against the group comp.graphics.gnuplot".

The voting period will be from Tue 01 Sep 1992 through Tue 22 Sep 1992.

The document "Guidelines for USENET Group Creation" is available by
anonymous `ftp' to pit-manager.mit.edu (18.172.1.27) as the file
/pub/usenet/news.groups/How_to_Create_a_New_Newsgroup.

Let the vote begin!
Daniel Lewart
d-lewart@uiuc.edu
-------------------------------------------------------------------------------
NAME:   comp.graphics.gnuplot

CHARTER:
1) This group is for the discussion of the GNUPLOT plotting program by
   developers and users.
2) This group will be gatewayed with a mailing list (if someone volunteers
   to maintain it).
3) An FAQ list will be maintained.
4) GNUPLOT is a command-driven interactive function plotting program which:
   a) Plots data or functions
   b) Has been tested on Unix, VMS, MSDOS, MS-Windows, OS/2, Amiga, and
      Atari platforms
   c) Supports many different graphics devices
   d) Is authored by Thomas Williams, Colin Kelley, Russell Lang,
      Dave Kotz, John Campbell, Gershon Elber, and many others
   e) Is not part of the GNU project.

STATUS: Unmoderated
-------------------------------------------------------------------------------
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: Ping for TCP/IP
Keywords: raw ethernet, ping, read, write
Date: 29 Aug 92 00:35:21 GMT
Organization: D and D Data, Vienna Virginia

In article <715021719@macbeth.cs.duke.edu> pusateri@duke.cs.duke.edu (Thomas Pusateri) writes:
>In article <1992Aug28.143120.25887@jhunix.hcf.jhu.edu>
>andy@jhunix.hcf.jhu.edu (Andy Poling) writes:
>>
>>I too spent some time on ping (a long time ago).  My recollection is the

	As have I.  Is there anyone left who hasn't? :-)

>>same - I could never successfully read raw packets.  I don't think the
>>SOCK_RAW socket support is complete...
>
>If we are ever going to solve problems like this, we are going to need either
>a way to recompile the kernel source and put printf statements in it
>or some type of kernel debugger to set break points and print registers
>and assembly code. 

	There is a kernel debugger, I think still in the archives in
OSU-CIS, and there are hooks to it in the 3.51m kernel, if I remember
correctly.  I think that is was simply called kdb, which was also suggested
as meaning "kernel de buggerer" in the wrong hands. :-)

	Another consideration is that access to the kernel sources, when and
if it occurs, may not solve our problems with the ethernet, since the
ethernet is using a loadable device driver from a third party, and *that*
source may not be available to us.

>Even if we can get source some day, it would still be nice to have a kernel
>debugger or monitor. Does anyone at AT&T or convergent know if there are
>any development tools that could be released as well under the possible
>upcoming source agreement? 

	Yes, anything else would be a welcome addition.  I'm not sure how
much use kdb is without the source access, so we know what we're looking at,
instead of guessing, based on the assumption that meaningful names were
squeezed into 8-character variable names.  (At least the earlier versions of
the compiler only kept a limited subset of the variable names as
significant, so that probably is reflected in the kernel code, even if the
most recent parts were compiled with the newer compiler.)  After all, who
goes back and expands variable names in working code? :-)

-- 
Donald Nichols (DoN.)     | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
D&D Data                  |  Email: <dnichols@ceilidh.beartrack.com>
I said it - no one else   |         <nichols@nvl.army.mil>
	--- Black Holes are where God is dividing by zero ---
Newsgroups: comp.sys.3b1
From: elliston@msdrl.com (Keith Elliston)
Subject: newsfeed
Organization: Merck Research Laboratories
Date: Wed, 26 Aug 92 16:49:11 GMT


Hello

I have finally resurrected by old 3b1 (two of them actually), and would like
to get reconnected to the world.  I have (am going to install) HDB UUCP, and 
a telebit t2500 with v.42bis (new roms).  The machine lives in Somerville, NJ,
and would like to be fed Email , comp.sys.3b1 and maybe a couple of rec groups
(like rec.aviation and rec.ham.etc).  Anyone in the neighborhood with
reasonably good feed want to let me poll them?  I would be most appreciative,
and am willing to kick in a bit for the service (but not too much.. after all
I am running a 3b1 :).

Thanks

Keith
elliston@msdrl.com
-- 
Keith O. Elliston            elliston@msdrl.com           uunet!av8tr!elliston
AA5A/U  N9734U             elliston@mbcl.rutgers.edu     elliston@biovax.bitnet
"Beware of pseudo-experts with a mission and a grudge, especially if they are
 lawyers pretending to be scientists." -- H.W. Lewis in 'Technological Risk'
Newsgroups: comp.sys.3b1
From: grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST))
Subject: batteries
Organization: Univ. of MD, Baltimore County
Date: Mon, 31 Aug 1992 03:34:48 GMT

	The PC 7300 has a battery for the clock, right? This
is (I am sure) a faq, but could someone tell me a little about
what is involved. Like what kind of battery, how, where to get it,
etc...
Thanks!

Later,
	Mike
	ZMEG@AACC.bitnet
	or grabenst@umbc3.umbc.edu
Newsgroups: comp.sys.3b1
From: ignatz@chinet.chi.il.us (Dave Ihnat)
Subject: Re: Unixpc source code access
Summary: Riiigggghhhtttt......
Organization: Chinet - Public Access UNIX
Date: Wed, 26 Aug 1992 16:37:36 GMT

In article <1992Aug24.142847.26151@alw.nih.gov> crtb@helix.nih.gov (Chuck Bacon) writes:
>Hey, that's your out!  Send them a letter stating that you have the code,
>and inviting them to name terms to its distribution.  Absence of a response
>is commonly taken to be a sign of assent.

Ayup.  AT&T, and all its lawyers are going to buy that.  From an AT&T employee,
no less.  Riiigggghhhtttt....  Sure thing....
(Hi, Craig...)

		Dave Ihnat
		ignatz@homebru.chi.il.us (preferred return address)
		ignatz@chinet.chi.il.us
From: vince@tc.fluke.COM (Craig Johnson)
Newsgroups: comp.sys.3b1
Subject: Re: batteries
Summary: use cheap alkaline batteries
Keywords: lithium battery
Date: 2 Sep 92 21:46:28 GMT
Article-I.D.: tc.1992Sep2.214628.12005
Organization: John Fluke Mfg. Co., Inc., Everett, WA

The original battery installed was a 3V lithium button (or "coin") cell
with solder tabs.  In later production they changed to a higher
capacity 1/2 AA size lithium with axial leads.  The only thing powered
by the battery is a CMOS real time chip and in actuality the voltage
can vary considerably.  I don't have the schematic in front of me, but
I'm pretty sure the RTC chip is a Toshiba TC8250 and a quick look in a
data book says the battery voltage can be anything in the range 1.8 -
5.0V.

The FAQ suggests looking at Radio Shack for a suitable replacement
lithium cell.  Since the old battery is soldered in, you need to find a
battery with leads or solder tabs unless you choice to install a
battery holder.

I have modified a couple of Unix PCs to use standard alkaline cells.
The first I did several years ago, placing a 2-cell AA holder in the
back between the fans, and running twisted wire up the side of the
machine to the location of the removed dead battery.  This machine has
been running now for about 5 years without the batteries being
changed.  (Incidentally, I'm about to remove that machine from service
because the Seagate ST-251-1 harddrive is worn out.)

The second machine I just worked on recently and I installed the same
configuration of batteries and battery holder except that this time I
used AAA cells instead.

Its no big deal.  You can use just about anything.  May as well do what
you can to keep it cheap and easy to service.

--
	Craig V. Johnson		vince@tc.fluke.com
	John Fluke Mfg. Co.			or
	Everett, WA			...!fluke!vince
From: bdb@becker.GTS.ORG (Bruce Becker)
Newsgroups: comp.sys.3b1
Subject: Re: LAPM and uucp "f" protocol (was: Re: How to run 19,200 (or faster))
Date: 4 Sep 92 03:21:53 GMT
Organization: G. T. S., Toronto, Ontario

In article <1992Aug21.121022.2587@blilly.UUCP> bruce@blilly.UUCP (Bruce Lilly) writes:
|In article <1992Aug18.172747.25332@bwdls61.bnr.ca> clewis@bwdlh118.bnr.ca (Chris Lewis) wrote:
|>And of course, hardware handshaking doesn't work properly on the 3b1.
|>(it works in one direction but not the other).
|
|Hardware flow control works fine in both directions, with tty000
|or EIA/RAM combo boards, at least with 3.51m (probably also with
|stock 3.51, but I doubt if it worked with earlier versions).


	The man page for TERMIO (7) says that the c_cflag
	bit CTSCD controls local hardware flow control:


	"If CTSCD is set, flow control is performed using hardware signals.
	No data will be sent in the absence of the CTS (Clear To Send)
	signal.  Outgoing data will be suspended if CTS is lowered,
	transmission will be resumed after CTS is raised."


	There's no mention of inbound RTS flow control.


	I recall someone who had seen the driver source
	posting that they had observed that inbound flow
	control code was present in the driver, but it
	had been commented out...

	
|Note however, that hardware flow control requires that the
|device connected to the 3B1's RS-232 port *also* support
|hardware flow control in both directions, and that the
|appropriate pins of the 25-pin connector are used for that
|purpose.
|
|At least one modem that I know of does *not* support hardware
|flow control when sending to the CPU, at least in some modes.
|Regardless of the state of RTS, that modem will continue to send
|data to the CPU.


	For uucp use even at 19200 bps the flow
	control seems not to be necessary - when
	the modem interface is locked at 19200
	and the data traffic is at 2400 bps, the
	throughput appears to be the same as when
	the port is running at 2400 bps (unless
	compression or packetising is on of course)


-- 
  ,u,	 Bruce Becker			Toronto, Ontario
a /i/	 Internet: bdb@becker.gts.org	Uucp: ...!web!becker!bdb
 `\o\-e	 "We want the worm, and we want a cow!"
 _< /_	 	- More Jimison, ordering drinks for his table
Newsgroups: comp.sys.3b1
From: lenny@icus.ICUS.COM (Lenny Tropiano)
Subject: For Sale, 512K memory board modified to fit with combo card.
Organization: ICUS Software Systems, Austin, Texas
Distribution: usa
Date: Fri, 28 Aug 1992 22:18:44 GMT

512K ram card, modified to share same space as 1.5MB combo card,
therefore you can get 4MB max without a 2MB board.  Normally this will
not work, unless modified (simple pin cut).  This will work as
512K of extra memory even if you don't have a 2MB board or 1.5MB
card.  This card WILL NOT work in the expansion box.  It will work
in any of the three internal slots.

$50 + shipping (COD cash, cert check, prepaid, etc..)

Let me know if you want this.  This is probably the last of my
3B1 stuff for now.

-L.
-- 
| Lenny Tropiano           ICUS Software Systems        lenny@icus.ICUS.COM |
|               ...!{ames,cs.utexas.edu,pacbell}!icus!lenny                 |
+---------------- 14300 Tandem Blvd #222, Austin, TX 78728 -----------------+
From: vern@zebra.UUCP (Vernon C. Hoxie)
Newsgroups: comp.sys.3b1
Subject: Re: netfax (was: Re: 3b1 internal modem-flow control)
Date: 27 Aug 92 17:41:16 GMT
Reply-To: vern@zebra.UUCP (Vernon C. Hoxie)
Organization: Alpha Science Computer Networks, Denver, Colo.

In article <1992Aug25.213609.7371@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:

.. deletions ..

>
>	If you do feed it through your 3B1, you'll need to set the software
>up to to that checking and refuse a connection to the modem if it is being
>used by the system.  (The lockfiles in /usr/spool/uucp.)  Also, if you are
>using the modem for dial-in to the 3b1, you'll have to turn off the getty on
>that port before the call out, or the program and getty/login will be
>fighting for characters.
>

	I have just posted a revised version of the NBS.timeck program.
The new name is NIST.timechk.

	There is is routine which which manages the
/usr/spool/uucp/LCK..XXXX files appropriately.  Thanks to a suggestion
from Karl Schwartz.

	There is also a section which will remove and restore getty's in
good fashion.  Thanks to code posted by John Milton.

	Please feel free to appropriate whatever parts you might be able
to use elsewhere.

vern

-- 
Vernon C. Hoxie                            {ncar,boulder}!scicom!zebra!vern
3975 W. 29th Ave.                                       voice: 303-477-1780
Denver, Colo., 80212                                     uucp: 303-455-2670
Newsgroups: comp.sys.3b1
From: rwilson@uts.cc.wayne.edu (Ron Wilson)
Subject: Re: Lack of libPW.a module
Keywords: libPW PW alloca xmalloc
Organization: Wayne State University, Detroit Mich.
Date: Fri, 28 Aug 1992 18:44:11 GMT

In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
>In article <1992Aug25.235036.28469@colnet.cmhnet.org> res@colnet.cmhnet.org (Rob Stampfli) writes:
>...
>>===============================================================================
>># This is optimized for the Unix PC, it won't work on some other 68k systems.
>># The "and.l &-4" could be changed to "and.l &-2" if you're only running the
>># code on the Unix PC.  I use this same code when cross-compiling to a 68020
>># system, thus the longword alignment.
>>
>>	global	alloca
>>alloca:
>>	mov.l	(%sp)+,%a0	# pop return addr
>>	mov.l	(%sp),%d0	# get size argument
>>	and.l	&-4,%d0		# round size down to long word
>>	sub.l	%d0,%sp		# allocate by moving stack pointer
>>	mov.l	%sp,%d0		# return pointer in d0
>>	lea	-4(%sp),%sp	# allow caller to pop the arg
>>	jmp	(%a0)		# return
>
>Rob's post mentions that you can't call this alloca() when there's
>something on the stack.  But beware: I believe this aproach also fails
>if you use register variables in your functions: think about how the
>compiler saves and restores the registers.
>
>--> Steve

The problem is NOT that something is on the stack, but rather using this
alloca inside an expression that uses the stack will corrupt the stack.
As for register variables, they shouldn't be affected: Once "you" start
executing code in the BODY ofa function or a block of code - as opposed
to executable code imbedded in the definition section - all of the
variables - including register variables - will be allocated.

As long as you only use alloca() in simple asignment statements - = only,
not even if ((x = alloca(n)) == NULL) - functions using alloca() should
work just fine.
Newsgroups: comp.sys.3b1
From: andy@cs.caltech.edu (Andy Fyfe)
Subject: Re: problems with some files on osu-cis
Organization: California Institute of Technology
Date: Fri, 28 Aug 1992 18:11:32 GMT

In article <1992Aug28.010033.13663@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>In article <1992Aug26.151626.10758@sonyd1.Broadcast.Sony.COM> bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) writes:
>>Some of the files on osu-cis seem to have been mangled.
>>Specifically, in ~/att7300/csvax
>>	perl-bin.tar.Z
>>	perl-man.tar.Z
>>	gnutar.Z
>
>	This sounds like the kind of behavior I have seen when I have
>forgotten to set the binary mode on ftp before the transfer.

The copy of these files on uunet/OSU is bad.  Perhaps the "binary" option
was left off when the files were copied from ftp.cs.caltech.edu (in which
case all of the files in the csvax subdirectory are probably bad).

Connected to ftp.uu.net.
-rw-r--r--  1 81       21         543255 Jul  7 21:13 perl-bin.tar.Z
-rw-r--r--  1 81       21          91838 Jul  7 21:13 perl-man.tar.Z
-rw-r--r--  1 81       21          49665 Jul  7 21:04 gnutar.Z

Connected to archive.cis.ohio-state.edu.
-rw-r--r--  1 5169     274        543255 Jul  8 02:46 perl-bin.tar.Z
-rw-r--r--  1 5169     274         91838 Jul  8 02:46 perl-man.tar.Z
-rw-r--r--  1 5169     274         49665 Jul  8 02:45 gnutar.Z

Connected to ftp.cs.caltech.edu.
-rw-r--r--  1 132      65534      543397 Jun 29 17:07 perl-bin.tar.Z
-rw-r--r--  1 132      1061        91839 Jun 16 17:34 perl-man.tar.Z
-rwxr-xr-x  1 132      1061        49678 Jul  4 19:57 gnutar.Z

Anyway, I believe Dave Brierley is aware of the problem.  Anonymous
ftp users can get a copy from ftp.cs.caltech.edu:pub/3b1.  Unfortunately,
there is no anonymous uucp access to the Caltech machine.

Andy Fyfe						andy@cs.caltech.edu