Message-ID: <595@turtlevax.UUCP>
Date: Mon, 19-Nov-84 21:23:00 EST
Article-I.D.: turtleva.595
Posted: Mon Nov 19 21:23:00 1984
Date-Received: Tue, 20-Nov-84 07:30:21 EST
Distribution: net
Organization: CADLINC, Inc. @ Palo Alto, CA
Lines: 15

I just received literature from DEC about their Octal Asynchronous
Receiver Transmitter (OCTART).  Each channel has Transmit Data (TD),
Receive Data (RD), Data Set Ready (DSR), and Data Carrier Detect
(DCD).

Now what good does Data Set Ready (incoming) do without Data Terminal
Ready (outgoing) for full handshaking?  Obviously they designed the
chip to interface to terminals and not other machines.

I would like to see a sister chip with DTR instead of DCD.  Anyone know
what DEC has in mind for the future?
-- 
Ken Turkowski @ CADLINC, Palo Alto (soon Menlo Park), CA
UUCP: {amd,decwrl,flairvax,nsc}!turtlevax!ken
ARPA: turtlevax!ken@DECWRL.ARPA

Message-ID: <602@turtlevax.UUCP>
Date: Sun, 2-Dec-84 12:30:45 EST
Article-I.D.: turtleva.602
Posted: Sun Dec  2 12:30:45 1984
Date-Received: Tue, 4-Dec-84 06:59:58 EST
References: <595@turtlevax.UUCP>
Distribution: net
Organization: CADLINC, Inc. @ Menlo Park, CA
Lines: 110
Xref: watmath net.arch:726 net.micro:8824

> I just received literature from DEC about their Octal Asynchronous
> Receiver Transmitter (OCTART).  Each channel has Transmit Data (TD),
> Receive Data (RD), Data Set Ready (DSR), and Data Carrier Detect
> (DCD).
> 
> Now what good does Data Set Ready (incoming) do without Data Terminal
> Ready (outgoing) for full handshaking?  Obviously they designed the
> chip to interface to terminals and not other machines.
> 
> I would like to see a sister chip with DTR instead of DCD.  Anyone know
> what DEC has in mind for the future?
> -- 
> Ken Turkowski @ CADLINC, Palo Alto (soon Menlo Park), CA

** Here is the response that I received from DEC: **

A friend of mine who knows that I wrote the DEC  "Octal-ART"
specification  has sent me a copy of your comments about the
provision of DTR on this part.  You are  very  correct  that
DTR  is  a necessary signal.  The reason that we did not put
it in is that it requires an additional 8 pins, raising  the
package size from 68 pins to the next size which is 84 pins.
At the time we were doing the design, 84 pin  packages  were
no  where  near  as  common  as  68 pin;  in fact, I believe
that's  still  the  case.   We  did  not  want  someone  not
interested  in  modem control to have to pay the cost of the
much larger package.  We envision that anyone who would like
DTR  (and RTS, etc) would install an 8-bit addressable latch
(74LS259).  If you are using the  DC349  Octal-ART  in  2661
compatibility  mode  (i.e.   not using the interrupt logic),
you can wire the addressable latch to the same  bit  as  the
2661 uses, since Octal-ART uses that as an interrupt enable.
Given that we made DTR require  external  logic,  you  might
ask, "why put in DSR and DCD?".  The reason for this is that
while DTR is a rather dumb function that a latch can do, DSR
and DCD require change detection logic, a good candidate for
LSI implementation - i.  e.  a  really  good  use  of  pins.
Also, operating the chip in 2661 compatibility mode requires
that these signals be within the chip.

By  the  way,  please  don't  say  "Octart";  that's  a  re-
gistered trademark of  Cromemco Corporation  for  an  8-line
serial interface board.  Our product is the DC349 Octal-ART.































































-- 
Ken Turkowski @ CADLINC, Menlo Park, CA
UUCP: {amd,decwrl,flairvax,nsc}!turtlevax!ken
ARPA: turtlevax!ken@DECWRL.ARPA