HDTenEightyP/NetNews huggingface dataset:
From: gst@gnosys.svle.ma.us (Gary S. Trujillo)
Subject: Re: LAPM and uucp "f" protocol (was: Re: How to run 19,200 (or faster))
Date: Wed, 26 Aug 1992 18:04:51 GMT

In <1992Aug21.121022.2587@blilly.UUCP> bruce@blilly.UUCP (Bruce Lilly) writes:

>...
>
> Many devices claiming to have RS-232 ports do not use the
> correct pins for hardware flow control. Printers in particular
> tend to use bizarre flow control methods...

I found a good discussion of this whole subject in a book I got at Rat Shack
a few years ago: _Understanding Data Communications_ by Friend, Fike, Baker,
and Bellamy (EEs all, three of the four with PhDs) - Howard Sams & Co., 1984
(quoting from 1987 edition), no ISBN number apparent.  In section four on
"Asynchronous Modems and Interfaces" the book has a few pages dedicated to
talking about flow control, and one subheading entitled "Non-standard Use of
a Standard" which talks about how RS-232C signal lines are used by printer
and other peripheral manufacturers in strange ways.  The problem, they claim,
is that "The RS-232C and other standards are intended to define the interface
between DTEs and DCEs for communications over networks, usually telephone
facilities.  They don't address the idea of using the interface as a general
serial input/output port..."  They talk about the tradeoffs involved with
using RTS and CTS for flow control as compared with using DTR and DSR, versus
in-band (XON/XOFF) signalling - and even stranger schemes, such as using DSR
and the RD line (XON/XOFF).  I find this whole section of the book pretty
interesting, actually - but then I don't know that much about hardware, so
it doesn't take much to impress me, I guess.  :-)

Gary
--
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst
From: tkacik@hobbes.hobbes.cs.gmr.com (Tom Tkacik)
Newsgroups: comp.sys.3b1
Subject: Re: Lack of libPW.a module
Date: 3 Sep 92 11:54:45 GMT
Reply-To: tkacik@hobbes.hobbes.cs.gmr.com
Organization: GM Research Labs

