No typo. While BCD was a way of encoding digits, BCD was also used as a character encoding. Often these were outgrowths of the digit+zone punch encoding of IBM cards. IBM later extended their BCD making into…. The EXTENDED Binary Coded Decimal Interchange Code, going from 6 to 8 bits in the process.l UNIVAC indeed have their own BCD-sih format called FIELDDATA. It was notable in that the nul value printed as @. the PDP-10 and the UNVAC 1100 series were just the longest surviving perhaps of the 36 bit computers, that also included the IBM 70XX series and the GE 600 (Honewell 6000) series. Both the UNIVAC and the PDP-10 did have the nice variable partial word mode, but all of these were indeed word addressed machines. The early Crays also were word addressed. The C compiler would simulated byte addressing by putting the byte offsetinto the word in the high order bits (the address resgisters themselves were pinned at 24 bits). Just to get this back on a UNIX history track, let me delve into more trivia. Perhaps the real oddity was the Denelcor HEP. The HEP had two addressing modes: One was byte addressed (as you expect), the other was for all other data thpes (16-bit, 32-bit, and 64-bit portions of the 64-bit word). The lower 3 bits of the memory address encoded the word side. If it was 0 or 4, then it a 64 bit operand at the address specified in the higher part of the pointer. If it was 2 or 6, then it was either the upper or lower half word. If it was 1,3,5, or 7, it was one of the respective quarter words. This caused a problem when we ported 4BSD to the thing. The Berkeley kernel (particularly in the I/O code) did what I called “conversion by union.” They would store a value in a union using one type pointer and the retrieve it via a different type. In our compiler, had they used a cast (or went via a void* intermediary), everything would be fine. But doing this sort of shenanigan (which is technically undefined behavior in C) led to insidious bugs where you’d be doing pointer operations and the WRONG size word would be referenced. I spent a few days hunting all these down and fixing them. It was about this time I realized that the code was setting up I/Os using a feature aptly named “The Low Speed Bus” and that we’d never get any reasonable performance that way. HEP designer Burton Smith and I redesigned the I/O system literally on napkins from the Golden Corral in Aberdeen. We went back and built a new I/O system out of spare parts we had on hand using an 11/34 as a control processor. The HEP I/O system was kind of interesting in that while it had a highspeed interface into he HEP’s ECL memory, the thing consisted of 32 individual DEC UNIBUSes.