HDTenEightyP/NetNews huggingface dataset:
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: Re: Supra V.32bis (Disappointment)
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Mon, 13 Apr 1992 01:14:46 GMT

In article <1992Apr12.204056.4062@newshost.lanl.gov> reames@aries.towson.edu (John W. Reames III) writes:
>
>The Macs use a RS 442 port which has not only a Signal Ground and a 
>Protective Ground, but seperate grounds for each data path.. here are
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the pinouts (i think) on the mac serial ports:
>
>    Pin     Signal
>     1       DTR
>     2       DSR
>     3       TxD-
>     4       SG
>     5       RxD-
>     6       TxD+
>     7       DCD
>     8       RxD+
>    Shld     PG
>

OK, enough is enough. This is close, but still contains mis-information.
The Mac serial port is indeed RS-422, which uses differential outputs and
inputs for data transmission. Thus there is a normal pin (+) and an inverting
pin (-) for both transmit data and receive data. This also means that no
reference ground is actually required in the data cable! Apple's implementation
of the RS-422 port sets the data voltages at +5v and -5v so that the signals
can actually interface with RS-232 level devices. The additional signals
are there simply because they are available, and tend to serve multiple
purposes depending on how they are configured. The Mac Plus (and later)
pinouts are:

1	HSKo	Output handshake pin, used as DTR or RTS
2	HSKi	Input handshake pin, used as CTS or as a clock input
			Some terminal programs use it as a DCD input.
3	TxD-	Inverting transmit data, also used for RS-232 TxD
4	Gnd		Signal ground
5	RxD-	Inverted receive data, also used for RS-232 RxD
6	TxD+	Normal transmit data
7	N.C.	Not connected on Mac Plus
	GPi		Multi-use input on Mac II's port A. Either handshake input
			or used as a secondary clock (e.g. for synchronous data)
8	RxD+	Normal receive data

Note that LocalTalk uses TxD+/- to drive the network signals, and RxD+/-
to receive them. GPi is only available on the Modem port of Mac II class
machines. It can be used as DCD input or as a receive data clock in a
synchronous connection. This is similar to the HSKi pin which can be used
as the transmit clock in synchronous mode.

The Input and Output handshake lines can serve many purposes. The Mac's
serial driver allows versatility here, so the program using the driver
can pick and choose the purpose of the pins. Generally, HSKo is used as
DTR, _BUT_ it also may be (and should be) used as a flow control signal,
especially when communicating with devices at higher speeds.

The Mac's serial ports are extremely versatile, and have an excellent serial
driver controlling them in asynchronous mode.

Jack Brindle
ham radio: wa4fib
internet: jackb@mdd.comm.mot.com
AppleLink: BRINCOMM
From: Adam.Frix@p18.f20.n226.z1.FIDONET.ORG (Adam Frix)
Newsgroups: comp.dcom.modems
Subject: Re: Modem clicks Was : Supra v32bis (Initial Review)
Date: Tue, 14 Apr 92 05:30:09 EST
Organization: FidoNet node 1:226/20.18 - cmhGate UF Gateway, Columbus OH


andrew@cubetech.com (Andrew Loewenstern) writes:

AL> Well, clicking is an awfully little thing, and there are plenty 
AL> of excellent, pricey modems that click. Telebits and some 
AL> of the older Hayes modems for instance. However, when you 
AL> pay a lot of money for a good modem like a USR, Telebit, or 
AL> Hayes, you are paying for big things like excellent technical 
AL> support and a generally more compatible modem and not petty 
AL> things like click noise, LED color/shape, etc.... 

I said that the little things like this add up, not that by themselves they
mean a whole lot.  Another example of a little thing:  on my commodity
Goldstar 2400, not only can you hear audible clicking, it goes right on
through to the power line and gets transmitted to the radios throughout my
house, coming right through even on powerful stations.  Just try getting that
weak AM BCB station with all that annoying clicking coming through like a
powerhouse.  But with my USR, everything is sufficiently isolated that when
it's dialing, I don't even know and can't tell even when looking for those
tropical stations.

As they say, few bucks here and there, and you start talking real money. 
Well, the same idea holds for modems.  A few details here and there, and soon
you're talking about a well thought-out modem.  I just think that the new crop
of Supra-like modems will ultimately be like my commodity Goldstar--workable,
but the attention to detail that makes the purchase a pleasant one won't be
there.  I'm waiting to see what the conventional wisdom turns out to be,
because I really want the world to have a cheap v.32bis modem, but if they
turn out to be no better--beyond speed--than the $75 2400 setups, I'll pass,
thanks.

