Path: utzoo!utgpu!water!watmath!clyde!rutgers!sdcsvax!ucbvax!PANDA.PANDA.COM!MRC
From: MRC@PANDA.PANDA.COM (Mark Crispin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Where to find... supdup and tn3270 specs
Message-ID: <12367937853.7.MRC@PANDA.PANDA.COM>
Date: 19 Jan 88 22:31:44 GMT
References: <8801182254.AA07198@gmuvax2.gmu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 33

Philip Prindeville -

     I wrote the SUPDUP RFC (RFC 734) 10 years ago.  It doesn't
require any knowledge of PDP-10 assembly language programming,
although it was written in a day when PDP-10 conventions were
more widely understood.  Today, I would probably write it a bit
differently.

    However, it isn't that difficult to understand octal numbers
or even the n,,m format.  n,,m is a way of specifying a 36-bit
quantity, where n is the more significant 18 bits and m is the
least significant 18 bits.  PDP-10's are big-endian, so the number
120,,54 is equivalent to 00012000054 bit is easier to understand.
36-bit quantities are only used in the terminal code registers
sent at startup.  They're sent as 6-bit bytes (in our example, as
00 01 20 00 00 54) and on a byte-oriented machine I'd store them
in the least significant 6 bits of 6 consecutive 8-bit bytes.

     If you bothered to read the RFC, you'd realize that there
are no NCP dependencies at all; the connections are 8-bits.  A
9 and 12-bit character set for keyboard INPUT are possible for
operating systems which swallow them.  The rules for folding
such characters down are well defined in the RFC, and if a
client SUPDUP doesn't want to send such characters it doesn't
have to (all it has to do is not set the bit saying it has such
a keyboard).

     People who have never seen a line of PDP-10 assembly code
have read, understood, and implemented Unix code based on the
SUPDUP RFC.  Give it a try.

-- Mark --
-------