* Barry Margolin | I don't know much about what DEC did, as much of my PDP-10 experience was | on ITS, which did not come from DEC. There was quite a bit of 6-bit in ITS.
Oh, sorry, I missed the ITS-exclusive context. I have only worked with TOPS-10 and TOPS-20.
| You're right, it's wrong to call it ASCII, it's just a 6-bit character set | (wasn't BAUDOT also a 6-bit character set)?
Baudot code was a telegraph alphabet using 5 bits with two shift states, allowing 90 different characters. (Only one shift state was allowed at a time, or 60 more characters could easily have been added, as their order would also have mattered.) I believe Baudot was International Telegraph Alphabet Number 1, but cannot confirm this now. It dates back to 1880, and was replaced by the start-stop asynchronous International Telegraph Alphabet Number 2, about which I find no authoritative information -- my library of past editions of the CCITT colored books are not that complete. (And after having tried to explain the relationship between Unicode and ISO 6429 to a few people and having been voted down by Google searches because the myths outnumber the actual specification, I have once again lost all faith in asking the Internet in general for accurate and correct information.) -- Guide to non-spammers: If you want to send me a business proposal, please be specific and do not put "business proposal" in the Subject header. If it is urgent, do not use the word "urgent". If you need an immediate answer, give me a reason, do not shout "for your immediate attention". Thank you.
>>>>> On 21 Jun 2002 11:03:14 +0200, Lars Brinkhoff ("Lars") writes:
Lars> ja...@unlambda.com (James A. Crippen) writes: >> What *I* would like to see is a modern SUPDUP implementation for Unix. >> Both client and server. Over TCP.
We had that back in the mid-80s, so the trick is just finding it. I'd look around in public FTP sites like PREP and RTFM.
Will Hartung <wi...@msoft.com> wrote: >> You're right, it's wrong to call it ASCII, it's just a 6-bit character set >> (wasn't BAUDOT also a 6-bit character set)?
>BAUDOT was 5-bit.
That's what I thought. But 5 bits isn't enough for 26 letters and 10 digits, so I decided my memory must have been faulty. Did it use an escaping mechanism?
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Erik Naggum" <e...@naggum.net> wrote in message news:3233667508189525@naggum.net... > (And after > having tried to explain the relationship between Unicode and ISO 6429 to a > few people and having been voted down by Google searches because the myths > outnumber the actual specification, I have once again lost all faith in > asking the Internet in general for accurate and correct information.)
I just love it when the democratic spirit moves people to vote on reality.
"Barry Margolin" <bar...@genuity.net> wrote in message news:k0LQ8.28$S83.1018@paloalto-snr1.gtei.net... > In article <3d13577a$...@news5.nntpserver.com>, > Will Hartung <wi...@msoft.com> wrote: > >> You're right, it's wrong to call it ASCII, it's just a 6-bit character set > >> (wasn't BAUDOT also a 6-bit character set)?
> >BAUDOT was 5-bit.
> That's what I thought. But 5 bits isn't enough for 26 letters and 10 > digits, so I decided my memory must have been faulty. Did it use an > escaping mechanism?
It had a shift-in/out mechanism.
Once I was up at the Ham Radio Club at Walker Memorial and they were hacking with an old Baudot teletype. The decoder looked a bit like an automobile distributor. There was a rotor with an arm and it swept a over a circle of contacts. When the signal was high, it would complete the circuit and throw a solenoid that moved a metal bar back and forth. There were five metal bars and each had notches cut in them in strategic places. The notches were cut so that only one set of notches lined up for any of the 32 possible positions of the sets of bars. Once the bars were set, a level dropped into the correct notch and caused the appropriate key to be struck.
It was quite a sight to behold.
I wish I could remember how it synchronized with the signal. I do remember it would occasionally drop or munge a byte. This was in general ok unless it was a shift-in/shift-out byte, then you had to retransmit a good chunk of the message.
> Does anyone know _why_ they used 36-bit words??? Why not 2^n? (Or say 2^5 - > 1, like O'Caml's integer?)
Probably a legacy from the PDP-10s, which had 36 bit words. I think the original architectural source of this was based on having 6 six-bit bytes in a word. A number of early machines had a more compact character set that encoded in 6 bits. It didn't use lower-case letters, so you still had 64 - 26 - 10 = 28 characters left over for punctuation and other symbols.
-- Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
In article <3233667508189...@naggum.net>, Erik Naggum <e...@naggum.net> writes:
> ... > Baudot code was a telegraph alphabet using 5 bits with two shift states, > allowing 90 different characters.
two shift states? in which context? i started out on machines whose only input devices were 5 channel paper tape, and the software on both systems recognized only two shift states, with one patter having the same interpretation (space/blank) in both states
hs
--
don't use malice as an explanation when stupidity suffices
> In article <3233667508189...@naggum.net>, > Erik Naggum <e...@naggum.net> writes: > > ... > > Baudot code was a telegraph alphabet using 5 bits with two shift states, > > allowing 90 different characters.
> two shift states? in which context? i started out on machines whose > only input devices were 5 channel paper tape, and the software on both > systems recognized only two shift states, with one patter having the > same interpretation (space/blank) in both states
There were 5 patterns that had meanings independent of the shift state: letters, figures, space, carriage return, and line feed.
>> In article <3233667508189...@naggum.net>, >> Erik Naggum <e...@naggum.net> writes: >> > ... >> > Baudot code was a telegraph alphabet using 5 bits with two shift >states, >> > allowing 90 different characters.
>> two shift states? in which context? i started out on machines whose >> only input devices were 5 channel paper tape, and the software on both >> systems recognized only two shift states, with one patter having the >> same interpretation (space/blank) in both states
>There were 5 patterns that had meanings independent of the shift state: >letters, figures, space, carriage return, and line feed.
Are the 2 shift states here the most successful instance of trinary computing? AFICT 5 bits and 2 'shift states' is equivalent to 5 bits and 1 trit.
-- Attaining and helping others attain "Aha!" experiences, as satisfying as attaining and helping others attain orgasms.
* dvdav...@aol.comNOSPAM (Dvd Avins) | Are the 2 shift states here the most successful instance of trinary computing? | AFICT 5 bits and 2 'shift states' is equivalent to 5 bits and 1 trit.
Huh? 1 bit gives you two shift states if the system is capable of shifting, which we have to assume once we say "shift state" to begin with. Two _codes_ were used to select state. Letter shift and figures shift. Now, two _codes_ could have been two independent bits, right? That would have given a lot more codes, but since there were only two states, you have a space of a total of 60 codes. (I think I write 90 up there somewhere, a bad thinko.) If you could combine the two codes (two orthogonal shift codes), things would have been much more powerful, but that was not the case. -- Guide to non-spammers: If you want to send me a business proposal, please be specific and do not put "business proposal" in the Subject header. If it is urgent, do not use the word "urgent". If you need an immediate answer, give me a reason, do not shout "for your immediate attention". Thank you.
In article <3233751765044...@naggum.net>, Erik Naggum <e...@naggum.net> writes: >* dvdav...@aol.comNOSPAM (Dvd Avins) >| Are the 2 shift states here the most successful instance of trinary >computing? >| AFICT 5 bits and 2 'shift states' is equivalent to 5 bits and 1 trit.
> Huh? 1 bit gives you two shift states if the system is capable of >shifting, > which we have to assume once we say "shift state" to begin with. Two >_codes_ > were used to select state. Letter shift and figures shift. Now, two >_codes_ > could have been two independent bits, right? That would have given a lot > more codes, but since there were only two states, you have a space of a >total > of 60 codes. (I think I write 90 up there somewhere, a bad thinko.) If >you > could combine the two codes (two orthogonal shift codes), things would have > been much more powerful, but that was not the case.
Sorry. I thought you (or somebody) had meant a base state plus two additional shift states.
-- Attaining and helping others attain "Aha!" experiences, as satisfying as attaining and helping others attain orgasms.
I found a backup of Brad Parkers site on http://info.alexa.com and contacted him last week. His new site is http://www.heeltoe.com and on his ftp server (ftp://ftp.heeltoe.com/pub/chaos) there are some more versions. He has as well a much newer version ready which was never published and is planning to put it on his ftp server next week.
cst...@grant.org (Christopher C. Stacy) wrote in message
(snip)
> CHAOSNET was a local area network protocol similar to Ethernet. > It was developed at the MIT AI Lab for the Lisp Machines, > In 1975 there were no commercially available LANs -- nor was > there anything to hook up to them -- and the hackers there > were familiar with Ethernet that was created at Xerox PARC.
(snip)
> When TCP/IP became a stable standard, CHAOSNET was mostly > abandoned, although some of the CHAOSNET protocols continued > to be used over top of TCP.
> I can't think of any reason why anybody would want to > use CHAOSNET today.
I'm not suggesting trying make the world use CHAOSNET again, but were there any good ideas in the CHAOSNET protocols that were not picked up on by the TCP/IP and Unix networking communities?
I did read David Moon's AI Memo #628 at ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-628.pdf but the scan is so faint that I probably missed something. (By the way, I noticed that the publication looks like it was typeset in some fashion. The fonts don't look like they were designed by Knuth and the date is several years before Postscript. Any idea what might of been used to generate this document?)
In article <90ac4ec2.0206251251.33cc5...@posting.google.com>,
Martin Pomije <use...@MartinPomije.eiomail.com> wrote: >I'm not suggesting trying make the world use CHAOSNET again, but >were there any good ideas in the CHAOSNET protocols that were not >picked up on by the TCP/IP and Unix networking communities?
The most obvious one was the use of symbolic identifiers for protocols rather than port numbers. I think the TCPMUX protocol was inspired by this. But it's not really that big a deal, because you still need some system to prevent naming conflicts; you need either a worldwide registry analogous to the IANA registry of port numbers, or a hierarchical protocol naming system (coupling it with the DNS hierarchy might make sense, although domain names can change as organizations evolve and merge).
Chaosnet used two different types of acknowledgements. Receipts were used to indicate that a packet has been received, for retransmission and error checking purposes. Acknowledgements indicated that a packet had been read by the application process, and they were used for flow control. TCP combines these two functions into a single acknowledgement combined with the window. I think this turned out to be a reasonable mechanism, because flow control also needs to deal with network congestion, not just slow receiver processes. On the other hand, many TCP programmers seem to wish that it provided application-level acknowledgements, rather than forcing them to design it into the application protocols; but since Chaosnet didn't generate acknowledgements immediately, only when at least 1/3 of the window has been read (this is similar to TCP's Silly Window Syndrome avoidance), it wasn't really reliable.
It had a built-in connection forwarding mechanism. A server, upon receiving a connection request, could respond with a FWD packet containing the address and contact name for another server. This allows for various kinds of connection brokers and location servers.
Other than that, it was not too different from TCP/IP; it was designed around the same time as TCP/IP was being developed to replace NCP, and they apparently got many ideas from each other. Controlled packets are very similar to TCP, while uncontrolled packets are like UDP. RUT packets are similar to RIP.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> I did read David Moon's AI Memo #628 at > ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-628.pdf > but the scan is so faint that I probably missed something. > (By the way, I noticed that the publication looks like it was > typeset in some fashion. The fonts don't look like they were > designed by Knuth and the date is several years before Postscript. > Any idea what might of been used to generate this document?)
Looks like `Scribe' by Brian K. Reid It was popular at the lab around that time.
use...@MartinPomije.eiomail.com (Martin Pomije) writes: > [David Moon's AI Memo #628] > (By the way, I noticed that the publication looks like it was > typeset in some fashion. The fonts don't look like they were > designed by Knuth and the date is several years before Postscript. > Any idea what might of been used to generate this document?)
Well unless Dave Moon answers with the real dope, I can speculate a little bit about what may have been used. IIRC popular typesetting systems around at roughly that time were Scribe, R and possibly Bolio.
Output would have been to one of two Xerox laser printers. Either an XGP (earlier) or a Dover (later). The XGP was rather interesting in that it used a roll of paper rather than precut sheets. The paper was 8.5 inches wide, but pretty much as long as you wanted...
-- Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
> 36-bit systems typically used 6-bit bytes for simple printable > characters, called SIXBIT ASCII or simply SIXBIT. Or ASCIZ??
ASCIZ simply means a 0-terminated ASCII(oid) string, like C uses. In some assemblers, it was a pseudo-op, a la: .ASCIZ "hello" would emit (to borrow C syntax, sorry) the sequence "hello\0". I'm ignoring byte sizes here, since they're orthogonal to this concept.
Related: Does anybody have a SIXBIT conversion map readily available?
Barry Margolin <bar...@genuity.net> wrote: +--------------- | Erik Naggum <e...@naggum.net> wrote: | >| 6-bit ASCII is only usable if you're willing to forego lowercase. | > | > Actually, there is no such thing as 6-bit ASCII. SIXBIT has no | > control codes and is completely useless except in extremely | > well-controlled settings. | | You're right, it's wrong to call it ASCII, it's just a 6-bit character set +---------------
"Right" or "wrong", DEC SIXBIT (mandated for filenames in PDP-10 system calls [UUOs], among other things) *was* a strict subset of 7-bit ASCII, with one bit inverted. Or to say it another way, the 7-bit ASCII characters at codepoints #o40 through #o137 *were* the SIXBIT characters with values 0 through #o77.
To convert from ASCII to SIXBIT, you first upcased any alphabetics, then complemented the #x20 (#o40) bit, and the low six bits of the result was your SIXBIT character. In C, it would probably be something gross like:
If memory serves, it was only three lines of PDP-10 assembler, using those wonderful combined test-under-mask-and-modify-and-conditionally-skip instructions:
; here with a 7-bit ASCII character in t0 TRZE t0, 100 ; if alpha (and clear 7th bit unconditionally) TRZ t0, 40 ; upcase (zero) it TRC t0, 40 ; and in either case, complement ; t0 now has the corresponding SIXBIT char
-Rob
----- Rob Warnock, 30-3-510 <r...@sgi.com> SGI Network Engineering <http://www.rpw3.org/> 1600 Amphitheatre Pkwy. Phone: 650-933-1673 Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanal...@sgi.com and zedwa...@sgi.com aren't for humans ]