In article 4632@digibd.com, steve@digibd.com (Steve Wahl writes:
> I don't think anyone understands me yet.  First, some context.
> 
> In article <1992Aug29.052011.24352@colnet.cmhnet.org> res@colnet.cmhnet.org (Rob Stampfli) writes:
> >In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
> >[ alloca.s code deleted ]
> >>
> >>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.

All passed parameters and local variables will be ahead of the alloca'd
space, and will be accessed via the frame pointer (%a6) rather than the
stack pointer (%sp aka %a7).  Only temporary variables are accessed via
the stack pointer.

Register variables are ok, as they will be saved before the alloca.  The stack
will be clear.  The only problem is using alloca in an expression.
Never do something like   char *c; c=i*(j+alloca(10))
Any temporaries that are put on the stack for this expression are accessed via
the stack pointer, and will be corrupted.

Also, note that this alloca is non-reentrant.  Do not do c=alloca(alloca(10)).
This one is guarenteed not to work.

> Yes, but the problem is in what is restored by the called function...

No, that is not a problem.  The unlink instruction will return everything to
normal when the routine ends.


An example is given (most of which is now deleted):
> f2()
> {
> 	register int b;
> 	char *p;
> 
> 	b = 7;
> 	p = alloca(10);
> 	return(b);
> }

And the approximate assembly code:

> f2:
> 	link.l	%a6,-4		# create stack frame
> 	mov.l	%d2,-(%sp)	# save regsiter variable
> 	mov.l	&7,%d2		# set b to 5
> 	pea.l	10		# parameter to alloca
> 	bsr	alloca		# call alloca
> 	add.w	&4,%sp		# pop argument to alloca
> 	mov.l	$d0,-4(%a6)	# store alloca return in p
> 	mov.l	%d2,%d0		# return value
> 	mov.l	(%sp)+,%d2	# restore register variable **************	
> 	unlk	%a6		# remove stack frame
> 	rts

All of the saved parameters, passed parameters, and local variables are accessed
via the frame pointer, not the stack pointer.  Your line marked "**************"
should use %a6.  (Actually, what will happen is the link instruction is given
a mask telling it which registers to save.  Neither your save %d2, nor restore %d2
will be generated by the compiler.  The Unlink instruction will restore the
proper registers from the stack, again using %a6 not %sp.)

Everything will work out just fine.  The Unlink will also restore the stack
pointer to its proper value before calling alloca.

> Anyone disagree with my analysis?

Yes.

Tom Tkacik
GM Research Labs
tkacik@hobbes.cs.gmr.com
tkacik@kyzyl.mi.org

Xref: sparky comp.sys.3b1:3208 comp.sys.att:2089 comp.lang.ada:2444
From: dburr@sbphy.physics.ucsb.edu (Donald Burr)
Newsgroups: comp.sys.3b1,comp.sys.att,comp.lang.ada
Subject: Ada/ED for AT&T 7300 UNIX PC?
Date: 26 Aug 92 04:43:08 GMT
Followup-To: comp.sys.3b1

Hi.  I am taking an ADA class this fall, and so I went to the ftp site
in new York (?) and got the code for ADA/ed, an public implementation of
the ADa language.

Unfortunately, i have not been able to compile it on my machine, an AT&T
UNIX PC (PC7300)  This runs System V Release 2 UNIX.  gcc barfs with
numerous errors, and sometimes runs out of virtual memory. (ugh)

If you have ADA/ed compiled for this particular machine, or if you can
do this, I would greatly appreciate it if you could send me binaries,
and/or altered source (altered so that it will compile right)  Binaries
would be preferred, though.

Anyway, please send mail to dburr@sbphy.physics.ucsb.edu.  Class starts
this Thursday, so I am pretty desperate.  (Well, I suppose that as long
as it is within 2-3 weeks, it would be OK.  Usually we don't do anything
of earth-shattering importance in those first weeks.)

THANK YOU!!

--
: Donald Burr, Coordinator          : dburr@sbphy.physics.ucsb.edu   INTERNET :
: Santa Barbara Area Network(SBANET): dburr@gnu.ai.mit.edu (Backup)  ======== :
: Santa Barbara, CA  USA            : DonaldBurr@aol.com (AOL gateway)        :
: uunet!dsc.com!dschub!sbanet!dburr : America OnLine: DonaldBurr              :
Xref: sparky comp.sys.3b1:3237 biz.comp.telebit:862
From: kls@ditka.Chicago.COM (Karl Swartz)
Newsgroups: comp.sys.3b1,biz.comp.telebit
Subject: WorldBlazer on 3B1 (aka UNIX PC)
Date: 30 Aug 92 08:43:56 GMT
Organization: Chicago Software Works, Menlo Park, California

I know someone mentioned something about the Telebit WorldBlazer on
a 3B1 recently but I didn't think I had a problem since my T3000 had
been working just fine.  My WorldBlazer upgrade ROMs finally arrived
yesterday and now I find that I do have a problem.  It was actually
there all along but without PEP the T3000 was only marginally useful
to me so I had it on my voice line, dialout only.

The problem comes when I turn the getty on.  As soon as I try to go
out via the modem the getty starts echoing the modem's responses to
cu/uucico and a shouting match ensues.  There is a correct lock for
the outgoing program but uugetty seems to be ignoring it.

The WorldBlazer configuration I'm using is essentially the builtin
one for HDB UUCP (which I'm running), set by AT&F3&W0.  I was using
a few modified registers but nothing that should have any effect, and
reverting to exactly what &F3 gives didn't help any.

The Devices entry for the line is

    Direct	tty001,M -	Any		wbdir
    Direct	tty001,M -	9600		wbdir

and Dialers has

    wbdir	=W-,	"" \M

There's other stuff, of course, but the problem can be simply
triggered by

    $ cu -s 9600 -l tty001
    Connected
    AT&V

The response from the AT&V starts the battle nicely.

Meanwhile, my old TrailBlazer Plus, with a very similar configuration
and identical Devices/Dialers entries, continues to work just fine as
it has for years.  BTW, the 3B1 is running 3.51m and HDB uucp.

Any ideas?

-- 
Karl Swartz	|INet	kls@ditka.chicago.com
1-415/854-3409	|UUCP	uunet!decwrl!ditka!kls
		|Snail	2144 Sand Hill Rd., Menlo Park CA 94025, USA
"Unix is a fractal thicket." (Mark Barnett)
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: Sat, 29 Aug 1992 05:20:11 GMT

In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
[ alloca.s code deleted ]
>
>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.
>

Register variables are not saved prior to calling a function, but rather are
saved and restored by the called function, and then only if the register is
needed therein.  This is true of both the stock cc and gcc compilers for the
3B1.  The alloca function I posted uses only those register variables that
are defined to be scratch variables by the compilers, so there is no need
for it to save %d0 or %a0.  (In fact, this function doesn't really set up a
standard 'C' stack frame for itself -- since it is so simple and calls no
one, it uses an efficient, but externally equivalent alternative.)

Just to be on the safe side, I wrote a small program that called alloca()
and did a "cc -S" on it, examining the results to make sure I wasn't missing
something obvious.  I couldn't detect any problems.  To be fair, I usually
use gcc and their built-in __builtin_alloca function, but I have made some
use of the supplied function, and I've never experienced a problem with it.
I would certainly like to know if someone can provide an example where it
fails.

I must also reiterate that this version of alloca(), which I previously
posted, is not my work, but was written by Mike Ditto, as posted to the
3B1 newsgroup some time ago.
-- 
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.
From: sandy47@cats.ucsc.edu
Newsgroups: comp.sys.3b1
Subject: 3.51 Set, Develop. Set and Manuals For Sale
Date: 31 Aug 92 03:39:45 GMT
Distribution: usa
Organization: University of California; Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


I've picked up a few sets of manuals and software with some purchases
over the last few years and I know that you've been wanting some of them
to round out your collection, so here's your chance.
---

Disks:
=====
(all are on original AT&T floppy disks in AT&T red binders)

AT&T System V Version 3.51 Operating System	$75
AT&T System V Version 3.51 Development Set	$75

(Also available:  disks only for BASIC, Pascal, FORTRAN and others.
send email for list:  mack@mchome.santa-cruz.ca.us )
---

Manuals:
=======
(all are original AT&T red manuals in like new condition)

Title			     Qty. Avail.       Price
----------------------------------------------------
GSS-Terminal (with software)	1		$30
Virtual Device Interface	6		$15
User's Manual 			1		$30
User's Manual I			2		$20*
User's Manual II		2		$30*
Programmer's Guide		2		$30*
Owner's Manual 	(+ disks)	5		$20*
Communications Mgmt. (+ disks)	3+1		$35*
Getting Started			4+1		$15*
7300 Owner's Manual		1		$15
System Software Install		3		$5*
GSS-Drivers			3		$5*
Quick Guide-Owner's Man.	3		$5*
Quick Guide-Managing		2		$5*
Quick Guide-Remote Acc.		2		$5*
Quick Guide-Tel. Mgr.		2		$5*

* denotes manuals comprising "complete set"
+ denotes additional qty. of 7300 only manuals
---

ALL items require additional money for shipping - shipping costs are
not negotiable.  NO CODS.  Money order or cashier's check for no-delay
shipping, personal checks ok with delay for clearing.

I'll consider offers where 3 or more manuals are involved.


				Larry

Larry McElhiney
c/o Plantronics
345 Encinal St.
Santa Cruz,  CA
95060

(408) 426-5858 x358 (W)
(408) 475-8027 (H)

mack@mchome.santa-cruz.ca.us
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: batteries
Date: 31 Aug 92 22:59:02 GMT
Organization: D & D Data

In article <1992Aug31.033448.23464@umbc3.umbc.edu> grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST)) writes:
>
>	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...

	The battery, at least in the 7300 that I got, is soldered into the
main board, perhaps half-way back the left side (viewing the machine from
the front).  This requres almost complete dissassembly, especially if you
desire to unsolder from the bottom of the board, which is the best way.

	The battery is a 3V lithium cell.  It has leads affixed to the cell,
and while it can be replaced with a similar battery, what I reccomend is
replacing it with a holder for the coin-style batteries.  The ones commonly
used for clock chips in XT-class machines will work quite well, and the pin
spacing on the holders (at least those which I got) matches the holes on the
CPU board.  Once this has been done, you need only open the case, remove the
power-supply cable and the three screws at the front, lift the top plate,
slide out the old battery, and slide in a replacement.  I have been running
for several years on a single replacement, so far.  The other machines don't
need replacements yet (or if they do, they get their time set over the net
from one of the Suns before it becomes obvious).

	You should dig into the FAQ for instructions on how to open the
case, and what to be careful about.  Really, you should keep a printed copy
somewhere with the machine documentation, unless you can answer all of the
questions from the top of your head. :-) (Actually, a machine-readable copy
on another machine will do.)

	Good Luck
		DoN.

-- 
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,biz.comp.telebit
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: WorldBlazer on 3B1 (aka UNIX PC)
Organization: Bruce Lilly
Date: Wed, 2 Sep 92 23:13:43 GMT

In article <1992Aug30.084356.16529@ditka.Chicago.COM> kls@ditka.Chicago.COM (Karl Swartz) wrote:
>The problem comes when I turn the getty on.  As soon as I try to go
>out via the modem the getty starts echoing the modem's responses to
>cu/uucico and a shouting match ensues.  There is a correct lock for
>the outgoing program but uugetty seems to be ignoring it.

