Early 18-bit computers like PDP-1 were based on 18-bit instruction sets, and used punched paper tape for storage etc. As far as I know paper tape was usually 8 holes, which works nicely with 16-bit etc. I haven't heard of 9-hole tape. How did they encode 18-bit instructions on tape?
3 Answers
The answer is invariably specific for a particular computer, and indeed may be specific depending on what is doing the reading (say, hardware bootstrap versus software loader, or what it's reading from (say, photoelectric reader versus teletype attachment).
On the PDP-1 reading 8-channel tape in binary mode from the photoelectric reader, an 18-bit word was assembled from 3 frames, taking 6 bits from each.
Assembly takes place in the I/O register, and it seems that this is accomplished by hardware obeying the "read papertape binary" instruction, rather than the reader software needing to read each frame, shift, and merge.
Read Punched Tape, Binary
For each In-Out Transfer instruction, three lines of punched tape are read and assembled in the In-Out Register to form a full computer word. For a line to be recognized in this mode, the eighth hole must be punched; i.e., lines with no eighth hole will be skipped over. The seventh hole is ignored. The pattern of holes in the binary tape is arranged so as to be easily interpreted visually in terms of machine instruction
The 1963 Handbook, page 23, has a concrete example:
The instruction sub 5137, for example, appears on tape and is assembled by rpb as follows:
Channel 8 7 6 5 4 : 3 2 1
Line 1 X X : X
Line 2 X X X : X
Line 3 X X X : X X X
Reader Buffer 100 010 101 001 011 111
This answer, though about the PDP-1, shows the general nature of binary I/O (whether paper tape or otherwise) -- the medium supports units that are so-many bits wide, and there is some convention for representing machine words with multiple units. Magnetic tape needs to do the same thing.
-
2It's also interesting to note how the PDP-6 and the PDP-10 stored 36 bit words on binary paper tapes. Same issue. 8 bits to a frame, but 36 divides evenly by 6. inwap.com/pdp10/rim10b.html Commented Dec 31, 2021 at 14:27
-
That's RIM format, the possibility of which I alluded to in my first paragraph. Was the same format used for storing non-bootstrap code on papertape? Did anyone actually punch executable binaries on papertape?– daveCommented Dec 31, 2021 at 14:36
-
wow thanks! ran across a fun video showing the pdp1 in action: youtube.com/watch?v=1EWQYAfuMYw– isbCommented Dec 31, 2021 at 15:26
-
The first block of a binary tape was in RIM format and was readby the read-in-mode hardware. The first block contained the RIM10B loader, no checksum. The remainder of the the tape was read by the RIM10B loader. This contained some stand alone program, such as a bootstrap that could read TOPS-10 from disk. Does this count as an executable? As far as storing .SAV files or .EXE files on paper tape, I'm unaware of anyone having done that at any PDP-10 site I visited. The PDP-6 was a whole different story. Commented Jan 2, 2022 at 12:38
-
I had in mind "user" .SAV files on paper tape, not the OS itself, but I guess the second-stage bootstrap counts.– daveCommented Jan 2, 2022 at 17:34
In addition to anotehr-dave's in depth answer maybe some (not PDP-1 specific) background information to show the environment:
8 hole punch tape was only a thing rather late on. Paper tape was commonly used in 5 to 8 hole versions (special types up to 24 and more), depending on purpose/equipment. 5 hole was 'small' Baudot type tapes, while 6 to 8 hole shared the same 25.4mm tape.
Thanks to this physically compatible medium, any 6..8 hole reader could any of these tapes and produce the lower 6 bits correctly. Read characters were always framed as a byte, so any 6 bit portion was always put into the lower 6 bit of whatever size that byte was, independent of paper tape 'width' or transmission byte size. That's why splitting any binary data it up into 6 bit chunks not only made a fine threesome of 18 bit words, but created as well a mostly device independent storage format. A machine could thus load a tape from any 6..8 bit reader as long as the serial interface as configured to the right word format.
At the time of the PDP-1 the most common teletypes were still operating on 6 bit.
-
Not to nit-pick, but I didn't see any easy way to attach a teletype to a standard PDP-1. There was one IBM-type typewriter connected to a dedicated slot; the connection was AFAIK more than just bit-serial (some time ago I wrote a question about machines with similar console Flexowriters). The papertape reader was likewise a device with a dedicated controller and as far as I can tell, one per PDP-1. I think teletypes came a little later than the PDP-1.– daveCommented Jan 1, 2022 at 2:58
-
@another-dave True, you're right. It was meant more of a generic addition. Then again, what reader was used? I have to admit, the only part of a flexowriter I have is an auxiliary reader made for 6 hole tape. And yes again, at the time of the PDP-1, ASCII was still not invented and 6 bit TTY were still the most common.– RaffzahnCommented Jan 1, 2022 at 3:20
-
1The manuals are a bit vague. It's a photoelectric reader, 300 cps or 400 cps depending on which document you read, and was built into the console cabinet.– daveCommented Jan 1, 2022 at 4:34
-
1AFAIK, the PDP-1 console typewriter was made by Soroban, and used FIO-DEC codes, not ASCII. This is form memory, no research. Commented Jan 2, 2022 at 12:41
-
This is explained here starting at page 21. There are basically two modes in which a paper tape can be used:
- Alphanumeric: 8 bits per tape line.
- Binary: 3 tape lines of 6 effective bits each per 18 bit word. Positions 7 and 8 are unpunched and punched respectively when punching. Lines with position 8 unpunched are skipped while reading.
Instructions were encoded using the binary mode.
-
It's also useful to note the role the sprocket holes played in establishing the location of "lines", including tape feed. Tape feed could be useful in binary tapes to spearate "blocks" from each other visually. Commented Jan 3, 2022 at 10:52