21

The contract to develop ARPANET, the first version of the Internet, was awarded in 1969; usage of the system expanded exponentially through the seventies.

The size and format of ARPANET packets were specified in terms of octets (8-bit bytes): http://mercury.lcs.mit.edu/~jnc/tech/arpanet.html

However, at that time, the world had not yet settled on octets. Though the Honeywell used as the first IMP was a 16-bit computer, e.g. DEC was still selling 18/36-bit mainframes until 1983.

Given a pair of PDP-10s trying to send native binary data to each other over the ARPANET, how did they go about formatting it for transmission?

Improve this question
16
  • 2
    Unisys too - I used a Univac 1100 series at University of MD for a few courses in the early 1980s. Big innovation (which I used but most of my class didn't) was to use Mixed case text in the Assembler...
    – manassehkatz-Moving 2 Codidact
    Dec 18, 2019 at 23:42
  • 3
    PDP-10 had instructions to treat any quantity from 0 to 36 bits as a 'byte'. But apart from that, there are pretty much always shift and mask instructions on any computer.
    – another-dave
    Dec 19, 2019 at 1:34
  • 3
    Here's a partial answer to how the 36-bit words in memory are serialized into 8 bits for transmission, in other words, how htonl() works on a UNIVAC 1100: stackoverflow.com/a/38675086/966071
    – snips-n-snails
    Dec 19, 2019 at 19:30
  • 2
    @UncleBod - but ASCII is a 7-bit code! (I am quite sure of that, since there are 5 ASCII characters in a PDP-10 word)
    – another-dave
    Dec 19, 2019 at 23:30
  • 2
    The IMP interfaces used on the MIT PDP-10s could operate in both 36-bit and 32-bit mode. The latter left four bits unused in a 36-bit word. Both modes were used depending on what was convenient. The 1822 IMP messages were specified as bit streams.
    – Lars Brinkhoff
    Jan 16, 2020 at 11:15

3 Answers 3

Reset to default
16

However, at that time, the world had not yet settled on octets.

I beg to differ. If you look through brochures and manuals of next to all manufacturers, they tried hard to be IBM compatible at least for data exchange. Being IBM compatible was effectively mandatory for the whole industry and with the /360 introduction in 1964 the size of a byte (for interchange) was settled at holding 8 bits.

Given a pair of PDP-10s trying to send native binary data to each other over the ARPANET, how did they go about formatting it for transmission?

The PDP-10 was quite capable to handle 8 bit data streams as well as peripherals. Its standard punchtape, the PC04, was 8 bit, and quite capable of loading binary data.

While I do not remember the PDP-11 binary tape format, I would assume it was not much different from the way a PDP-8 or 12 handled a binary paper tape on a PC05 (also 8 bits wide). Her a PAL/MACRO-8 binary tape stored 6 bits per character, with using the the high bits as markers. A loadertape looked like this:

  • 10.000.000 marking the start
  • 10.xxx.xxx denoted the upper half of a loading address followed by
  • 00.xxx.xxx with the lower half of the loading address

All following pairs of bytes with zero in the top two bits were decoded as words, until either another address was set (starting with 10), or a final mark (10.000.000) was read. If a final mark was detected. In this case the_last_ word read isn't data, but a 12 bit checksum of the 6 bit (!) values (including the loading address) read.

AFAIR if both bits are set, it addressed the field (memory block) the data had to be stored in. It had to come prior to any loader address and had the lower bits always set to zero to avoid generating a rubout - which was used to eliminate data.

Improve this answer
13

ARPANET isn't the only context in which the world of PDP-10 computing ran into data paths that used octets for framing. Four other contexts come to mind: 9 track magnetic tape, PDP-11 file exchanges, DECnet, and Kermit.

9 Track Magnetic Tape. 9 Track tape rapidly became the most popular standard as IBM transitioned from 36 bit processors to the 360. PDP-10 installations used 9 Tracks for backing up disks, and also for reading and writing tapes to be used with a 360 or other mainframes. 9 track tapes had one track for a parity bit, and an octet of data per frame.

PDP-11 file exchange. Many sites ended up with one or more PDP-11s sharing a data center with a PDP-10. There were a variety of needs to share native mode data, and a variety of encoding schemes to accommodate octets and 36 bit words.

DECnet. DECnet, like ARPANET, was built around octets. In this context, you might want to find Technical Aspects of Data Communications (1988 3rd ed) by John E McNamara. It's got a good writeup of the issues leading up to DECnet, especially DDCMP.

Kermit. One of the first implementations of Kermit was for the PDP-10. The Desktop computers that used Kermit were all octet oriented. Here the issue was somewhat reversed. Kermit could store a file made up of octets on a PDP-10 and return it to a desktop undamaged. Seems trivial today, but there were a number of contemporaneous tools that could only manage ASCII files.

Exploring these other contexts will give you additional handles on how people accustomed to 36 bit words adapted to octets.

Improve this answer
7
  • 1
    "Seems trivial today"? Does that mean that Windows FTP has finally switched to transferring files in binary mode by default?
    – Mark
    Dec 19, 2019 at 20:52
  • 1
    That's not what I was trying to say.
    – Walter Mitty
    Dec 19, 2019 at 23:11
  • 1
    Doesn't the magtape controller deal with the conversion between tape frames and PDP-10 words?
    – another-dave
    Dec 19, 2019 at 23:35
  • 1
    Sometimes. But there have to be multiple modes for writing and reading backup tapes on the one hand, and dealing with IBM compatible tapes on the other. And I'm including mediation done by controllers in my thinking about the strategies for dealing with the difference. I'm also including feature built into DEC-10 Cobol.
    – Walter Mitty
    Dec 20, 2019 at 1:59
  • Basically, I'm not too interested in whether the transformation between 36 bit words and octets happens inside the controller, in the CPU, in the operating system, in the language run time SW, or inside the application. There's a little bit of all of that going on. As far as the controller goes, the 680i (??) was one of the magtape controllers, and it had a PDP-8 inside of it.
    – Walter Mitty
    Dec 20, 2019 at 16:27
9

36-bit computers were used to communicate through channels which were not 36-bit. ARPANET packets are not the only one, paper and magnetic tapes, connections to terminals, ... have also their frame which is not 36-bit.

Protocols and OS of the time were used to define various ways to transform 36-bit words in smaller units (search here for SET TAPE FORMAT for instance to see how TOPS-20 handled the matter).

ARPANET is not an exception and FTP for instance define various types of transfer. You can still see trace of that in the current ftp command of Linux which still has ascii, binary, image and tenex commands (Tenex being the ancestor of TOPS-20) to set up the transfer types. Here you can find a recollection of how PDP-10 sytems handled those conversion with references to RFC-959, RFC-854 and RFC-683 (which describes how to deal with TENEX files with holes which seems to be of interest for you).

Improve this answer
2
  • Oh how I LOVED the DECSystem-20. It was a glorious mainframe. At one point I actually had many of the JSYS calls memorized.
    – Wilfred Smith
    Dec 19, 2019 at 19:31
  • And command recognition was way ahead of it's time. Powershell is finally catching up.
    – Walter Mitty
    Dec 19, 2019 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .