On 6 Oct 2007 at 16:48, William Donzelli wrote: I remember getting the Adventure source tape and reading it in and saying "What the h*ll is this?" It didn't take too long before I figureed that I was dealing with 36-bit words with 5 7-bit ASCII characters packed into each. Of course, someone on a PDP-10 may have been equally puzzled to see 6- bit display code packed 10 characters per word, with an end-of-line being a 00 00 combination packed into the low-order 12 bits of a 60 bit word--otherwise, the meaning of 00 was a colon (:) character. The standard tape conversion/transfer utility for the Cyber 70's had no idea of how to deal with PDP-10 character representations. Most large mainframes excelled at I/O. The aforementioned Cyber 70s used 10 peripheral processors to transfer data between I/O devices and central memory. The standard I/O scheme was to use "circular buffering", so that it was possible to continously transfer data from one device to another by using two PPUs and having them chase buffer pointers. Disks were only somewhat faster than tapes. Deadstart involved reading a tape and copying files from it to disk. Much effort went into the deadstart routine that did this so that the tape could read non-stop. Cheers, Chuck

On 6 Oct 2007 at 18:10, woodelf wrote: The whole history of character respresntations in computers seems to have been pretty bleak to me. Early decimal machines could use 00-99 for characters, then binary machines adopted 6-bit characters--a *smaller* set. At least 5-bit Baudot wasn't used much. When customers started asking for lowercase characters on the CDC 6- bit machines, IIRC, there were seveal approaches suggested. One was to pack 7.5 characters into a 60 bit word. Someone coined the term "snaque" for this unit (bigger than a byte, get it?). I'm not aware that the system was ever widely deployed, thankfully. Instead, uppercase characters were represented with their usual 6-bit codes, while lower-case was denoted with a 00 "escape" character. So, "HELLO" woud be represented in octal as 10 05 14 14 17 and "Hello" would be represented as "10 00 05 00 14 00 14 00 17". (Hope I got that right!). 6 bits was miserably crowded when numbers and punctuation were added. In particular, I recall that double-quote and "not equals" shared the same code--what came out on your listing depended on what type train was installed in the printer. In retrospect, a 12-bit character would have made a huge amount of sense--12 rows on a punch card, so nn need for translation hardware to somehow turn legal and illegal punch combinations into characters. Lots of room to grow--perhaps not enough for the ideographic alphabets, such as Kanji, but enough for most writing systems. Octal or hexadecimal accommodated equally well. In the Sepember IEEE Computer magazine, Neville Holmes wrote a squib on "The Profession as a Culture Killer", with some note of the new ICANN rules allowing non-Latin characters to be part of domain names. I don't agree with everything he wrote, but he had some points. Cheers, Chuck

On 6 Oct 2007 at 21:52, William Donzelli wrote: If efficiency was the primary goal, hollerith cards could have been punched in column- or row-binary; packing 3 digits per colum, with leftover codes for sign and point. Think of the trees saved! Yet I never saw a BDP application do that. Would have been hell on the punches in any case. Back to 6 bits. For the type of stuff that the BDP community did, 6 bits per character was plenty. In that sense, using an 8 bit character was a real waste. Two 6-bit characters can pack 3 BCD digits--exactly the same efficiency as S/360 packed decimal--and packing/unpacking is not much different Cheers, Chuck

On 7 Oct 2007 at 16:10, William Donzelli wrote: And yet, many of my bills still arrive as all upper-case. And I'll wager that most of that data is stored as 8-bit characters. Go figure. Cheers, Chuck

Curiously, the HP9100 _calculator_ used 6 bit words. This made sesne for user programs (and keycodes), but numbers were stored with one BCD digit, a sign bit and a blanking bit in each word (I think). The main processor register was 6 bits wide too. The HP9810 that replaced it used 6 bit (logical width) memory, but I think only for the user programs (which again were lists of 6-bit keycodes). I think nunmbers were stoed in 16-bit-wide memory. Actually, since this machine had phyical memeory that was half the width of the logical memory (and circuitry to automaitcally do 2 memory cycles), this must be one of the few machines to have 3-bit-wide memory boards. -tony

Explain? Parity does not count. The big reason IBM picked eight over six with the S/360 (and yes, there was a fight over this), was that in the big scheme of things, eight and four bit chunks are more memory efficient than six bit chunks. Kind of really bad timing on DEC's part, setting up the whole 36 bit line just as IBM set up everything to 32. But then, they would not have known. Bad luck. -- Will

???? The 36 bit IBM architectures died with the that early 1960s IBM report. Yes, it did. My point is that right after DEC decided to make the 36 bit line, the 8 bit world was born. Nobody's fault, just really bad timing. -- Will