Make sure that the device name used for uugetty (look at the
``line'' arg of the uugetty line in /etc/inittab) is the same as
the device name known to UUCP (check field 2 of the appropriate
line in /usr/lib/uucp/Devices (modulo any overrides in
/usr/lib/uucp/Sysfiles)).  For example if you link /dev/tty000
to /dev/modem, make sure you use either "tty000" or "modem" in
*both* places.

Also, what other flags if any are you using with uugetty?
-r and -t20 (or some other suitable timeout value) might help.

During the cu/uucico call, there should be a lock file in
/usr/spool/uucp named LCK..foo, where "foo" is the device name
which is known to both uugetty and to the UUCP programs (via
Devices). Using HDB UUCP, the lock file should contain the
process id of the process which created the lock file (cu or
uucico) as an integer, followed by a newline character, i.e. the
file size should be 5 bytes (some of the older programs, such as
the phone manager, use a different format). You can examine the
lock file as shown in the example below:

od -dc /usr/spool/uucp/LCK..dsi
0000000   00000   06318   02560
	 \0  \0 030 256  \n  \0
0000005

In this case, there was a cu process, pid 6318. "dsi" is the
mnemonic device name known to uugetty and to the UUCP package:

grep dsi /etc/inittab /usr/lib/uucp/Devices

/etc/inittab: dsi::respawn:/usr/lib/uucp/uugetty -r -t20 dsi 9600DSI
/usr/lib/uucp/Devices:Direct dsi,M - Any direct
/usr/lib/uucp/Devices:ACU dsi,M - 9600 dsi \T

(The "Direct" entry in Devices is used for talking directly to
the modem using cu; the "ACU" entry is used by cu and uucico)

ls -l /dev/tty002 /dev/dsi

crw-rw-rw-   2 uucp     uucp       0,   3 Sep  2 18:45 /dev/dsi
crw-rw-rw-   2 uucp     uucp       0,   3 Sep  2 18:45 /dev/tty002

(Note that the device file(s) must be owned by uucp, and both
cu and uucico must be owned by and suid to uucp.)

>The Devices entry for the line is
>
>    Direct	tty001,M -	Any		wbdir
>    Direct	tty001,M -	9600		wbdir

You might be better off using "ACU", rather than "Direct"
(field one in Devices, and field three in Systems); in some
versions of HDB UUCP it does make a difference, though the 3B1
version would seem to regard only "PC7300" and "STARLAN" as
magic incantations. Make sure uugetty is using "tty001".

>There's other stuff, of course, but the problem can be simply
>triggered by
>
>    $ cu -s 9600 -l tty001
>    Connected
>    AT&V

Try adding a -d flag to cu to see a bit more of what's
happening.

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce
From: tkacik@hobbes.hobbes.cs.gmr.com (Tom Tkacik)
Newsgroups: comp.sys.3b1
Subject: Re: Lack of libPW.a module
Date: 3 Sep 92 12:01:35 GMT
Reply-To: tkacik@hobbes.hobbes.cs.gmr.com
Organization: GM Research Labs

> >In article <1992Aug27.213851.20578@digibd.com> steve@digibd.com (Steve Wahl) writes:
> >[ alloca.s code deleted ]
> >>
> >>Rob's post mentions that you can't call this alloca() when there's
> >>something on the stack.

Note that there is a portable alloca (I believe written by Doug Gwyn), that does
not save the alloca'd space on the stack.  It uses calls to malloc to get space,
and frees up old space every time alloca is called again.  There are no
worries about trashing the stack.  I do believe that it is still nonreentrant
though.

Always use alloca delicately.  Actually, never use alloca and all
will be right with the world.  The only reason to have alloca is that there
are those who write the GNU stuff that seem to love it, and if you wish
to use their code you need it.  (Personally, I wish that they would just stop
using it.)   

Tom Tkacik
GM Research Labs
tkacik@hobbes.cs.gmr.com
tkacik@kyzyl.mi.org
From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: problems with some files on osu-cis
Date: 28 Aug 92 01:00:33 GMT
Organization: D and D Data, Vienna Virginia

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
>		and
>	perl-man.tar.Z
>		both cannot be un-tar'ed due to a ``directory 
>		checksum error''.  The part that comes out

	[ ... ]

>		dumps core due to an Illegal instruction.
>	gnutar.Z
>		fills up the disk when uncompressed. I had to stop

	[ ... ]

	This sounds like the kind of behavior I have seen when I have
