EPORTS & TB+

[Greg A. Woods]

In article <1990Aug01.164029.3251 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
> Amen. How many years were smart modems around before it was possible
> to dial them reasonably (the \M,\m tokens in Dialers)?  It wouldn't
> have been possible to do this in combination with uugetty before
> the SysVr3 release because an open without O_NDELAY (uugetty's)
> would never complete if another process opened the same port
> with O_NDELAY.

Luckily I missed this period of time.  I was using XENIX, which had
semi-decent bi-directional ports.  (Though if I remember, Sun was the
first to get it right with two devices which didn't need lock files
between getty and uucico.)

> Why doesn't everyone just provide HFC by default, always on?  If you
> connect to a device that doesn't support it, all you have to do is
> loop back the computer's RTS to CTS.  I can make up a custom cable 
> a lot faster than waiting for AT&T to make their software work (Has
> it been 5 years already?).

I knew there was an obvious solution!  I can't quite figure out why
the damn PORTS card didn't have hardware flow control in the first
place.  I thought software flow control went out with 20 mA loop!  :-)

However, I will say that it's nice to have full control over a device
with software, and that goes for HFC too.

Now if only AT&T would provide source for their drivers, and a
development system for those horrid 80186's on the smart-cards, for a
decent price.  Then we could fix our own problems!
-- 
						Greg A. Woods

woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA