Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Digital

Remembering 36-bit DECs 122

Posted by Hemos from the looking-back-on-the-past dept.
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."
This discussion has been archived. No new comments can be posted.

Remembering 36-bit DECs More

Remembering 36-bit DECs

Comments Filter:
  • 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)
  • 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.
  • Is there a DEC-10 emulator anywhere? If so, I would like to hunt down copies of various games I played in the 1980's on a DEC-10 at the University of Toronto [utoronto.ca]'s Engineering Annex [utoronto.ca].

    My favorite game was VTTrek [mono.org], 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 [blkbox.com] 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.

  • 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!

  • 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.
  • I started with TOPS-20 on the DEC-20 in 1981. Many a night I spent in the WPI WACCC, playing with VT100 escape codes, learning EMACS, and writing programs - in Pascal and PCL. My biggest program was cwplot, which was basically an object file you linked with your own Pascal object containing functions you wanted plotted on the Benson-Varian drum plotter. I plotted quantum wave functions with that thing. Other people used cwplot, too. It used the COMND JSYS, which made it extremely easy to write an interactive command interpreter in Pascal.

    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...

  • Have you ever wondered why C uses octal? Or why Unix (and therefore chmod(1)) takes octal numbers for permissions? It's because C and Unix were initially developed on 36-bit DEC machines. A 36-bit word has four 9-bit bytes, each represented by three octal digits.

    According to a long list of computers [nus.edu.sg], the PDP-7 was an 18-bit machine and the PDP-11 was 16 bits. Not mentioned on the list, the GE 635 had a 36-bit word.

    Early history of Unix according to Ritchie [bell-labs.com].

  • 'w/ the Tektronics 'in circuit emulator' with the 8" floppy!'

    That'd be the one with the PDP11 core, running V7.
    So maybe you were closer to the cool students than you thought.

  • On finding plus sides in the transition to unix:

    "...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 [surrey.ac.uk]

  • 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.
  • Have you ever wondered why C uses octal? Or why Unix (and therefore chmod(1)) takes octal numbers for permissions? It's because C and Unix were initially developed on 36-bit DEC machines.


    No. Unix V1 was done on an PDP-7 18bit computer. somewhere around V2 or V3 they switched to an PDP-11 16bit machine. C only came with V5 on 16bit.


    But all these machines were octal, grouping bits in groups of 3. PDP-7 6*3, PDP-11 1+5*3 (and 18bit addresses when using MMU).


    Only the VAX (32bit) and microprocessors (4/8/16/32bit) came as hex(ed) machines.

    --

  • The PDP-11 came later. The original platform was the PDP-7, which had an 18-bit word size.

    --
  • Yes, Kernighan was a brain, but his first name is Brian.
  • 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!

  • 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......

  • I particularly liked the description of the ways in which Tops 20 is better than Unix, because it's a reminder that there is still lots of room for improvement in the basic design of Unix.

    UNIX, however, is notoriously terse, cryptic and unfriendly, especially to novice computer users. ... converting to UNIX did force us to give up some of the features which originally drew us to the DEC-20 in the first place.

    The "user-friendly" shell provided by the TOPS-20 Exec, which gives help to those who need it but does not penalize expert users, is probably the feature that was missed the most. In UNIX, most commands are programs, assumed to have arguments of only options or filenames. This means you can't have "?" for commands and arguments in the shell, because the programs that would act upon the help request hasn't even started running yet.

    ... the DEC-20 program, once written, will contain built-in help, command and filename completion, etc, whereas the UNIX procedure can only be used by those who know exactly what they are doing. If you've typed "ls -s | sort" but don't know what the appropriate sort option is, typing question mark at that point won't do any good because the sort program isn't running yet.

    tcsh (the Tenex C-shell) does provide command and filename completion via the TAB and CTRL-D commands. But this quote suggests that the TOPS-20 environment provides a nicer implementation of these features than tcsh is able to.
    A special amenity of TOPS-20 is its retention of multiple generations (versions) of each file, giving the ability to revert to an earlier version should the latest one suffer from human error, folly, or tragedy. This, coupled with the ability to resurrect a file after it is deleted, imparts a sense of comfort and security that can only be appreciated once one moves to a more conventional and precarious file system. If you delete a file in UNIX, or create a new file with the same name as an existing one, then the old file is just plain gone. The "rm *" command in UNIX is simply too powerful, and too silent.
    Another example of a useful facility missing from Unix. Although it's possible to, for example, reimplement 'rm' as a shell script that moves the file to be deleted into a "trash can" directory, TOPS-20 provides a much more powerful facility for undoing file system changes that is implemented at the file system level.
    Another important feature of TOPS-20 is the logical device name, which can be defined in infinite variety for the system as a whole, and for each individual user. Each logical name can point to a particular device and/or directory, or to a whole series of them, to be searched in order. These are built into the operating system itself, whereas the notion of PATH and CDPATH are afterthoughts, grafted into the UNIX shell, not available from within programs, and not applicable outside their limited spheres of operation.
    Plan 9 implements this idea at the file system level, and, according to Rob Pike's papers on the subject, it adds considerably to the gracefulness and expressive power of Plan 9.

    == Doug Moen ==

  • More dirt on the "user friendliness" of early Unix systems. Here is the correct etymology for "dsw":

    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 ==

  • The Computer Museum History Center [computerhistory.org] has a KL-10 [computerhistory.org] 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.
  • Outed! By an Anonymous coward! Sounds like Carbo-loado to me.
  • a 36-bit word has four 9 bit bytes? not really. the 20 had byte instructions that took the size of a byte as an instruction parameter. i recall one c compiler that stored literal strings as four 9-bit bytes. but it was not a natural fit for the 20. far more common than four 9-bit bytes was five 7-bit bytes (remember ASCII really only has 128 codes) with one wasted bit per word. that's the way text files were commonly represented.
  • Did Frank tell you about the time when he & a bunch of other radicals occupied Grayson Kirk's office in Low Library? Do you know the real story about how Kermit was named? Did you know that Chris Gianone has incriminating pictures of me? That Alan Crosswell is crankier than 99% of all human beings? That Millman really *is* cool. That Maurice is *still* faster than everyone else? I think not! And yes, there are lots of bits & pieces of TOPS-20 that you can see in unix. Where do you think the idea behind 'completion' came from in TCSH? Where do you think EMACS came from (instead of being a dumped LISP environment, it was a dumped TECO environment on the 20).
  • The KL-10 (and successors?) had PDP-11 front-ends. The earlier KA-10 and KI-10 models of the PDP-10 did not -- just "classic" front panels. (My memory might be rusty, though.)

    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.

  • 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.
  • 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.
  • One of the first MUDs was developed by (mostly) Mike Yoder at DEC. 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. It had a "world" kind of like Adventure. Ah, the power of Pascal.
  • 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.
  • 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?

  • 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

  • My very first job, in 1981-82 when I was still in high school, was working at the computer center at Sweet Briar College as a general gofer and weekend scut-work operator. At the time, SBC had a DECSYSTEM-2060. My job was pretty simple--come in at night sometimes to print big jobs, burst and de-carbon them, clean up, etc. On the weekends I'd print some big stuff they normally ran on Saturday mornings, hang the backup tapes, vacuum the printer, and otherwise be bored out of my freakin' mind, while lusting after the weekend student operators (SBC's a high-priced private women's college).

    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. :)

  • They might've been RP06s, come to think of it. Push the button, wait for it to spin down, open the lid, put the plastic thing on top of the platter, spin until it locks, lift, give yourself hernia. Reverse process to reinstall.

    I also did 3 years of COBOL programming on a Unisys A15 (later A19) for a major US credit card company. Yes, Unisys A-series use 48-bit words (we used six 8-bit bytes), and they're a monster pain in the ass to program COBOL on. They don't pack and store their numeric data in the same way as IBMs (translation: Everybody Else In The World) do it. Packed fields could actually be fractional bytes--a 7-digit field would be 3.5 bytes--and the next field would start in the middle of that fourth byte. Plus they put the sign on the front of the field, instead of the end. And in general, their OS made me weep for the days of TOPS-20 or VMS. CANDE was the suckiest editor I ever had the displeasure of using, especially after 3 years of ISPF and 3 years of vi.

    Sadly, I never got to program on that '2060, just play at being an operator. Oh, and occasionally call the DEC service center in Colorado Springs, when something went haywire. I remember watching some tech there take over our machine through the 1200-baud modem, as his commands echoed over the console. Hey, at 16, I thought that was some cool shit. :)

    Didn't those DECSYSTEM-20s have a PDP-11 in there as some sort of front-end processor? I seem to remember my boss telling me there was a PDP-11/43 in there somewhere...like I knew what a PDP-11/43 was at age 16 growing up in rural Virginia. I was too busy checking out the student op's 34Cs. :)

  • OK, we're both making mistakes here.

    SIXBIT and RAD50 were different OK. I was wrong.

    RADIX50 was a 40-character set system. The "50" was an octal number :-) I have no idea why it was done that way.


    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • RP04, RP05, and RP06 all looked like washing machines. If you leaned on the cover, it would pop open and the drifve would spin down on you.

    Remember the cleaning brushes that would come out when the drive spun up?



    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • DECWAR was popular within DEC.

    I also remember SNAKE and TANK -- two good multi-user VT100 graphic games.

    I also remember when ADVENTURE and DUNGEON first came out. Lost 5 months of my life to those games!



    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • I knew someone that started a PDP-11 RSX BBS running in his basement. When the next month's electric bill showed up and was several hundred dollars more, he killed the whole thing.


    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • Why is your sig "Lotus Super Seven"?

    visit http://ftp.uk.linux.org/~kgb/Caterham7, then email me :-)


    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • I have the front panel to a DEC PDP-11 (purple triangle switches) hanging on the wall of my garage.

    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • 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).



    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • You aren't the only one with a head crash story like that. I remember one site where their RP04 disk was operating so fast, that the heads came off and smashed the drive cover.

    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 :-). It was fun toggling in boot programs.

    ---

    Keith Barrett (kgb)
    Red Hat HA Team

  • What do you want then?

    I guess we'll all have to go back to DEC-20's then, and abandon our "Athlon, Geforce, and latest Redhat."

    - Ando
  • Wowzo, I'd forgotten that little tidbit - I actually /do/ remember those days - download the latest host table every week, what's DNS?

    Oh, that .ARC file you downloaded is corrupted? You probably used binary and not tenex!

    Thanks for the trip back.
  • I remember the days. I came in right at the end of when JA Net could have been considered as something separate from the Internet; it still had its own protocols (I never knew much about them, but I do remember numeric addresses that were about 15 digits long with no separators), and its own conventions (they were starting to adopt internet naming, but a lot of stuff was backwards... eg uk.ac.warwick rather than warwick.ac.uk).

    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?

  • Al Aho, Peter Weinberger & Brain Kernighan [as you mentioned], if you care...
  • 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.
  • 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
  • Disclaimer:
    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 .sig i usually try to think of something witty everytime.

  • Re:byte? 8 bits? (Score:2)

    by Anonymous Coward
    Actually, the PDP-10 supported variable-width bytes. The hardware byte pointer concept allowed you to create byte pointers to bytes of arbitrary widths.

    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.

  • why 32? (Score:2)

    by hawk ( 1151 )
    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.
  • I really don't think that for example Intel hardware is designed for mission-critical situations.

    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 [sequent.com] show.

  • There was a line of IBM mainframes 8360 (used to run VM/ESA stuff) that had 31 bit CPUs!

    No, those were 32-bit CPUs (in the sense of having 32-bit general registers), like all IBM S/3x0's; they just happened to have 31-bit virtual addresses, unlike earlier S/3x0's, which had 24-bit virtual addresses even though they had 32-bit registers. (At least on the ones with 24-bit addressing, the uppermost 8 bits of the address were ignored - just like the original 68000; the 31-bit S/3x0's had a mode bit so they could run applications in 24-bit mode, in case somebody'd stuffed extra data into the upper 8 bits of pointers, relying on them being ignored. I think similar problems cropped up when Apple went from the 68000 to the 68020 in Macs.)

  • BBN sold an OS for the '10 called TENEX, and when TOPS-20 came out (looking quite like it in some respects)

    I'd been under the impression that DEC had {bought,licensed,whatever} TENEX and turned it into TOPS-20, i.e. the reason TOPS-20 looked quite like TENEX was that it pretty much was TENEX.

  • I dunno what OSes you might run on them apart from Ultrix and possibly OSF/1.
    NetBSD [netbsd.org]? ("NetBSD/pmax is the port of NetBSD to Digital Equipment Corporation's MIPS based computers. NetBSD/pmax runs on wide range of DECstation and DECsystem family. NetBSD/pmax is the first port which can run on either MIPS R3000 processors or MIPS R4400 processors; single kernel can run common set of user programs.")
  • Unlike C, there's absolutely *nothing* in Ada that requires a particular byte or word size, or requires two's-complement arithmetic. A 36-bit one's-complement machine poses no special challenge for Ada.

    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.
  • I think the IBM 360 architecture was the first really popular range to support 8 bit bytes and 32 bit words - it was also the first time a consistent instruction set architecture was defined over a range of machines of varying size, using microcode. All these features are still used in most CISC processors, such as Pentiums.

    Some supporting URLs:

    - http://www.dg.com/about/html/ibm_360.html
    - http://www.cs.uiowa.edu/~jones/assem/notes/05.html (search for '360')
  • ``You aren't the only one with a head crash story like that.''

    Oh, I'm certain of that. You tended not to believe those stories until you experienced one first-hand.

    ``It was fun toggling in boot programs.''

    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!)
    --

  • Whoa...

    I think I'm having an ASCII FORTRAN and FORTRAN V flashback!



    --

  • ``...TOPS-20.

    Gods, what a weird OS that was...''

    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.



    --

  • I met a guy at DECUS years ago who was running a PDP-11/45(?) (essentially an 11/70 w/o cache) in his basement. Like the 11/70, I believe these needed three-phase power to run. I suppose you could rework all the power supplies to avoid the hassle of three-phase but that doesn't do much about the current draw. This guy's electric bill must have been something! The UNIBUS and MASSBUS PDPs could be serious power hogs.

    You could have run RSX quite nicely on a Q-bus PDP-11 that wouldn't have emptied out your bank account. I actually considered it but I couldn't scrounge up a 9-track tape drive to do the OS load. And a good thing, too! The tape drive would have really run up the electric bill.



    --

  • Gee... I thought I was the only one.

    I have hanging on the wall in the den:

    • a PDP-11/70 front panel (the magenta style).
    • a PDP-8 front panel (that mustard-yellow style; were there others?).
    • a platter from a crashed RK06 pack.
    • a core memory board from an 11/70.
    • a KIM microcomputer (in case of emergency :-) ).

    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).



    --

  • 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.

    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?

    --

  • 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.
  • Stop thinking in powers of two! There is nothing in the universe that requires a byte to be eight bits. A byte is a set of (consecutive) bits used to represent a character. Nowadays, it just happens to be eight bits on most architectures.

    If you read some RFCs, for example you will see that IP datagrams consist not of bytes, but octets, and words are defined, not assumed, to be 32-bits.

    Look at the Jargon file. You'll see byte [tuxedo.org]'s proper definition as "A unit of memory or data equal to the amount used to represent one character; on modern architectures this is usually 8 bits, but may be 9 on 36-bit machines. Some older architectures used `byte' for quantities of 6 or 7 bits,"

    Have you ever wondered why C uses octal? Or why Unix (and therefore chmod(1)) takes octal numbers for permissions? It's because C and Unix were initially developed on 36-bit DEC machines. A 36-bit word has four 9-bit bytes, each represented by three octal digits.

    Honestly.

    --

  • 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!
  • Remember, SIMTEL20 was a DECsystem-20, running TOPS-20.

    Gods, what a weird OS that was...
  • Yeah, but it ain't the same as finding SIMTEL20.ARPA, and having to know to set TENEX...
  • 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?
  • The only DEC machines NetBSD will work on are VAX'es, MIPS'es, Alpha's, and Intel's. Ultrix only ran on VAX'es and MIPS'es. Neither works on any of the 16 bit or 36 bit DEC machines.

    What you have to understand is that the culture of the 36 bit machines was very mainframe, and nobody who is interested in them is interested in anything to do with Unix.

    The whole point of collecting exotic hardware is to be able to run exotic software (i.e. anything BESIDES Unix - especially a mass-consumed, homogenized Unix like NetBSD).

    Also, the machines are extremely large, expensive, and costly to operate; there are very, very few installations of these machines by hobbyists (and few/none elsewhere), thereby severely limiting the potential audience for it.
  • Well, a lot of the 36 bit machines were 6x6bit, so you would fit 6 characters into one word (DEC had a 6 bit ASCII type endoding system). Some of these OS'es had six character filename limits (i.e., so it could fit in one word). There are still some vestiges of this around today (e.g., DECnet still has a 6 character hostname limit), which I'm not sure if they're related to 36-bitness.
  • Think "DEC". Think "Boston". Think "MIT". Think "AI". Think "Lisp". Think "lists". Think "cons cell". Think "car" and "cdr". The 20 had instructions for manipulating 18-bit halfwords. Each 18-bit half-word could store an address. Thus, each 36-bit full-world could store a cons cell. And yes, I still have a copy of my SYSDPY.INI file.
  • 8 bits is addressable by 3 bits in the instruction. It's a "clean" binary number. Same with 16 32 and 64. It makes engineering opcodes just a little bit easier.

    Think about it: if you can encode a 34 bit shift, you have the bits to encode a 63 bit shift. With only 36 bits to shift, you end up with a huge hole in your instruction space. If you use those spare encodings for 'special functions' then you end up with a messy opcode map (not too nice for the microcode).

    All in all, it's just nicer if your bit count is a power of two.
    `ø,,ø!

  • Reminds me of the mantra:

    4 bits in a nibble
    2 nibbles in a byte
    The size of word depends on how big your buss is.
    `ø,,ø!

  • The IBM 709 /7090 / 7094 were the Fortran machines of the day. They had 36-bit words to get enough precision to do useful computation without resorting to double-precision, which took longer and swallowed too much memory (all 32K WORDS of it).

    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...

  • Well, lex is relatively obvious, but the others...
  • anyone remember SIXBIT?

    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!

    --

  • I found a good list of 'em here [google.com]:

    word size char size chars/word architecture Company

    16 bits 8 bits 2 Mini/Micro Intel,Moto,DEC,DG
    24 bits 6 bits 8 PDP?? DEC
    24 bits xxxxxx ? DSPs TI,Moto
    36 bits 6 bits 6 1100 Univac/Sperry/Unisys
    36 bits 6 bits 6 GCOS 8 GE/Honeywell/Bull
    36 bits 9 bits 4 1100/2200 Sperry/ Unisys
    36 bits 9 bits 4 GCOS 8 Honeywell/Bull
    48 bits 6 bits 8 A/B series Burroughs/Unisys
    48 bits 8 bits 6 A/B series Burroughs/Unisys
    60 bits 6 bits 10 6000 CDC
    60 bits 7 bits 8 6000 CDC

    God I must have some work to do!!


  • What do you want then?

    I think the poster is referring to the fact that computer technology to most young people nowadays means PC-class computers (or at best a Sparc platform) in their house or on their office desk. They rarely have access to large TPM environments.

    The days at wonderlust at a piece of "big iron" are long fading, though I get to play with an E10k sometimes (but it's live, so I can't 'tinker' :-)

  • A bit of detective work on google found the following info [adaic.org] 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!

  • ... and Ahmdal are still making them!! Amdahl will continue manufacturing its existing 31-bit S/390-compatible systems until March 2002 and will continue to provide service and technical support until 2007

    Where will it all end? ;-)

  • >I think I'll print this out for my Grandma to read!

    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

  • And at one point, our system was infested by a cabal of teenagers from a nearby prep school, who had broken in by exploiting a bug in the login process. They had their way with the system for several weeks before they were detected, and it took several days of round-the-clock work to eradicate the numerous trap doors and time bombs they had left behind.

    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.

  • I actually logged into the system mentioned in this article, presumably right before it was unplugged, since it was in the 87-88 timeframe.

    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 /mine mine mine/, not some university's!
  • If someone came up with a 68bit (for instance) architecture nowadays we'd all be on /. accusing them of smoking crack!

    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.

  • 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.

    Any system one doesn't know well appears "user unfriendly". That's true for mainframes, UNIX machines, Windows, and even the Macintosh.

    And to get good at any system requires quite a bit of effort. The only area systems like Macintosh differ in is that they make it easy to get started (good for sales and motivation). Once you are over the initial hump, they are as complex as everything else.

    Of course, some systems really do suck, even when you know them well...

  • One of the advantages of using 36 bits is that you can have the 32 bit types everybody expects (int, IEEE float), and still have a few bits over for type tags, to distinguish pointer types from numerical types. That way, when you read a word of data from memory, you'd know whether it was, say, a floating point number or a pointer before you dereference it. That would be helpful for making C/C++ code safer, and help even more with the compilation of Java, Python, Smalltalk, and other languages.

    In the future, you are probably going to see a lot more people treating 64 bit machines as "32 bit machines with a few extra bits in each word", for just that reason.

  • I agree that the UNIX command line is a bit deficient in new-user-handholding: it won't prompt you or converse with you. On the other hand, UNIX documentation used to be easy to get to, relevant, and concise, making up for the simplistic command line to some degree. Keeping the UNIX command line interface simple also made it easier for people to develop new command line tools for UNIX. And many UNIX systems (actually, probably the majority of commercially deployed UNIX systems) have excellent menu systems to help inexperienced users.

    As someone who has used TOPS, I appreciated the hand it held out to new users. But once you got a little below the surface, I found it was the same as any other system: where it was simple it was simple because it was limited, and where it wasn't limited, it was as complex as anything else. I didn't think it was significantly better overall than UNIX.

  • 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.

  • byte? 8 bits? (Score:3)

    by hawk ( 1151 ) <hawk@eyry.org> on Thursday January 18, 2001 @05:47AM (#499286) Journal
    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 . . .)

  • You're not fooling me! (Score:3)

    by quamper ( 229753 ) on Thursday January 18, 2001 @04:53AM (#499287) Homepage
    "A nontechnical reminiscence ..."

    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!

  • What a great read (Score:3)

    by baptiste ( 256004 ) <mike@baptis[ ]us ['te.' in gap]> on Thursday January 18, 2001 @05:53AM (#499288) Homepage Journal
    That was a great read. While I didn't get to touch a mini or mainframe system until I went to RPI in 1988 (PCs were just starting to become widespread), I remember many days of going to work with my Mom who was a mainframe programmer all her life from the late 1960's on. Talk about awe inspiring.

    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.

  • 36bit architecture (Score:5)

    by doctor_oktagon ( 157579 ) on Thursday January 18, 2001 @04:49AM (#499289)
    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*

    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 /. accusing them of smoking crack!

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close