forgotten to set the binary mode on ftp before the transfer.  Also when
trying to uncompress (on a BBN C-70) a file which had been compressed on the
same BBS C-70.  The problem there is that the C-70 has 10-bit bytes, so
compress produces at best wierd files, and at most, disk-fillers.

>Could the person responsible for maintaining the osu-cis archives
>please look into this and post to the net when the problems have
>been resolved.  Thanks in advance.

	If you got these by uucp, this isn't relevant, but if you got them
by ftp, have you checked that they were transferred to you with the binary
mode set?  You probably know enough to know that it must be set, but it is
possible when in a hurry to forget to do so.  I have done it often enough
that I usually catch myself and throw away the file and re-start
transmission before I 'bye' off, but occasionally one slips through.  You
should grab the smaller one again, and compare checksums before being sure
that the files on the server site are munged.  (You may have already done
this, and just neglected to mention it.)

	I post instead of e-mail this in case others are encountering the
same problems and just haven't posted.

	Good Luck
		DoN.
-- 
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: andy@cs.caltech.edu (Andy Fyfe)
Subject: Re: netfax (was: Re: 3b1 internal modem-flow control)
Organization: California Institute of Technology
Date: Tue, 1 Sep 1992 21:03:03 GMT

For sending the occasional fax, where one is willing to do a bit more work,
one might try something like the following.  This is *not* for unattended
use!!!

First get the fax pages in separate files.  gs can do this:
    gs -dNOPAUSE -sDEVICE=dfaxhigh -sOutputFile=/tmp/fax.%d file.ps quit.ps
(or device dfaxlow for 100 lines/inch).

Then, let kermit do the talking to the modem.  One should do more
sophisticated error checking, of course, but....  Anyone want to try it?

Receiving is left as an exercise for the reader.  :-)

    def getinput -
      input 7 \%1, -
      if failure stop 1 Failed to get \%1

    def sendpage -
      output AT+FDT\13, -
      getinput CONNECT, -
      getinput \21, -			     <-- <XON>
      transmit \%1, -
      output \20\3, -			     <-- <DLE><ETX>
      getinput OK, -
      output AT+FET=\%2, -
      getinput OK
      
    set modem direct
    set line /dev/tty000
    set speed 19200

    output ATZ\13
    getinput OK
    output AT+FCLASS=2 +FLID="123-4567"\13   <-- whatever init string you need
    getinput OK
    output ATDT 765-4321\13
    getinput +FCON
    getinput OK

    sendpage /tmp/fax.0 0
    sendpage /tmp/fax.1 0
    sendpage /tmp/fax.2 0
    sendpage /tmp/fax.3 2		     <-- last page

    getinput +FHNG
    getinput OK

Andy Fyfe						andy@cs.caltech.edu
From: andy@cs.caltech.edu (Andy Fyfe)
Subject: Re: problems with some files on osu-cis (and gcc 1.40 bug)
Organization: California Institute of Technology
Date: Wed, 2 Sep 1992 00:25:01 GMT

In article <1992Aug31.232858.1963@blilly.UUCP> bruce@blilly.UUCP (Bruce Lilly) writes:
>In article <1992Aug28.181132.11130@cco.caltech.edu> andy@cs.caltech.edu (Andy Fyfe) wrote:
>>  Unfortunately,
>>there is no anonymous uucp access to the Caltech machine.
>
>Any plans to change that?  Is there anonymous uucp access to a machine
>that has the ftp'able files [NR]FS-mounted?

No.  What little uucp remains, within the CS department anyway, (a single
line, 2400 baud) is kept begrudgingly.

>do you plan
>to make a binary of 1.41 available after its release?

Since it was relatively easy, I cross compiled gcc 1.41.  Anyone who
wants it will have to link the .o files him or herself.  Since it was
cross compiled with gcc 2.2.2, you will need the gcc 2.x version of
libgcc.a, not the 1.x version gcc-gnulib, that is (more or less),
	$ gcc -o cc1 *.o libgcc.a
or
	$ ld -o cc1 *.o -lc libgcc.a
If you have gcc 2.x installed, then use it to do the linking.  libgcc.a
can be created from libgcc[12].tar.Z in the directory gcc2-objects
(see the README in that directory for details) or can be extracted from
gcc2-bin.tar.Z.  The details are in the README file in the directory
pub/3b1/gcc-1.41/ on ftp.cs.caltech.edu.  (I haven't actually tried this,
by the way.  And won't.  :-))

Andy Fyfe						andy@cs.caltech.edu
Newsgroups: comp.sys.3b1