What was the DEC CR11 card reader 'compressed Hollerith code' for?

Question

In this manual for the DEC CR11 card reader controller, the controller can deliver the card content to the PDP11 in either of two forms:

1. Column binary: the 12 rows of hole/no-hole are delivered in one 16-bit word

2. Compressed Hollerith: 5 rows are delivered as-is, and the other 7 (rows 1 to 7) are delivered as a 3-bit number, possible because there's supposed to be only one row punched of those 7. This results in one byte in memory for each column.

(See pages 4-5, 4-6)

The manual refers to the second mode as 'the proposed expansion of the Hollerith code'.

What was this proposed code? Who proposed it? Was the proposal adopted?

I looked at the RSX-11M CR11 driver code and documentation. The manual documents 'binary' mode (exactly as the hardware) and 'ascii' mode, where the card is assumed to be in DEC026 or DEC029 code (very similar to IBM 026/029!) and translated to ASCII for the user program. No Hollerith mode is documented.

The driver, however, seems prepared to support it. There's apparently a read modifier to request compressed-Hollerith mode directly. The compressed-Hollerith data also seems to be used for ASCII conversions, I would guess because it makes the translation tables more compact. But I assume that the 11M driver takes advantage of compressed-Hollerith mode 'because it's there', rather than that being why it was put into the controller in the first place.

Answer 1

TL;DR;

What was the DEC CR11 card reader 'compressed Hollerith code' for?

It essentially allows to read arbitrary card data as distinct 8 bit values, as long they follow the 'Hollerith scheme' of decimal encoding marked up with zones.

---

Long Read:

Compressed Hollerith: 5 rows are delivered as-is, and the other 7 (rows 1 to 7) are delivered as a 3-bit number, possible because there's supposed to be only one row punched of those 7. This results in one byte in memory for each column.

Exactly. This is true for all 256 EBCDIC encodings.

Hollerith code means essentially that all punching is based on direct encoding of the basic decimal numbers 1..10(0), extended by the addition of 'zone' markings.

1. No hole is space
2. A single hole in 1..10 mark numbers
3. A single hole in 11/12 is -/&
4. A Single hole in column 10(0)/11/12 (as zone) plus one hole in 1..9 mark the basic uppercase letter.
5. Multiple holes in 10/11/12 (as zone) plus one hole in 1..9 are added lower case and OCR/subscript numbers
6. A Single hole in 10/11/12 plus a hole in 8 (all as zone *1) plus one hole in 1..7 added punctuations
7. Multiple holes in 10/11/12 plus holes in 8, 9 or 8+9 (all as zone) plus one hole in 1..7 added the rest (*2)

So the 'compressed' encoding is able to gather all 256 possible encodings used in EBCDIC based punch cards, as well as such in ASCII - a fact unbeknown to many, there was an ASCII assignment for punch card with different encodings for some glyphs than IBM did for EBCDIC. They did differ in several later added characters, essentially everything after above step 5. Most control codes are defined different, but as well printable character. For example the curly brackets are on 10/12/8/3 and 11/12/8/3 on IBM EBCDIC while ASCII puts them on 10/12 and 10/11.

This encoding was defined at at time even before ASCII got lower case. And beside being house encodings for a few machines, they never gained widespread use, as IBM compatible encoding was essential for data exchange.

All of this is relevant when coming to the core question:

What was this proposed code? Who proposed it? Was the proposal adopted?

Hollerith code or "Binary Coded Decimal Interchange Code" as it was called in the 60s by ASA's X4 committee(*3), is a synonym for all kinds of punch card encoding. Something that varied a lot between machines and manufacturers. Modern base is essential IBM's EBCDIC as it was defined for the /360. But it generally only guaranteed only 66 (above step 1..4) basic glyphs. Everything else was up to much machine and even application specific encoding. This includes as well all 64 control codes which - after all, on punch cards structure was not done by injecting control codes, but field length.

While ASCII soon settled for a basic character set, EBCDIC did wobble for decades due the need to cover various previous encodings. Essentially it wasn't until the late 1980s when ASCII, going 8 bit with 8859, forced IBM to finalise assignment for all 256 codepoints.

Long story short: 'proposed expansion of the Hollerith code' simply means the ability to handle anything outside the basic 66 glyph by following the basic 'Hollerith' encoding scheme shown above.

---

*1 - Originally only 11/12 was named as zone, but already with the original 1932 Mills patent 10/11/12 was used. With the later extensions for punctuation and other characters 8/9 as well became zone.

*2 - It gets quite confusing here as this area was originally filled with alternative characters depending on the 1401 printer train.

*3 - Here a whole set of history books could be added about IBM being a main proponent of ASCII, but at the same time being slowed down by other card manufacturers taking part in various ASA committees. While X3 (Committee for Computer and Information Processing) was focusing on a complete new code (which became ASCII), the X4 (Committee on Office Equipment) was punching for a Hollerith compatible encoding - whose proposed 8 bit encoding was not like the later EBCDIC. And IBM danced on both parties - with a preference for ASCII but held back by Hollerith and most important developing the /360 right at that time of change.