Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Remembering 36-bit DECs

Hemos posted more than 13 years ago | from the looking-back-on-the-past dept.

Digital 122

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

cancel ×

122 comments

All modern x86 Processors are 36 bit, sort of (1)

Anonymous Coward | more than 13 years ago | (#499168)

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.

On Unisys 2200's, some stuff is six-bit FIELDATA. (1)

Richard Steiner (1585) | more than 13 years ago | (#499169)

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)

Memories of Columbia days (1)

Yeechang Lee (3429) | more than 13 years ago | (#499170)

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.

DECWAR, SITWAR, VTTREK (1)

Clith (5063) | more than 13 years ago | (#499171)

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.

Re:Hooray for sarcasm (1)

deity (8806) | more than 13 years ago | (#499172)

Aho (of AWK fame) also taught at Columbia for quite a while.

so, why 36? (1)

ch-chuck (9622) | more than 13 years ago | (#499173)

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!

Re:byte? 8 bits? (1)

swb (14022) | more than 13 years ago | (#499174)

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.

Re:so, why 36? (1)

Knight of the Sad Co (22131) | more than 13 years ago | (#499176)

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

Re:so, why 36? (1)

artg (24127) | more than 13 years ago | (#499177)

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

Hooray for sarcasm (1)

pstevenson (24978) | more than 13 years ago | (#499178)

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]

Re:byte? 8 bits? (1)

mwood (25379) | more than 13 years ago | (#499179)

Correct: PDP-10 bytes may not cross word boundaries. Anything else is permitted.

Re:byte? 8 bits? (1)

mwood (25379) | more than 13 years ago | (#499180)

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

Re:36 bit? Sounds as kludgy as 53 bit ATM (1)

mwood (25379) | more than 13 years ago | (#499181)

It allowed DEC to make more use of those 18-bit PDP-1 memory planes they had lying around? :-)

Re:DECprocessors (no NOT alpha) (1)

mwood (25379) | more than 13 years ago | (#499182)

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.

Re:SIXBIT anyone? (1)

mwood (25379) | more than 13 years ago | (#499183)

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

Re:User Friendliness (1)

Kevin T. (25654) | more than 13 years ago | (#499184)

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.

Re:so, why 36? (1)

Neil Franklin (32480) | more than 13 years ago | (#499185)

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.

--

Re:so, why 36? (1)

theonetruekeebler (60888) | more than 13 years ago | (#499186)

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

--

Re:Hooray for sarcasm (1)

sconeu (64226) | more than 13 years ago | (#499187)

Yes, Kernighan was a brain, but his first name is Brian.

Re:That's not even that weird (1)

haggar (72771) | more than 13 years ago | (#499188)

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!

That's not even that weird (1)

haggar (72771) | more than 13 years ago | (#499189)

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

Tops 20 vs Unix (1)

dmoen (88623) | more than 13 years ago | (#499190)

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

dsw == delete from switches (1)

dmoen (88623) | more than 13 years ago | (#499191)

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

DECsystem 10 in a museum (1)

Mark of THE CITY (97325) | more than 13 years ago | (#499192)

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.

Re:Memories of Columbia days (1)

Capablanca (100250) | more than 13 years ago | (#499193)

Outed! By an Anonymous coward! Sounds like Carbo-loado to me.

Re:so, why 36? (1)

Capablanca (100250) | more than 13 years ago | (#499194)

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.

Re:Memories of Columbia days (1)

Capablanca (100250) | more than 13 years ago | (#499195)

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

Re:DECWAR, SITWAR, VTTREK (1)

lotussuper7 (134496) | more than 13 years ago | (#499199)

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.

Re:The first real MUD was on DEC (?) (1)

lotussuper7 (134496) | more than 13 years ago | (#499200)

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.

Re:36bit architecture (1)

doctor_oktagon (157579) | more than 13 years ago | (#499201)

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?

Re:What's up with this topic? (1)

green pizza (159161) | more than 13 years ago | (#499202)

Correct

What's up with this topic? (1)

green pizza (159161) | more than 13 years ago | (#499203)

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*

Boy the way Glenn Miller played... (1)

marlowe (179270) | more than 13 years ago | (#499204)

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

Jeez, this brings back memories (1)

Moose4 (182029) | more than 13 years ago | (#499205)

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

Re:Jeez, this brings back memories (1)

Moose4 (182029) | more than 13 years ago | (#499206)

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

Re:SIXBIT anyone? (1)

kbarrett (191847) | more than 13 years ago | (#499207)

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

Re:Jeez, this brings back memories (1)

kbarrett (191847) | more than 13 years ago | (#499208)

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

Re:DECWAR, SITWAR, VTTREK (1)

kbarrett (191847) | more than 13 years ago | (#499209)

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

Re:DECprocessors (no NOT alpha) (1)

kbarrett (191847) | more than 13 years ago | (#499210)

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

Re:The first real MUD was on DEC (?) (1)

kbarrett (191847) | more than 13 years ago | (#499211)

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

Memories (1)

kbarrett (191847) | more than 13 years ago | (#499212)

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

Re:SIXBIT anyone? (1)

kbarrett (191847) | more than 13 years ago | (#499213)

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

Re:What's up with this topic? (1)

Ando[evilmedic] (199537) | more than 13 years ago | (#499215)

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

Re:Ah, those were the days... (1)

JaredLeto (225482) | more than 13 years ago | (#499216)

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.

Re:Hooray for sarcasm (1)

tolan's my name (234431) | more than 13 years ago | (#499218)

Al Aho, Peter Weinberger & Brain Kernighan [as you mentioned], if you care...

60-bit machine at UT Austin in the mid 80's (1)

Nick Driver (238034) | more than 13 years ago | (#499219)

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.

Re:DECprocessors (no NOT alpha) (1)

Trevlig (240776) | more than 13 years ago | (#499221)

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

DECprocessors (no NOT alpha) (1)

Trevlig (240776) | more than 13 years ago | (#499222)

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.

Why 36 bits? Here's why .... (1)

sales_worldwide (244279) | more than 13 years ago | (#499223)

For the same reason a local company in Brighton, UK, used to have, wait for it .... a 17 bit computer (called a Molecular - "Molly" to friends - she was even water cooled.)

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?

Re:36bit architecture (1)

jmcneill (256391) | more than 13 years ago | (#499224)

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.

Re:User Friendliness (1)

suwain_2 (260792) | more than 13 years ago | (#499225)

...utilities like sed, grep, awk, lex, and yacc, whose functions should be obvious from their names.

It took me a minute to realize this was sarcasm!

36 bit? Sounds as kludgy as 53 bit ATM (1)

typical geek (261980) | more than 13 years ago | (#499226)

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.

I'm all weepy (1)

slasherr (262186) | more than 13 years ago | (#499227)

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.

The first real MUD was on DEC (?) (1)

rednax (305483) | more than 13 years ago | (#499233)

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?

Re:The first real MUD was on DEC (?) (1)

rednax (305483) | more than 13 years ago | (#499234)

Not the same MUD - the one I refer to was simply called MUD. I think it was written by Richard Bartle (?) - the name rings a bell anyway - and may have been written in something like BCPL(?)

Re:Jeez, this brings back memories (1)

fuat (306413) | more than 13 years ago | (#499235)

Yeah, this brings back memories. Funny thing is I was trying to port CCMD and MM to RedHat this week. They were RP06 drives, by the way. I still have a couple of platters from an old pack. They had smaller RA81 and RA82 removable packs on the VAXen.

Re:Ah, those were the days... (1)

fuat (306413) | more than 13 years ago | (#499236)

Looks like the SIMTEL20 archives live on at http://www.simtel.net/simtel.net/ [simtel.net] .

Re:I'm all weepy (1)

fuat (306413) | more than 13 years ago | (#499237)

We have two copies of Gorin at home. I think I still have a JSYS manual too. :-) %DECSYSTEM20 not running.

Emulators (1)

Harris Newman (306599) | more than 13 years ago | (#499238)

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

Re:DECWAR, SITWAR, VTTREK (1)

Harris Newman (306599) | more than 13 years ago | (#499239)

Actually, DECWAR was my first multiplayer game on a computer. It was very user friendly, and very additictive. I guess thats why Kesmai modified the University of Texas's licensed source code and used it specifically for profit. See a clip from the license in the source code: This agreement grants a royalty free, nontransferable, and nonexclusive right to use the following software: DECWAR.FOR FORTRAN source WARMAC.MAC MACRO source DECWAR.RNH help file source 1. All publications, reports, developments, etc. relative to this material should acknowledge the authors and The University of Texas at Austin. 2. Neither this software, adaptations thereof, nor services resulting from it's use should be sold, leased, or distributed to any individual or organization without prior written consent of the authors. 3. Any modifications to or adaptations of this software should be made available on request, and without charge, to the authors or The University of Texas Computation Center. Jee, I guess Kesmai (now Gamestorm @ http://www.gamestorm.com/company/) forgot to read that license when they bought the source for a measly $50 and modified it to be Megawars on Compuserve. Megawars ran on Compuserve for over 10 years! The game I am developing is simular to Decwars, in the commands, but will support up to 1024 users. It runs on Freebsd, and instead of using the Tops-10 command line entry, it uses Tops-20 style parsing. See CCMD at Columbia University for that.

Re:DECprocessors (no NOT alpha) (1)

Bjorn Hell Larsen (306676) | more than 13 years ago | (#499240)

You're right, I was a bit too quick on the Submit button on that one. Sorry, and thanks for the correction.

bhl

Re:Jeez, this brings back memories (1)

Bjorn Hell Larsen (306676) | more than 13 years ago | (#499241)

Yes, the PDP-10s had PDP-11 console frontends for diagnostics and boot. They ran a specialized OS named RSX-20F.

Before networking became an option, it was also usual to have a number of PDP-11-based terminal server frontends.

(Newer PDP-10-based system such as the DECSYSTEM-2065 and DECSYSTEM-2020 had integrated LSI-11 CPU frontends. For us that were used to the full-size PDP-11 systems provided with systems such as the DECsystem-1099, this was kind of a letdown.)

bhl

Re:SIXBIT anyone? (1)

Bjorn Hell Larsen (306676) | more than 13 years ago | (#499242)

RADIX50 was used by LINK to store symbol names in .REL and .UNV files.

bhl

Re:byte? 8 bits? (2)

Anonymous Coward | more than 13 years ago | (#499245)

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? (2)

hawk (1151) | more than 13 years ago | (#499246)

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.

Re:36bit architecture (2)

sql*kitten (1359) | more than 13 years ago | (#499247)

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.

Re:36bit architecture (2)

Eric Smith (4379) | more than 13 years ago | (#499251)

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.

Re:36bit architecture (2)

hpa (7948) | more than 13 years ago | (#499252)

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.

Re:why 32? (2)

Cato (8296) | more than 13 years ago | (#499253)

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

Re:On Unisys 2200's, some stuff is six-bit FIELDAT (2)

rnturn (11092) | more than 13 years ago | (#499255)

Whoa...

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



--

Re:You're not fooling me! (2)

rnturn (11092) | more than 13 years ago | (#499256)

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



--

Re:DECprocessors (no NOT alpha) (2)

rnturn (11092) | more than 13 years ago | (#499257)

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.



--

Re: Front panels (2)

rnturn (11092) | more than 13 years ago | (#499258)

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



--

Re:byte? 8 bits? (2)

AME (49105) | more than 13 years ago | (#499259)

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?

--

User Friendliness (2)

Hard_Code (49548) | more than 13 years ago | (#499260)

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.

Re:so, why 36? (2)

theonetruekeebler (60888) | more than 13 years ago | (#499261)

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.

--

Re:You're not fooling me! (2)

sconeu (64226) | more than 13 years ago | (#499263)

Remember, SIMTEL20 was a DECsystem-20, running TOPS-20.

Gods, what a weird OS that was...

Re:Ah, those were the days... (2)

sconeu (64226) | more than 13 years ago | (#499264)

Yeah, but it ain't the same as finding SIMTEL20.ARPA, and having to know to set TENEX...

Maybe we should bring them back (2)

Mr. Protocol (73424) | more than 13 years ago | (#499265)

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?

Re:DECprocessors (no NOT alpha) (2)

VAXman (96870) | more than 13 years ago | (#499266)

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.

Re:so, why 36? (2)

VAXman (96870) | more than 13 years ago | (#499267)

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.

Re:36 bit? Sounds as kludgy as 53 bit ATM (2)

Capablanca (100250) | more than 13 years ago | (#499268)

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.

36 Bits: Fortran made them do it (2)

SouthendPier (126056) | more than 13 years ago | (#499271)

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

Re:Hooray for sarcasm (2)

joto (134244) | more than 13 years ago | (#499272)

Well, lex is relatively obvious, but the others...

SIXBIT anyone? (2)

TheGratefulNet (143330) | more than 13 years ago | (#499273)

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!

--

Re:so, why 36? (2)

doctor_oktagon (157579) | more than 13 years ago | (#499274)

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

Re:What's up with this topic? (2)

doctor_oktagon (157579) | more than 13 years ago | (#499275)


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

Re:36bit architecture (2)

doctor_oktagon (157579) | more than 13 years ago | (#499276)

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!

Re:That's not even that weird (2)

doctor_oktagon (157579) | more than 13 years ago | (#499277)

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

Re:You're not fooling me! (2)

kbarrett (191847) | more than 13 years ago | (#499278)

>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

Skr1pt k1dd33z in the '70s! (2)

b1t r0t (216468) | more than 13 years ago | (#499279)

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.

Ah, those were the days... (2)

JaredLeto (225482) | more than 13 years ago | (#499280)

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!

the driving factor is C/C++ (2)

q000921 (235076) | more than 13 years ago | (#499281)

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.

Re:User Friendliness (2)

q000921 (235076) | more than 13 years ago | (#499282)

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

Re:36 bit? Sounds as kludgy as 53 bit ATM (2)

q000921 (235076) | more than 13 years ago | (#499283)

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.

Re:36bit architecture (2)

jmcneill (256391) | more than 13 years ago | (#499285)

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? (3)

hawk (1151) | more than 13 years ago | (#499286)

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

quamper (229753) | more than 13 years ago | (#499287)

"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 (3)

baptiste (256004) | more than 13 years ago | (#499288)

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 (5)

doctor_oktagon (157579) | more than 13 years ago | (#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!

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...