If you seriously thought that clicking when going off-hook would by itself
make or break any modem purchase.....unless one had to sleep next to the darn
thing, of course....

--Adam--
 
--  
Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!20.18!Adam.Frix
INET: Adam.Frix@p18.f20.n226.z1.FIDONET.ORG
Newsgroups: comp.dcom.modems
From: gerg@netcom.com (Greg Andrews)
Subject: Re: Are 16550'a pin compatible with 16450's?
Date: Thu, 09 Apr 92 08:27:19 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <1992Apr8.195056.16953@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes:
>jim@ferkel.ucsb.edu (Jim Lick) writes:
>:
>: For the last point, the software which doesn't know about the 16550 will
>: still benefit, but not as much as one which does.
>: 
>
>No. If the software can't enable the FIFO on the chip, it will act EXACTLY
>like a 16450, with NO improvement at all
>

Not completely true, I'm afraid.  If the software used the more proper
method of checking the Data Ready bit in the Line Status Register and
reading bytes from the UART until that bit turned off, that software
would work better when the buffers are enabled.

Most programs that aren't 16550-aware don't do that.  They simply read a
single byte from the UART and exit.  They certainly won't benefit from
having the buffers enabled.

But there were a few out there that had receive routines that kept reading
from the UART until the UART told them to stop.  Those ones did benefit
when an outside program enabled the buffers for them.  Even though they
didn't have any 16550-specific code.


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
From: adhir@cygnus.umd.edu (Alok Dhir)
Newsgroups: comp.dcom.modems
Subject: Supra v32bis speeds?
Date: 12 Apr 92 23:12:05 GMT
Organization: /etc/organization

I just bought a Supra v32bis FAXmodem...I was just wondering what kind of
speeds you people are seeing from this thing.  With my USRobotics Courier
HST (non v42bis) I used to see about 1650cps regularly when hooked to 
another Courier HST...I have actually seen above 2000 cps with it.  This
was on compressed files (LZH, ZIP, ARC).

With this Supra modem, the most I've gotten is about 1450cps connected to
a 32bis USR Dual Standard.  When I connect to the maiframe at work which
has a v.32 (not bis) v.42bis modem, I get about 1100 cps.  Is this normal?
Or am I doing something wrong?

Also, I didn't buy the fax software they sell with it thinking it probably
sucks and wanting to pick up some good aftermarket fax software for it.
Well, I have no fax software now, and would like to get some if there is
any shareware or freeware fax software available (for both a PC and a Mac,
I use both regularly).

Thanks for any help/hints...

Oh, one final question, does Procomm Plus v2.0 use the 16550 UARTs?

						- Al

Xref: sparky comp.dcom.modems:6396 comp.sys.mac.comm:4504
From: gsnow@clark.edu (Gary Snow)
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
Subject: Re: Supra V.32bis (Disappointment)
Keywords: supra, v.32bis, v32bis, mac, macintosh
Date: 8 Apr 92 15:35:12 GMT
Article-I.D.: clark.1992Apr8.153512.1176
Organization: Clark College, Vancouver, Wa.  USA

In article <1992Apr8.081417.25548@unlv.edu> sknkwrks@unlv.edu (Scott Alfter) writes:
>In article <1992Apr7.180559.10267@clark.edu> gsnow@clark.edu (Gary Snow) writes:
>>In article <1992Apr6.172632.26295@unlv.edu> sknkwrks@unlv.edu (Scott Alfter) writes:
>>>
>>>The Mac's serial ports are brain-dead.  They lack some of the pins...
>>
>>Leave it to a 286 head to take the first shot.  The Macs Serial port has
>>ALL the pins that are necessary for HW Flow Control, you just can't have
>>DTR, but then you don't need to have DTR for dial-up either.
>
>But it would've been just as easy for Apple to stick all the pins in
>there.  If a Super Serial Card for the Apple II (design dates to the
>early 80s) can provide all the port signals, and if every serial board
>out for IBM clones can provide all the signals, why did Apple have to
>cheat on the Mac?

Sure the Super Serial Card provides all the signals, but it also only
has a maximum port speed of 19,200bps.

>Besides, not having DTR can be a pain in the ass if you run a
>BBS...many systems drop carrier by setting DTR low for a second or
>two.  If you don't have DTR, you end up sending +++ followed by ath to
>drop carrier...kludge!

Most people don't run BBS systems, they use their modem for dial-out
devices. But anyway, the +++ATH isn't really a kludge, it works just
fine for a great deal of the systems out there.

