Slashdot Mirror
Remembering 36-bit DECs
rjinbanff writes: "Very interesting read that details a number of historical events in Computing history (Kermit, EMACS, etc). Self-described as: "A nontechnical reminiscence written in 1988 (on the occasion of unplugging Columbia University's last DECSYSTEM-20) for a Digital Press book that was to commemorate DEC's 36-bit machines with a series of articles, but was never published."
Minor edits, notes, glossary, links, and HTML formatting added in January, 2001."
Not exactly the registers and memory words, but at least the PAE extension introduced in the Pentium Pro line (and AMD Athlon) uses a 36 bit bus for addressing physical memory, thus being able to use 64 GB of Memory as opposed to 4 GB with the 32 bit bus of the Pentium and K6 processors.
FIELDATA is an old six-bit character set that is used all over the place in EXEC-land (the OS) on a 2200 to store things like filenames, etc.
As with the SIXBIT format you mention, this allows the storage of 6 characters in each 36-bit word, and as the end result of this you see a lot of 12-character length limits (two words) in various system files, packet formats, and so on.
As a sidenote: the major airline I work for still uses 2200's, and the application I work on still stores most of the application data as FIELDATA.
--
-Rich (OS/2, Linux, BeOS, Mac, NT, Win95, Solaris, FreeBSD, and OS2200 user in Bloomington MN)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Although I came to Columbia after the TOPS-20 and VAX days, working for AcIS (the university's computing arm) definitely helped me to appreciate the whole command line philosophy Frank talks about. Columbia is where I really became familiar with Unix, from home on an ancient XT clone through PC Kermit 3.12 and a barebones TCP stack (to have multiple telnet sessions I'd switch between using Alt-N), installed Linux for the first time (5+ years ago!), and fell in love with Emacs.
My favorite game was VTTrek, which was a first-person 3D space fighting game played on a VT-100 terminal. No, there were no bitmap graphics. It used the wonky 8-bit ANSI character graphics combined with ANSI escape sequences for bold, flashing, etc. to make it more animated. And you had to play on a 9600 baud terminal connection, or else you would lag and be blown away by those high-baud bastards.
DECWAR was another favorite. It was only 2-D, but was realtime [not turn based] and you could play it on either a CRT terminal [i.e. a monitor] or, you could also play using a line printer terminal [paper]. You could enter lots of cryptic command lines and dump your view every so often if you needed it. Wow, that was fun. Sort of like keyboarders versus mousers in Quake. [Update: that DECWAR page linked to above has a link to a version running on a BSD box. Oh yes...]
sitwar was another fun realtime wargame [maybe it was spelled 'citwar'?]. But I think it required a monitor, so we didn't play it as much [monitors -- or "CRTs" as they were called then -- were in low supply and high demand].
When it came to instant messaging, we used something called "FORUM", which I think was written by my friend Yoram at UofT. Actually, it was closer to IRC, except that there you could see a history of the last N lines. It was great -- you could log in at noon, do a "/lastlog" and the previous 20 lines of conversation, complete with timestamps, would be printed out for you. Good for leaving messages.
[ReidNews]
Aho (of AWK fame) also taught at Columbia for quite a while.
All I can think of is 4 8-bit bytes with a parity bit each. (4X9=36).
Been there, done that: even in late 70's, like 78-79, at least one University in Appalachia had most student computer services as batch jcl FORTRAN as described, altho the 'cool' students would use 300 baud acoustical modems with (snicker) rotary dial phones to 'Wylbur' and something called a 'VAX' - I really didn't care about that stuff (in retrospect, should have) - was more involved in the build your own single board 8085 computer EE class w/ the Tektronics 'in circuit emulator' with the 8" floppy!
try { do() || do_not(); } catch (JediException err) { yoda(err); }
The CDC Cyber series we used in high school had an unusual byte/word/whatever size as well. A chat program (similar in usage to IRC) would accept more uppercase characters than lowercase characters due to the fact that lowercase characters higher ascii values used more bits.
I forget the specifics, 12 bit words? Something unusual.
God, the effort I went through just to get graphical output. That was in the days when CPU time was accounted for. My advisor dropped me a note in my department mailbox, telling me I had used something like $2300 of CPU time under account "misc" - "I hope there is a good reason for this". Well, there was, I was writing cwplot. The thought of CPU time accounting seems silly now.
But the COMND JSYS was the greatest. It made the command interpreter pretty much self-documenting. When I first encountered Unix, I was extremely annoyed that the "man" command didn't even do that really. It took a year of solid use to finally "get" Unix (and C programming, too), over 5 years after my experience with TOPS-20. tcsh tries to emulate COMND, but essentially fails. How can one go adding documentation for every command on the system? The very thought is ridiculous.
BTW, anyone else remember PCL? You could write clever hacks in that - kind of a scripting language for "exec," the command processor. But you had to run the "exec" in the directory. And PCL docs were something you printed out on the wide line printer and then cut and bound yourself. Had a lot of fun with PCL...
And I still remember a little TECO: "y" would irrevocably erase a buffer in EMACS. Of course, EMACS is permanently wired to my fingers now. I've only had to stop using it when I was stuck with Macs, DOS or Windoze...
My first abortive experience with C was on TOPS-20. A CS guy at WPI had written a compiler for it, and because of the 36 bit word, all the "bytes" were 9 bits! I stuck to Pascal anyway - thought it was the greatest. Didn't learn C until 4 years later.
Thanks for the great article. It explained a lot of little things I never knew, most probably because WPI was cut off from the ARPANET, supposedly because of some transgressions committed before I got there...
"...plus a set of powerful text manipulation utilities like sed, grep, awk, lex, and yacc, whose functions should be obvious from their names."
Paul Stevenson
Correct: PDP-10 bytes may not cross word boundaries. Anything else is permitted.
Ewww! 6/12 Display Code! Yeah, the CDC 6000 series used 60-bit words, and normally you'd pack ten bytes/word. Several values were used to escape to a larger code set, so some characters were two bytes long (as with some Unicode packing schemes).
The Cyber 170 series were 64-bit machines, but they had a 60-bit compatibility mode. KRONOS and NOS/BE would use 6/12 code IIRC, and NOS/VE used 8-bit bytes full of ASCII on the same hardware (in native mode).
It allowed DEC to make more use of those 18-bit PDP-1 memory planes they had lying around? :-)
Try again. BBN sold an OS for the '10 called TENEX, and when TOPS-20 came out (looking quite like it in some respects) it was sometimes jocularly referred to as TWENEX.
"It was also called RAD-50 ("50" being an octal or hex number -- can't remember).
Basically, squishing 3 characters into 2 (or 24 bits into 16) because the character set did not include lowercase.
It was commonly used to store passwords on RSTS/E
(boy, I remember this stuff like it was yesterday)."
Actually you don't. SIXBIT had six distinct 6-bit bytes per 36-bit word, and could be constructed using the byte operators. RADIX50 uses a 50-character charset and must be packed using arithmetic (multiply, add, multiply, add....)
SIXBIT was used by the TOPS-10 filesystem. RADIX50 was used *somewhere* in TOPS-10 but I misremember where; it was much more widely used in PDP-11 OSes (as you noted). TOPS-20 used ASCII throughout.
Any system one doesn't know well appears "user unfriendly". That's true for mainframes, UNIX machines, Windows, and even the Macintosh.
Yes, but in the context of the article, he seemed to think TOPS-20 was user-friendly the first time he used it, and still finds Unix unfriendly after five years (written in '88). Of course, could be nostalgia for TOPS is coloring his glasses, but based on my experience with UNIX, and his description of menu prompts in TOPS, I don't think so.
Amdahl? I thought they left the "IBM-mainframe-clone" market? They said they would do NT-based servers (how fucking lame!). I am glad they still do some good stuff.
Another thing I learn now: that there are 31-bit s/390 systems.
Thanks for the info!
Sigged!
There was a line of IBM mainframes 8360 (used to run VM/ESA stuff) that had 31 bit CPUs! Yep, and it indeed could address 2 GB memory. I remember I was quite surpirsed, something like "WTF?! 31?" It still doesn't make sense to me......
Sigged!
== Doug Moen ==
I have written a truly remarkable program which this sig is too small to contain.
From: kent@decwrl.dec.com (Christopher A. Kent)
Newsgroups: alt.folklore.computers
Date: 4 Jan 90 08:44:51 GMT
That's not quite the way I have it. The original dsw stems from the days when computers had front panel switches (dsw = "Delete from switches") and Unix core files were restartable.
To delete a file whose name you couldn't type, you would obtain its i-number (from ls or catting the directory), enter the i-number in the switches, and run dsw. dsw would create a core file that, when run, would delete the offending file.
I'm not sure when dsw changed from this functionality to the precursor of rm -i, but I'm pretty certain that V5 dsw didn't use the front panel switches.
== Doug Moen ==
I have written a truly remarkable program which this sig is too small to contain.
The Computer Museum History Center has a KL-10 model in their collection. The museum is working toward a permanent display building at Moffett Field, but you can see part of the collection now if you go to one of their events.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
And I believe all "TOPS-20" systems used KL-10 processors or successors, if any.
So while it might be true that all TOPS-20 systems had PDP-11 front-end processors, it wasn't the case that all TOPS-10 systems had them.
Practice random senselessness and act kind of beautiful.
I still have most of my DEC-20 Manuals (in boxes) and remembering PMAPs, UUOSYMS and the likes. I used to support 13 2060's back in the 80's as a Timesharing Systems Programmer, any cronies out there remember booting a multipack PS:??? Or how about a DX20 or PTYCON, those were the days. Put one more fan in a DEC 2060 and it would hover.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I used that machine for a numerical analysis course... apparently, UT made a custom OS for it to do the load-sharing (UT-2D); I assume it was based on the original OS though. The thing I remember the most about it was that it treated all files as tapes, and after you compiled your fortran program or whatever, you had to rewallx to rewind all of your files in order to read them again (if you wanted to recompile your program, for example). Rather annoying :) That machine was later renamed dinosaur.cc.utexas.edu, and served as a print server for a while, before it was finally decomissioned.
I posted this reply elsewhere, too, but it really belongs here. One of the first MUDs was developed by (mostly) Mike Yoder at DEC. (Mike sat in an area of offices in the DEC10 group that was often refered to as "Middle Earth", btw.) It was a 36 user real time game that allowed users to interact. It was writen in about 1978 or 1979. I forget what it was called, but Mike was a big DnD fan back then. Mostly, it parsed english like statements and took actions based on what you typed. Mike worked on the parser (the harder job), while I did the multi-user communications and created much of the game space. It had a "world" kind of like Adventure. Ah, the power of Pascal. I dont think it's the same MUD.
----- Lotus Super 7 - A real car.
68bit wouldn't really make sense, since there should be one parity bit for every byte. 64 / 8 = 8 bytes, so 72bit would make more sense than 68.
:-)
Aha! I had forgotten why 36bit was actually used in the first place: it makes sense again
So why don't we use parity bits in the data path any more? Is this because of self-checking ECC-RAM (for instance), or because of more reliable processors/manufacturing processes?
Correct
Most Slashdot-reading Linux kiddies aren't even old enough to remember the Intel Pentium fdiv bug, let alone 36-bit DEC systems. I'll bet they don't even know what parity is. To them life is nothing more than their Athlon, Geforce, and the latest Redhat. Maybe some new hardware to which they can make that weird whiney "schweeet" comment. What a future to look forward to. *sigh*
Songs that made the Hit Parade
Guys like us we had it made
Those were the days.
And you knew where you were then
By the lights of the KI-10
Mister we could use an editor like TECO again
Didn't need no ROM bootstrap
Or any of that GUI crap
Gee our old TOPS-10 ran great
Those were the days
http://www.angelfire.com/ca3/marlowe Better a smartass than a dumbass.
The main thing I remember about that job was the disk drives. I don't remember the DEC model number, but we had three, and they were each the size of a washing machine, had the big removable 20-pound 10- or 11-platter disks, and held, each, a whopping 200+ MB! Woohoo! (Now I've got 40 GB in a 3.5" form factor in my new PC at home...God, I love technology.)
I liked that 2060. I got decent at doing basic operator functions--startup, shutdown, queue management, etc. I even wrote school papers using whatever their runoff language was, and printed them on one of the typewriter-style terminals in the offices. It was just a very easy and straightforward system to use. And it sure helped when I got to college two years later and found myself working on a VAX 11/785.
Besides, I've been working with obsolete mainframes ever since, so that 2060 got me started on my career path. :)
"Settle down, Beavis. We've got an experiment to do."
SIXBIT and RAD50 were different OK. I was wrong.
RADIX50 was a 40-character set system. The "50" was an octal number
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
visit http://ftp.uk.linux.org/~kgb/Caterham7, then email me
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Basically, squishing 3 characters into 2 (or 24 bits into 16) because the character set did not include lowercase.
It was commonly used to store passwords on RSTS/E
(boy, I remember this stuff like it was yesterday).
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
I also have in my trophy collection an RK05 disk, and Altair 680 literature, but I must confess that it's still fun to flip the PDP-11 switches ones in a while
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Wowzo, I'd forgotten that little tidbit - I actually /do/ remember those days - download the latest host table every week, what's DNS?
.ARC file you downloaded is corrupted? You probably used binary and not tenex!
Oh, that
Thanks for the trip back.
Didn't realise it went back as far as early 80s though. I knew of a few dial-in MUDs around 84. I think BT invested in one at some point, but that would have been later. 86, 87? Wonder how much revenue they got from that?
Now there was an oddball machine. Made by CDC, I think it was called the Cyber 660, and UT had two of them connected together in some sort of load-sharing fashion. Had a 60-bit word length with 6-bit 'bytes'. The most popular application running on the monster was a software PDP-11 emulator/debugger. For my CS-410 class, I had to write an assembler and loader for the PDP-11 in assembly language itself, and get the emulator to assemble, load and run those two programs within the simulated PDP-11 environment. I was one of about 5 students in the class to get mine to work... out of 55 students who finished the class at the end of the semester in a class that began with about 275 at the start of the semester. Talk about a weed-out class in CompSci. Ahh, those were the good old days.
Yeah i looked closer when i got the chance and they are RISCprocessors
But it looks like the fuxxorz didnt even want to boot up. They have some systemtesting with a countdown that stopped at 3, even tried out a MicroVAX with the scsidrives, seems like that MicroVAX used another synch for monitors because i didnt get any display on it. Oh well as another poster said, ill go play with my Athlons & GeForce instead.
DEC-stations cant be used as radiators, they make to much noice.
This aint my
Oki so be it, but speaking of DEC-processors, is there anything else then Ultrix availble for them?
If i had a penny for every pound of junk i got home to piss off my GF id be a millionare instead of having a junkyard of old shit. Im really just hoping to be able to run something else then these old geezers like the ones you mention. Im wrapping up things at work here so i dont know the modelname other then it uses DEC-processor and is called DEC station (think it should be around 800Mb harddrive and scsi interface to it) It would be a shame not to atleast compile apache on it and let it be slashdotted over and over by mirroring sites that are popular or should i just throw it of the balkony down on some ricecooker car when it passes?
Feel the power of UNiX, submit to the Daemons
This aint my
Disclaimer:
.sig i usually try to think of something witty everytime.
Havent read the entire article.
--
Having that said, this hardware used to run Ultrix machines and to some extent is today.
But is there any other use today, can DECproccessors be run on any Linux distro or perhaps NetBSD?
Cuz if it cant be run on NetBSD it aint even electronics.
Nah this isnt my
This aint my
Anyway, the designers design a 16 bit machine, with one bit of parity, and of course a manager comes along and says "Sod this, we're not wasting a bit on parity - use it!".
So they did.
So then they had a 17 bit processor. 17 bit memeory. 17 bit programs. Not 16+1 bits (as originally designed), but 17 real bits.
Sounds like something out of Dilbert, but it's true.
-- Do gravity waves prove the existance of God?
"Making linux GPL was the best thing I ever did" - Torvalds. I'd hate to see the worst thing...
I really don't think that for example Intel hardware is designed for mission-critical situations. People are accustomed to their machines crashing, they blame it on the software and restart the computer. Nobody likes to admit that they have bad hardware, but nobody wants to pay a premium for reliable hardware either.
It took me a minute to realize this was sarcasm!
________________________________________________
suwain_2
So what are the advantages os using 36 bit instead of 32 or 64? It sounds like a lot of confusion for a little better performance.
Man, that takes me back. COMND, HRROI, ACJ. My first program was written in Pascal using EDIT on the LOTS (Low-overhead Time Sharing) DEC-20 at Stanford. That was a machine. I still miss some of the things it could do. EMACS minibuffer? AYEWBF anyone? What a different path I would have taken if I'd come a couple years later and cut my teeth on a VAX running UNIX instead. Took me 12 years to find my way to UNIX.
WWII era teletypes used a 5 bit code, so you had to shift just to get upper case + numbers. I don't know if anyone ever actually used shift codes to represent upper/lower case, since the change from 6 to 8 bits (for most manufacturers) predated any common use of lower case in computing.
I once rescued a 1943 Army teletype from a dump and took it apart. It did encoding and decoding by means of a rotating shaft and cams, and the print mechanism was the same flying levers as in manual typewriters. Two of the 32 bits were Shift In and Shift Out -- corresponding to hitting and releasing the shift lever on the keyboard. The numbers were shifted qwertyuiop keys. This seems to imply that the codes for either numbers or letters were out of order. But these machines were used for talking to each other, not to computers, so scrambled codes were OK as long as both ends scrambled things the same.
The 36 bits were all data. The printers of that day used only 6 bits for a character (A-Z, 0-9, a few punctuation marks, a few control characters). So the 36 bit word could hold 6 characters, or 9 binary-coded-decimal digits, or the equivalent of more than 10 digits in binary. It was a pretty useful word size until people started insisting on having lower case letters and all the other symbols you'd find on a typewriter.
I don't know if this relates, but the standard (IBM) punchcards had 12 x 80 hole locations. The 12 possible holes for one symbol were encoded with a rather sparse encoding scheme -- numbers were a single punch in the 0 - 9 rows. Letters were one punch in the X, Y, or 0 row, plus another in the 1-9 rows. Punctuation was 3 punches. Usually these were translated into a 6 bit code when read, but if you wanted to just read it straight in without translation, then a divisible-by-12 word size came in handy. And it was possible to use those cards to store plain binary, up to 12 bits per column...
6 bits is enough if you put letters in all uppercase. 7 bits is necessary for uppercase if you want more than two punctuation and control characters at all (26 lower case + 26 upper case + 10 digits = 62). Real ASCII is 7 bit, but computer designers didn't like 7 (it's a prime number, so a multiple of 7 bit machine would be very inflexible for any other sort of data), so they rounded up to 8.
The 4004 was designed for a calculator, hence 4 bits to store "0" through "9". It turned out to be useful to control other things as well. (Pure genius in that design.) So subsequent generations of microprocessors just doubled the size 8,16,32,64.
The only trouble with these two theories is that some people have stated that the IBM 360's were using 8 bit bytes, and they were designed almost a decade before the 4004 and more than a decade before normal printers or terminals could handle lower case. I don't know about the 60's -- I know that in 72-75 I worked on two very different non-IBM systems, an NCR 8-bitter, and a Xerox/SDS 32-bitter. So it looks like many hardware engineers were actually looking ahead a decade or so to when it would become possible to print lowercase... Stark contrast to the Y2K snafu, eh?
I've seen octal (mis)used on 8 or 16 bit machines too often to believe that the divisible by 3 word size was a reason. Probable real reason: conversion to/from octal is less than half as many assembly language instructions as to/from hexadecimal. (I've written hex conversion in enough assembly languages to be sure about that!)
Printing Octal on an ASCII display:
Isolate 3 bits (the method is machine-dependent)
Add 32 (0x20)
Print it
For hex, you have to test whether it is >9, then either add 32 or add something else to turn 10-15 into A-F. And in EBCDIC...I don't want to even think about that.
You might not think that one IF (2 instructions) and one extra addition (1 instruction) matter that much, but when 100KHz clocks and 256 bit PROM's were state of the art...
I remember playing MUD on a decsystem 10 - or 20 (i am not sure now) back in the early 1980s. It was developed at Essex University in England. I could only run after all other 'legitimate' processing was completed, which meant it was only available from around midnight GMT till 6 am. This did mean we saw a lot of international visitors due to the time differences, thru the JANET (joint academic network?). The same MUD was also run on other DECs at other unis - I seem to remember it was sometimes available at OSLO in Norway too.
Was this the first real MUD?
"Linux users never complain about Microsoft. They don't need to!"
Looks like the SIMTEL20 archives live on at http://www.simtel.net/simtel.net/.
There are several emulators out there, both hardware and software emulators.
I have several software emulators, specificially the one written by Stu Grossman and Ken Harrenstien. These are not in the public domain. The operating systems can be downloaded at the PDP 10 software archive site: http://pdp-10.trailing-edge.com/
Two people are currently working on emulators that I know of: Daniel Seagraves (at www.lunar-tokyo.net) and Timothy Stark. Timothy is nearly done, and actually running Tops 10 (albeit with errors).
To see a emulator in action, try telneting to:
bi5.bootstrap.org
To see a hardware emulator, try telneting to:
xkleten.paulallen.com
Decwars Lives at: telnet cs16019-99.austin.rr.com
bhl
I think the first Emacs was done at project MAC at MIT. This would have been on a DEC PDP-10 running ITS (Incompatible Timesharing System) The PDP-10 is a 36 bit architecture.
The most common byte size on the '10 was 7 bits, allowing you to store 5 bytes in a 36 bit word, with a bit to spare. One of the popular text editors on TOPS-10, SOS, used this extra bit as a "line number indicator", meaning that words with the extra bit set was in fact the start of a new line of text, and contained the line number.
File names on TOPS-10 was stored in SIXBIT format, a 6 bit wide character set that made it possible to store a 6 character file name in a 36 bit word.
Another common byte size was 9 bits. If you placed a terminal in Packed Image Mode (aka PIM, resembling Unix "raw" mode) and read from it, you received 9 bit bytes, where seven bits were data and the last two bits were status information.
Nothing stopped you from creating byte pointers of other widths, and I recall writing programs with 1, 18 and 36 bit wide byte pointers.
There's nothing special about an 8 bit byte; that's a more recent concept than these dec mainfraims. Why 32? It leaves 4 bits left over after putting 4 characters in it? 64 only wastes 1 bit after holding 9, but it's a bigger word than you need for common integer or floating point data.
The 8 bits we use (why not 7???) seems to come from the 4 bit processors (4004, 4040) of the 70's. 4 bits was enough to hold a bcd digit. 8 let you hold two at once. After that, we've just doubled what we started with a couple of times.
Oh, and many of those older processors could use bytes of various sizes. I think the dec's were among the 36 bit machines that had a command to set the byte size from anywhere from 1 to 36 bits. It all depended upon what yoyu were doing with the data.
Well, your common or garden variety PC desktop or "server" (in most cases, a desktop PC with more drive bays, if you buy it from someone like Gateway) certainly isn't. But that's a function of the whole system, not the CPU, as Sequent show.
They only ran into trouble because (apparently) they wanted to use some or all of their C compiler as a back end.
Chapter 13 of the Ada LRM (Representation Specifications) allows an Ada programmer to define layouts of data types and structures down to the bit level if desired (typically when writing device drivers), but it is explicitly warned that such code is non-portable.
The reason these early machines were 18/36 bits derives from a bit of historical accident: a lot of the early machines used for scientific computation had "at least 10 digits" as a requirement. 10 decimal digits translate to 34 bits. Add a sign bit and you have 35 bits. The EDVAC (successor to the ENIAC) actually used 35 bits, 2's complement, but it turns out that having an odd number of bits on a machine that supported halfword operations was an unbelievable pain, so machines quickly added one more bit to get to an even 36.
Oh, I'm certain of that. You tended not to believe those stories until you experienced one first-hand.
I guess it depends on the situation. We had an 11/34a installed in a truck out in California. One of the guys from the team flew out there to man it for some flight data collection seesions we were running with NASA. He somehow clobbered the boot block of the RL02 pack. Luckily we had a version of the 34a that had the programmer's front panel (Field Service really hated to work on customerss systems who didn't have that keypad). I had to read the bootstrap code to him over the phone and have him key it in about an hour before the flight tests were to begin. Then I had to overnight him instructions on how to rebuild the boot block. Actually, it was pretty nifty that you could even do that. I cannot imagine doing that on a PC, though I suppose with a DOS boot disk with DEBUG.COM you could accomplish the same thing. (Uh, oh. I think I just added another thing to my weekend to-do list!)
--
CUR ALLOC 20195.....5804M
Whoa...
I think I'm having an ASCII FORTRAN and FORTRAN V flashback!
--
CUR ALLOC 20195.....5804M
Nah. TOPS-20 wasn't so weird. Now Sperry's EXEC operating system. It had so many barriers to getting anything done that it nearly drove me nuts. I was so happy when I could move my software onto an RSX11 system.
--
CUR ALLOC 20195.....5804M
Gee... I thought I was the only one.
I have hanging on the wall in the den:
The 11/70 parts came from a system we got used from NASA Goddard back in the mid '80s and used as spare parts to keep our aging ``production'' 11/70 running. The crashed disk platter was particularly memorable. The heads didn't just crash into the disk; they were torn off the arm which proceeded to scrape all the data off the center of the platter along with a significant amount of aluminum. I don't think anyone who was there will ever forget the sound. Today's disk failures are nothing in comparison.
There seems to be no end to what bizaare stuff computer folks hang onto (and display like trophies on the wall).
--
CUR ALLOC 20195.....5804M
It hasn't always meant 8 bits. And there was nothing special about 8 bits--certainly not the size of a character.
But if a byte isn't 8 bits then 2 bits isn't a quarter of a byte. Then there's not a funny correlation between a quarter of a byte and a quarter of a dollar. What type of world would that be?
--
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
early versions of UNIX had an even more elusive name for this command: dsw, an abbreviation for "do swedanya", Russian for goodbye, transliterated into Polish or perhaps German; this is not the only place where the censor has been at work... Current "standard" versions of UNIX do not have a "help" command, but in earlier releases, a help command was provided which declared simply, "UNIX helps those who help themselves"
plus a set of powerful text manipulation utilities like sed, grep, awk, lex, and yacc, whose functions should be obvious from their names.
I find it sort of ironic to read this coming from people who worked on mainframes, etc. (real iron men) Sure, Unix has come a ways from 1988, but for all those hard-core super-31337 CLI hackers, I think this is some evidence that even to people working with card-reading machines, and programming their own mainframe system utilities in assembly, that Unix was still user-unfriendly.
It's 10 PM. Do you know if you're un-American?
Of course, todays 31337 h4Xx0R5 don't even know what a .ARC file is!
Back in my day, we had to walk 15 miles through a raging snowstorm to extract our archives. Uphill! Both ways! And we were glad to do it, too! We didn't have no fancy ZIP programs neither! But we didn't complain, oh no!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Remember, SIMTEL20 was a DECsystem-20, running TOPS-20.
Gods, what a weird OS that was...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Yeah, but it ain't the same as finding SIMTEL20.ARPA, and having to know to set TENEX...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
I'm fond of retrocomputing. I'll admit that up front. I'm getting old enough to be nostalgic about things like COMND JSYS and a UNIX shell that doesn't have shell variables.
But then a thought struck me. I worked at The RAND Corporation during the days when it still had a technology program (they assassinated it in favor of policy analysis). They had a DECSYSTEM 2060, used primarily for INTERLISP work. The 36-bit architecture never caught fire at RAND the way it did elsewhere. At ISI in Marina del Rey, for example, they had the world's most photogenic machine room: it had a view over the marina that was to die for, and they also had about ten PDP-10s lined up facing each other. They sold a lot of access to movie companies who needed a really sexy machine room, I hear.
Now, RAND did a lot of solid research on that 2060. That work was moved to Xerox Dolphins, which weren't nearly as fast, and on which INTERLISP ran much more slowly than it did on the 2060. Eventually that work petered out. There was an effort to port INTERLISP to the VAX, including writing new VAX microcode, but that effort was never completed (this wasn't at RAND, btw).
With the change in machine architecture, from PDP-10 to SPARC and PC, came a shift in research focus. Actually, at RAND, which was the first commercial UNIX licensee, those efforts were carried out in parallel. It was astonishing to note that there was essentially zip in the way of cross-fertilization between RAND's 36-bit world and RAND's PDP-11 and Sun worlds. There was an intelligent assistant AI type thing built on the UNIX system, RITA, the RAND Intelligent Terminal Agent, but that was only because that work was done before the 2060 arrived, I'm pretty sure.
So the question is, now that the 36-bit world is available again in emulation (sort of, if a decent PDP-10/20 emulator ever sees the light of day), could computer science benefit from any of that old work picking up again? I mean, the address space limits are essentially gone. I'm not certain but I'll bet that on a decently fast PC, the emulators would allow programs to run rather faster than they did on a 2060. INTERLISP suddenly becomes viable again.
Is there any point to doing this? Is any of the work that was starved off by the death of that architecture worth reviving?
4 bits in a nibble
2 nibbles in a byte
The size of word depends on how big your buss is.
`ø,,ø!
Free Software: Like love, it grows best when given away.
IBM adopted 32 bits with the System 360, this was great for Univac which sold many tons of 1107 /1108 machines into the Fortran
market..
Nobody cared about characters ..
the purpose of computers was numbers....
For many years (maybe still) a Linker option on Unisys 1100/ 2200-series programs is "AFCM" which stands for "Arithmetic Floating Point Compatibility Mode" and which guaranteed bit-for-bit compatibility numeric results with the long-extinct 7094...
on a 36bit word, you could fit exactly 6 'semi-ascii' characters if they were constrained to the limitations of SIXBIT. yes, SIXBIT is a character coding scheme invented by DEC that allows only (surprise!) 6-bits per character.
no upper/lower case - one case fits all.
abridged punctuation set as well.
but imagine the waste of having only 5 pure ascii characters (7-bit) in a 36bit word! hey, conserve that extra bit; there are hungry computer programmers in [insert remote underprivileged country here] that would give their eye-teeth for that extra bit you just wasted!
--
--
"It is now safe to switch off your computer."
A bit of detective work on google found the following info from trying to implement Ada on the 2200 36-bit architecture:
We are working with Unisys on an Ada 95 implementation for the 2200 series machines. Those machines are 36-bit, 1's complement machines.
Originally, we did not think there was a problem here. After all, the C compiler supports a full 36-bit unsigned type. We would just copy that implementation. However, on further inspection, that turns out not to be so easy. The C compiler had major problems with the unsigned type. Ultimately, two versions of the C compiler were built, one to pass the C validation tests, and one to actually use. To pass the C validation tests, Unisys built a compiler which emulated 2's complement math for this machine! That was done by doing all operations as 72 bit operations, and then reducing the result. Obviously, they did not want to use that implementation for production use.
In summary, if you read the Ada article it seems there are a whole lot of issues with a 36-bit machine, like having to do everything at 72-bit so you can divide by 8 again!
At this rate it's no wonder Emacs turned out so bl**dy complicated!
Your parents perhaps, but Grandma?
All this happened less than 20 years ago. I'm in my early 40's, but my whole career started in high school with DEC 20's with punch cards and PDP-11's with RSTS and papertape (110 baud modems), then RSX & RT11, VAX/VMS, Alphas, and finally intel (which was a technology step backward at that time, especially with windows). The pace of computer technology is incredibly fast. 20 years ago, half a meg of disk and 64k of memory was a lot.
Languages move fast too. First interpreted BASIC (I skipped COBOL because I started on DEC systems), then compiled BASIC, FORTRAN, C, then C++/smalltalk/java/perl/whatever ... Every 4-5 years you have to learn a new language.
Expect that everything you are writing will be obsolete within 10 years, and that something will come to rival Linux within 20.
Also expect that 10 years into your career, you'll be encountering younger people that believe what occured before them was bogus, and that what they are doing is totally new & different :-)
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Proof that skr1pt k1dd33z are far from a new phenomenon. When I was in high school in the early '80s, I was among the group of hacker kids at my school, but the ones at nearby schools had much more ph33r p0w3r. Of course there was no internet back then, so information was hard to find, and you only had one or two local time-share systems to work with. And this was back when you had to know what the hell you were doing just to log on even when you were supposed to be on a given system. The Internet has significantly lowered the bar on what it takes to be a kiddie.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
I actually logged into the system mentioned in this article, presumably right before it was unplugged, since it was in the 87-88 timeframe.
/mine mine mine/, not some university's!
Anyone remember SIMTEL20, which you can still find references to quite a few places on the net? That was a DECSYSTEM 20 at the White Sands Missile Range, and the home of many seriously cool archives.
My only personal experience with hardware of this era (actually older that that) was the DEC PDP-8e that we had for some time at our high school in Omaha. It had, I believe, 2K of core memory, quite a few DECtape units (mentioned in this article), and a 512K drum drive that was the size of a refrigerator and spun at an insanely high rate. We were told you didn't want to be in the room if the bearings ever went out.
The very cool thing about that system was power recovery. If the power ever failed (or someone pulled the plug, which we did once) the system could see it coming and quickly dump all the registers into core memory. Since core is non-volatile, things would pick up right where they left off when the power was restored. The ultimate UPS!
After that, I went on to work as an operator on a VAX 11/780 and 8650, doing standalone backups on the weekend graveyard shift, among other things. It was always fun to see what I could get out of students who only needed a few more minutes of CPU time to finish their assignments before I shut the system down. I got quite a few good takeout meals out of that deal.
Still and all, although it was a great time, I have to say that I'll take my nice portable laptop with Linux on it over any iron that big any day of the week. It's
That's an artifact of languages like C/C++, which provide 8bit byte addressability and use 8bit bytes extensively for string processing. In many other programming languages, you would hardly notice: they provide abstract string types, automatic packing and unpacking of arrays, and other features.
It's also an artifact of ASCII, in which characters are 8 bits. In fact, 36 bits is nicely divisible by 6, often used as the character size on mainframes.
It is kind of ironic how much the C/C++ programming language has driven the development of hardware. That sad thing is that now that the hardware has adapted so much to C/C++, many nice features that aren't in C/C++ are a lot harder to implement.
Incidentally, 36 bit or 68 bit architectures need not be a big problem for C/C++: you could treat them like byte addressable 32 bit and 64 bit architectures and use the extra 4 bits as type tags. That would actually make compiling languages like Java, Python, Lisp, and others a lot easier.
68bit wouldn't really make sense, since there should be one parity bit for every byte. 64 / 8 = 8 bytes, so 72bit would make more sense than 68.
You're using a very recent notion of "byte" . . .
.)
It hasn't always meant 8 bits. And there was nothing special about 8 bits--certainly not the size of a character.
With an ascii character set, the dec's put 7 characters/word, with one left over (which I think was used to indicate the last character in certain circumstances.
The data, though, was 36 bits, not 32+parity. Besides, if you want to do that, I think the correct number is 38, not 36, to allow 1 bit correction and 2 bit detection.
OK, OK. that's not the real reason for 36 bits. Remember how cars used to have real spare tires instead of the toy spare? Computers were like that, too. If you burned out bit 7 of the processor, you had some spares to use . . .
(really not as facetious as it sounds. Core memory used to come with spare rows & columns . .
Oh, ok I only counted 87 definitions in the glossary. I guess it has to be 100 before it's "technical".
"The most important contribution of the DEC-20 to networking was its support for the ARPANET protocols, first NCP and later TCP/IP. For many years, DEC was the only major computer vendor to support these protocols, which were mostly developed on DEC 36-bit machines under TENEX, TOPS-10, and TOPS-20 (and later on VAXes for Berkeley UNIX). "
Ok so us geeks understand this, but come on!
I think I'll print this out for my Grandma to read!
I thought the epilogue hit it right on: "Meanwhile, many of us who lived through that era retain our old habits, still using text-based applications such as EMACS and MM (or its successor, Pine) rather than their fashionable GUI replacements, but on UNIX platforms (Solaris, Linux, etc) instead of PDP-10s. Each time a new PC virus plunges the entire organization into chaos and panic, we barely notice. There is something to be said for the old ways."
So true.
Another thing. THough today we have massive amounts of software available, its somehow less satisfying it seems. Sure, you can deploy a major system, joining lots of software packages together and perhaps even modifying them some to do the job, but how exciting it must have been to be part of the group blazing the trail of timesharing user access, email, TCP/IP via Arpanet, and more. How satisfying it must have been.
Finally, I still shake my head is disbelief how fast things have changed. Back in 88, PCs were available, but not widespread, mostly due to lack of network access. I remember thinking how cool it was to have a BITNET address and being able to communicate with folks around the world. TCP/IP was made available to us around 1990. But to think that was only 10 years ago! In 88 I had a 4 or 8MHz XT (can't recall) and graduated with a 33MHz 386 just as 486s were hitting the market. Now, 8 years later I'm reading Slashdot on this web thing using a Pentium III laptop running @ 700MHz, connected to the internet via wireless networking to my DSL internet connection. 8 years ago we were psyched to have 9600 baud serial modems in each dorm room connected to the campus network.
Mind boggling.
Top Most Bizarre/Disturbing Error Messages
Unisys still use a 36 bit architecture in their 2200 mainframe class machines.... caused no end of grief to the new graduates at the last place I worked, on a UK banking system *grin*
/. accusing them of smoking crack!
Interestingly enough, these machines still power most of the airline reservation and core banking systems in a significant part of the world.
If someone came up with a 68bit (for instance) architecture nowadays we'd all be on