Gary

-- 
-----
Gary Snow
uunet!clark!gsnow  or  gsnow@clark.edu
From: des@frogland.inmos.co.uk (David Shepherd)
Newsgroups: comp.dcom.modems
Subject: Re: Moscow modem hunt
Date: 6 Apr 92 12:00:13 GMT
Organization: INMOS architecture group

In article <1992Apr05.184752.24506@slate.mines.colorado.edu>, jgore@Mines.Colorado.Edu (Jacob Gore) writes:
>> Starting from April 1st, the Commercial Service of the Moscow
>> City Telephone Network (Proizvodstvennoe Ob'edinenie MGTS) will
>> detect the unregistered modems. The experts doubt that this
>> action, objectively necessary, can be carried out quickly [...]
>Could someone explain to me why it is "objectively necessary" for modems to be  
>registered with a phone company?

well, now that Russia's a nice free country trying to develop along
capitalist paths i expect the telephone people are looking for ways
of making a quick buck (or should that be rouble) ... finding ways
to make people pay for additional services seems a fairly traditional
way.

given that the moscow telephone system is probably in pretty bad
shape they are obviously trying to limit the number of people
who make large demands on bandwidth my moving large amounts
of data around via modem. by putting up prices/imposing a modem
fee they may help the situation for people who want to use the
phone to talk to people ... this is basically a simple application
of (capitalist) economics ... increase the price to the level that
the market is at the size you can service. Of course this doesn't 
hold if they wish to stick to dangerously socialist ideas like
providing a service etc etc :-)

-- 
--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
		"i speak latin to god,   spanish to men,   french to women 
		 and german to my horse."             - charles v of spain
From: umduddr0@ccu.umanitoba.ca (Brendan Duddridge)
Newsgroups: comp.dcom.modems
Subject: SupraFax v.32bis in Canada yet?
Date: 13 Apr 92 22:35:06 GMT
Organization: University of Manitoba, Winnipeg, Canada

Hi, has anyone in Canada received a SupraFAX v.32bis modem yet?  I can't seem
to get any confirmations as to when we might see them here.  I've heard that
some people in Europe even have them.  Why is it such a problem for us Canuks
to get stuff quickly???  Pissed off...

-- 
Brendan Duddridge
InterNet        : umduddr0@ccu.umanitoba.ca
America Online  : BrendanD1
Newsgroups: comp.dcom.modems
From: res@colnet.uucp (Rob Stampfli)
Subject: Re: Telebit Loyalty pays
Organization: Little to None
Date: Wed, 8 Apr 1992 03:47:36 GMT

>Based on the phenomenal success of "loyalty pays" Telebit is 
>now offering an enhanced promotion called "loyalty pays again".
...
>		"LPA" Models		List Price	"LPA" Price
>		T3000 SA		$949		$499
>		T3000 RM		$899		$489

Note that this new offer does not say anything about the free PEP upgrade.
Is this an oversight, or is the deal not as sweet as before.
-- 
Rob Stampfli, 614-864-9377, res@kd8wk.uucp (Internet), kd8wk@n8jyv.oh (AMPR)
From: cthombor@phobos.d.umn.edu (Clark Thomborson)
Newsgroups: comp.dcom.modems
Subject: Re: v.42bis software
Keywords: v.42bis
Date: 13 Apr 92 17:04:01 GMT
Organization: University of Minnesota, Duluth. Information Services.


> From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
> Is there a public spec for the v.42bis data encoding?

yes, the CCITT standard document should be available by anonymous ftp
from digital.resource.org or bruno.cs.colorado.edu.  Good luck trying
to decipher it well enough to implement it!

> I'm thinking of hacking v.42bis into the CSLIP driver and turning it
> off on the modem.  This should decrease the load on the CPU by quite a
> bit by shedding all that needless I/O.
> 
> The questions are:
> 
>	Is v.42bis licensed software? 

Yes, you'd want to negotiate with the patent holders for a license for
any commercial use, if you didn't want to risk a lawsuit.  You can freely
use V.42bis for your own research and education, however...by which I
understand that you could hack it together for your own edification
and amusement, just don't try to make money out of it.  Even distributing
your code for free to your friends is risky, since this cuts into
the license-holders' ability to make a profit on their invention.
(If you don't agree with my interpretation of U.S. patent law, or if you
believe my interpretation is accurate but don't agree with the law, please
respond to the comp.patents newsgroup, not here.)

I think $40K or $50K (U.S.) is the going price for a modem manufacturer's
license; your implementation would probably be interpreted as a (portion of)
an internal modem, so I wouldn't hold out much hope for a discounted license... 

>	Is there protocol support for switching to v.42bis from a
>	plain ascii connection *after* the connection is established?

Sort of.  Any decent V.42bis modem will switch to "transparent mode"
transmission when the incoming data is incompressible.

Note that you could use any internal compression algorithm, not just V.42bis,
to reduce the CPU-modem bandwidth.  Your scheme has the important advantage
of standardization: anyone with a V.42bis modem can communicate with
your souped-up interface.  On the other hand, if you know a lot about
the data you're transmitting, or if you have CPU cycles or memory
to burn, V.42bis is not the best algorithm.

								Clark

PS: My article on V.42bis modems and ZL compression algorithms has been
accepted for publication in IEEE Micro.  I hope it will appear later this year.
From: jpotter@stsci.edu (Jeffrey J. Potter)
Newsgroups: comp.dcom.modems
Subject: help - is racal-vatic 9600vp any good?
Date: 8 Apr 92 04:18:40 GMT
Organization: Space Telescope Science Institute

just wondering if anyone in netland has any experience with the racal-vatic
9600vp modem?  if so, could you please give me some info on it?  i know of
someone who has one for sale and need to know if it is worth fooling with.


thanks in advance,
jeff potter
jpotter@stsci.edu
From: Jeff.Lindstrom@ofa123.fidonet.org (Jeff Lindstrom)
Newsgroups: comp.dcom.modems
Subject: S4x registers
Date: Tue, 07 Apr 92 12:21:36 PDT
Organization: Universal Electronics Inc. (Public access BBS)

  My Supra V.32bis modem documentation lists the following:

S40 Bit Mapped Option (MNP). Selects compression mode and control options
S41 continuew S40
S46 Compression or Protocol selection
S48 V.42 Negotiation control (can preset if the other modem is known)



--  

Jeff Lindstrom
Internet: Jeff.Lindstrom@ofa123.fidonet.org
Compuserve: >internet:Jeff.Lindstrom@ofa123.fidonet.org
From: Jay.Ashworth@f160.n3603.z1.FIDONET.ORG (Jay Ashworth)
Newsgroups: comp.dcom.modems
Subject: Re: Supra V.32bis FAXmodem
Date: Sat, 11 Apr 92 22:16:00 EDT
Organization: FidoNet node 1:3603/160 - Hacker's Haven, Clearwater FL

In a msg of <Saturday April 11 1992>, rick@nugget.rmNUG.ORG.mu.edu wrote to All:

 >> > Hmmmm, that certainly sounds feasible, and worth a try, but I wouldn't
 >> > purchase a FAX modem just to find out.  If anybody out there has tried
 >> > this please speak up.
 >> This had better be possible, otherwise it almost completely defeats
 >> the purpose of putting a V.32bis/FAX modem on a UNIX machine.

To the best of my recollection, Senator, there's a getty on uunet which answers the phone manually, and which I expect could therefore be hacked into doing this kind of thing.

 >> I don't have access to documentation for the Class 1/2 command set and
 >> I also don't (yet) have such a modem.  I will, however, be getting the
 >> modem soon.  If someone can provide the necessary documentation
 >> (result codes?)  I'll hack netfax to make it work.  I don't feel like
 >> giving up one of my UUCP/modem phone lines just so I can receive
 >> FAXes. Knowhatimeanvern?

Indeed.  The class 1 and 2 command sets include the response messages, I think, so this shouldn't be too hard to find.  I suspect Toby may know the answer to that for sure...?

Cheers,
-- jra

--  
Internet: Jay.Ashworth@f160.n3603.z1.FIDONET.ORG
UUCP: ...!uunet!myrddin!tct!psycho!160!Jay.Ashworth
Note:psycho is a free gateway between Usenet & Fidonet. For info write to
     root@psycho.fidonet.org.
From: albertw@netcom.com (Albert Wong)
Subject: Re: Supra BUSY signaling problem.
Date: Fri, 10 Apr 92 03:58:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <44691@mentor.cc.purdue.edu> huebnere@mentor.cc.purdue.edu (Robert Huebner) writes:
>
>Apparently the problem with BUSY signal detection isn't limited to a 
>preliminary batch as I have a relatively high serial # (1050's).  Also
>contrary to what I've seen before, I am experiencing the problem on a
>standard phone line (residential).  The Supra tech support said they had

I also have a SupraFax V.32bis (SN 14e 001195).  So far, I have been
able to get the BUSY detection to work even when calling through the
company PBX and a local line (when I'm at home).  It seems that the
Supra may be too sensitive when detecting the busy signal.  I have had
a Practical Peripherals missing busy signals when calling across
country.  The busy signal was really faint.  Just another data point.

-- 
+-------------------------------------------------+
| Albert Wong                                     |
| albertw@netcom.com                              |
+-------------------------------------------------+
| "Welcome to the Jusenkyo Spa and Resort Hotel!" |
+-------------------------------------------------+
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
From: epan@jarthur.claremont.edu (Eric C. Pan)
Subject: CTB & ZModem ( was Re: Supra V.32bis (Disappointment) )
Summary: Zmodem is not built-in 
Organization: Pomona College, Claremont, CA 91711
Date: Tue, 7 Apr 1992 23:46:34 GMT

	Nope, Zmodem is not "built-in" to the Communication Toolbox... the
only mention of Zmodem Tool I've seen is from SeaSoft(?) the maker of Zmodem
standalone program for PCs up at Oregan..

					Eric


Newsgroups: comp.dcom.modems
From: jeffp@wsuaix.csc.wsu.edu (Jeff Parke;S10000)
Subject: Re: Supra BUSY signaling problem.
Organization: Washington State University
Date: Fri, 10 Apr 92 23:55:38 GMT

I have had this problem in my original Supra modem and still have it in
the replacement modem Supra sent me.  BTW, they have been very good about
this problem, so far.

The current theory is that there may be something wrong with my phone line.
I have yet to check this modem out on another phone.  I am somewhat skeptical.
This is my home line, and I have used several modems on it with no
problems, including OKITEL 9600, and a Trailblazer Plus.

Supra has written me indicating they think this is a unique problem to me
implying other BUSY detection problems were from foreign lands.

How many Supra v.32bis modems have people seen this on?  It doesn't sound
real rare from what I've been seeing here.
From: bill@bilver.uucp (Bill Vermillion)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit 2500 tutorial
Keywords: We need one
Date: 5 Apr 92 18:08:00 GMT
Organization: W. J. Vermillion - Winter Park, FL

In article <1781@selway.umt.edu> cs000rdw@selway.umt.edu (Richard D Warner) writes:
>
>	We have AT&T 6386's running UNIX SVR3.2, and recently bought a 
>couple T2500's to test out.  Can someone point us to a tutorial that could
>help us get them up and running fast.  There is so much technical material
>to work through, and surely lots of other people have already struggled 
>through it.

To get them running fast turn to page 5.2 of the manual.  Choose which
ever charts fits your needs.  This will work in a large majority of
cases.   

-- 
Bill Vermillion - bill@bilver.uucp 
                - ..!{peora|ge-dab|tous|tarpit}!bilver!bill
Newsgroups: comp.dcom.modems,comp.sys.mac.comm
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.dcom.modems
Subject: pulse dialing (was  Modem clicks)
Date: 8 Apr 92 19:28:29 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <A61203@HB.maus.de>, Mick_Schmidt@hb.maus.de (Mick Schmidt) writes:

|  You're annoyed by the one Click, when the Modem goes off-hook?
|  I wish I could use Tone-Dialing, but I'm still stuck to Pulse-Dialing and
|  that's a nice Click Song on every dial! ;-)

  The reason I have touchtone on my outgoing lines is to avoid premature
modem death. I have had enough trouble with modems dying after a year or
so of making a lot of pulse calls, that I gave up and put touch in for
some lines.

  Does someone have figures for MTBF of those relays based on number of
calls? I had the trouble back in 1980 (or so) on my old PMMI modem and
CP/M system.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.dcom.modems
Subject: Re: 16450 -> 16550a
Date: 9 Apr 92 17:07:25 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <92099.075207SMITHBS@PURCCVM.BITNET>, SMITHBS@PURCCVM.BITNET (Barry Smith) writes:
|  Turns out I have a 16450 in my 486.  How much does a 16550a cost and how
|  hard is it to put in?  If I get an internal 14.4 v.32bis, I don't necessarily
|  have to upgrade the UART, correct?

  Right, the UART is not used internal. Changing the UART is simple in
most cases, just a socketed chip. However, your software has to enable
the FIFO in the chip. Someone was selling 550s for about $10, but I
think $20 is closer to what I've seen lately. Of course the internal
modem may or may not feature buffering, or your software may not use it
correctly... the software has to use the hardware.

  You can probably run 19.2 on one line with no trouble regardless of
what YART you have, I've done 38.4 with a dumb chip and dedicated system.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment