Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Old farts reminiscing about computers

This site may earn commission on affiliate links.
Statute of limitations has expired... tell us yours and I might tell you mine (IBM 360/50 and CDC Cyber 72 and one of the first 10 Unix PDP-11s).

Ok, I'm glad I found this write-up I did on another forum, so I don't have to type it all out again.

We had a Univac 1100 at college in the early 80's. I did a lot of cool stuff on that machine. Being a young, curious freshman, I would spend hours reading the dusty system docs stored in the corner of one of the terminal rooms. I was also in a CS 101 class at the time. I found a command line utility that would really do a great job at re-formatting my PASCAL programs. Nobody else knew of this internal program (and it's dozen of command line params to make it work really well and customize how it formatted the programs). So I told a few friends. They started to use it. So, to help out everyone in the CS 101 classes (hundreds of engineering students), I made a public command file that embedded all the complex parameters and returned the formatted program. Then EVERYONE started using my little public batch file.

Then I got the neat idea that since people are submitting their code (read: homework) to my formatter, I could copy their code into my private directory for later "analysis". So I started getting copies of everyone else's homework. That was fun to review (although I was better than 95% of the class, most of the code was crap). But it started taking up too much space in my account, so I turned it off. And no, I never turned in or used anyone else's' code for my own homework assignments. I always completed the assignments long before anyone else.

But then the administration caught wind of my little program and that everyone was using it to format their assignments. They made a very strongly worded announcement to all CS classes that nobody was allowed to use this utility, and if anyone did, they would get a failing grade on their assignments. "People must learn good code formatting themselves, and not rely on an automatic tool". Of course, that was an empty threat, because there was no way they could actually tell if someone was just really good at formatting their program, or the utility did it the exact same way. Anyway, I was forced to remove the public script, but I continued to use it and showed a few friends how to access the command line tool.


The second thing I did was a lot worse. ;) During the summer sessions, I got a job as a "consultant" in the terminal rooms to help summer students with CS assignments and usage of the UNIVAC. There was a skeleton staff during the summer, usually just one main system operator and someone to kick the printer and distribute the printouts, and me. Well, occasionally the main sysop would leave for dinner and ask me to "watch over" things while she was gone. Of course, being a good sysop and security minded, she would log out of her admin terminal before leaving.

So I would logon to my account while in her office. This one time (before phishing was a thing), I wrote a little script to run in my account that would spoof the actual logon screen, capture her login, password, and account code, write it out to my account, then log me out, and present a real logon page. So I'd just leave that running right before she got back.. I then started running it on terminals in the main computer room, too. The only problem was (1) the session would timeout in about 2 minutes, and (b), if someone happened to come up and hit CTRL-C (or whatever the break command was), they'd have open access to my account. So I didn't do that too much.

Then there was the time I was actually caught red-handed trying to hack (unsuccessfully) into my boss's (a CS grad student) account late one Friday night I was walking home drunk past the computer room. LUCKILY nothing happened, but I was sure I was going to be suspended or expelled for that one.
 
Well, I promised. My time at the university was the very beginning of the minicomputer era. There were three "power blocks" on campus, and it was very politicized. The main one was, of course, the computer center with its CDC Cyber 72. Another was Administrative Computing, which had the retired IBM 360/50, but actually still did most of the scientific computing work after hours. I was the 4pm-midnight operator for this computer for much of my second year of undergrad CS. The third was the Computer Science department. The power play was that the computer center wanted ALL the budget for computers, which they would then allocate for teaching. CompSci wanted at least some power to have hands-on teaching.

The Cyber architecture supported "Remote Batch Terminals", which you could buy from CDC for an outrageous amount. But DEC had an RBT application that would run under their operating system for the PDP-11, and these were actually cheaper than CDC's RBTs. So the campus bought 12 of those, and distributed them around. But that didn't satisfy CompSci, since DEC's RSX operating system was totally unsuited for teaching. Unix had just been announced by Bell Labs, so we wrote off and got a distribution of that, and over the end-of-year break (summer in Oz) a few of us pre- and post-grad students got together and wrote an RBT program for Unix V5. That allowed us to use the PDP-11 for teaching while still performing its day job of being a batch terminal (card reader and printer station) for the Cyber.

Here's where things started to get interesting and acrimonious. On a real RBT, the operator(!) would put the cards in the card reader, and type the "r" command, to tell the Cyber to start reading cards. The Cyber would read one or a few cards, then get around to reading more when it felt like it. Similarly for the "p" command and the printer. Everyone knew that your job went quicker if you just sat there typing "r" and "p" and "q" (to see the job queue) commands. So of course our emulator on Unix just did that for us. But this meant (and it was demonstrable) that jobs submitted at CompSci finished faster than jobs submitted anywhere else, even at the main computer center! First Mechanical Engineering, then Physics, and one other (forget who) converted their PDP-11s to run Unix with our help. (Great job for a poor undergrad like me, didn't have to do shift work any more.)

The computer center hated this and actually tried to get some of the professors in CompSci fired, so CompSci declared war. My personal little contribution to the war was the observation that even though there were very small and tightly controlled storage limits on accounts, the Cyber didn't check privileges on raw mass storage. So every now and then, I would allocate entire disk drives to random people, and jobs would start failing because they couldn't find storage. (A friend of mine has a coffee table whose top is a platter from one of these disk drives; about 24" across.)

The best trick wasn't one of mine, but should go down in history. The Cyber had a smaller computer (Peripheral Processing Unit, PPU, actually some number of them), and one of the PPUs jobs was to bootstrap the main CPU after a cold start. Cold starts were fairly rare; normal therapeutic reboots were just "warm starts". The PPU bootstrap program was 48 words of 12-bit instructions, represented by a panel of toggle switches like you'd buy at Radio Shack, with a little hex-nut holding them in position. No one ever bothered changing these switches; they had no other function. Somehow, someone, took one of the switches, loosened it, turned it upside down, retightened it, then flipped it. Everything looked perfectly normal, and nothing happened. Until the next cold start, which failed. The Cyber was down for about a week. I've been told that they actually flew in a replacement switch panel to fix it, but don't know whether that is true or not.

(I just realized that this means cyber-terrorism is at least 40 years old... since this all happened 76-77.)
 
  • Like
Reactions: HankLloydRight
The best trick wasn't one of mine, but should go down in history. The Cyber had a smaller computer (Peripheral Processing Unit, PPU, actually some number of them), and one of the PPUs jobs was to bootstrap the main CPU after a cold start. Cold starts were fairly rare; normal therapeutic reboots were just "warm starts". The PPU bootstrap program was 48 words of 12-bit instructions, represented by a panel of toggle switches like you'd buy at Radio Shack, with a little hex-nut holding them in position. No one ever bothered changing these switches; they had no other function. Somehow, someone, took one of the switches, loosened it, turned it upside down, retightened it, then flipped it. Everything looked perfectly normal, and nothing happened. Until the next cold start, which failed. The Cyber was down for about a week. I've been told that they actually flew in a replacement switch panel to fix it, but don't know whether that is true or not.
We had a paper tape boot strapper for a DEC PDP-15 that ran all sorts of specialized equipment and the basis of dozens of physics researchers projects. The rule was you never used the last paper tape when you rebooted (you had to reboot almost always because everyone used a different image). Of course periodically the paper tape reader would shred the tape. Once someone got lazy and ate the last one. There was no backup and the machine was basically bricked.

We were down for 90 days (we thought forever), before someone came back from sabbatical and happened upon a bootstrap tape tucked away in their filing cabinet.
 
My first "big iron" experience was a Burroughs B5500, followed by a Burroughs B6700 at school. Stack architecture, 51-bit words. The words had 48 bits of data and 3 bits to tell what the datatype was - integer, float, double, procedure reference, array... The most interesting instruction was "Value Call", which would convert the top of the stack into a value by doing whatever is necessary depending on the datatype. For an array, the Top of Stack was used as an index to get the appropriate entry. For a double, the second word of the value would be fetched. For a procedure reference, the procedure would be called which left the function value on the stack when it returned. If that value was an array reference or another procedure reference, the microcode would loop back and begin the process again until a final value was delivered. The flow chart describing VALC instruction took two pages (pp 7-16&17) in the manual.

So I wondered what would happen if a recursive function was defined that didn't terminate? In BASIC:

DEFINE FNA(X) = FNA(X)
PRINT FNA(1)

I typed it in and ran it. Nothing. A few minutes later, a system reboot message and login prompt. Well, I guess I won't do THAT again.

A few weeks later at two o'clock in the morning, I got an operator message saying the system was going down in five minutes for an OS upgrade. I messaged back "who is this?" "Burroughs technician." "Really? Wanna see something interesting?" "OK." I typed in my little BASIC program, hit run. System reboot message. Logged in. Operator message "How did you do that?" So I walked over to the computer room and demoed it for him. Since this was a "real computer" in the strong sense, it had a huge console with lights showing the entire processor state. In normal operation these lights are all merrily flashing all over. When we ran my program, the whole console absolutely froze.

So we took a look at the ASM code emitted by the BASIC compiler for my little demon. It turned out that the code for FNA was:

VALC FNA
RET

Since the value of X was already on the stack, the compiler optimizer realized the function could immediately call itself without any intermediate instructions. And the VALC instruction didn't need to do any memory operation to fetch either the argument or the next instruction, so it went into a hard microcode loop. Not even interrupts could get in -- no memory fetches, no new instructions, interrupts locked out.

The next version of the BASIC compiler emitted:

NAMC X
VALC FNA
RET

causing the address of X to be pushed onto the stack (unnecessarily), allowing interrupts to proceed and eventually crashing the program with a stack overflow. I'm guessing the fatal loop still exists in the microcode (if there are actually any B6700s still running out there), protected by a careful dis-optimization in the compiler documented by something like "Attention: DO NOT remove this line of code. A bad thing will happen."
 
  • Like
Reactions: snort
We had a paper tape boot strapper for a DEC PDP-15 that ran all sorts of specialized equipment and the basis of dozens of physics researchers projects. The rule was you never used the last paper tape when you rebooted (you had to reboot almost always because everyone used a different image). Of course periodically the paper tape reader would shred the tape. Once someone got lazy and ate the last one. There was no backup and the machine was basically bricked.

We were down for 90 days (we thought forever), before someone came back from sabbatical and happened upon a bootstrap tape tucked away in their filing cabinet.

What, too cheap to get Mylar tape for critical functions???
 
thanks for the memories, Tesla people.
I am turning 69 this week and was suffering from memory gapitis.
Reading your stories was a nostalgic therapeutic rush.
Actually, I did NOT invent the internet, as is often rumored, but my friend Billy and I did convert a Sanders desk shaped keypunch station into a functional mainframe user interface by wiring in a 24 character per line, 8 line Testing display and interfacing on an asynchronous interface controller using EXCP on a Mod 65 IBM 360. Of course we had to run BELOW the operating system to clear the interrupts before the OS could detect them. Since the personnel records were stored on that 65 we had a lot of fun with "pls type your name>"
on the pre-CRT CRT.
Oh, I hope the other poster was right about the statute of limitations!
 
Cool! At Upenn in the early 80's, that's all we had as freshman CS students. I remember it fondly. I also got into a bit of trouble with that machine on several occasions, which I can't really talk about here. :)
I was a CS major at Dartmouth in the late 80's. The US Army Corps of Engineers' Cold Regions Cold Regions Research and Engineering Laboratory (CRREL) was/is just north of campus. CRREL had a Convex C1 that they kept at Dartmouth's Kiewit Computation Center. In return for machine room space and operations support, CRREL allowed limited student access to the C1 (our main public Unix machine was an 11/785 running BSD 4.3)

One of the main student uses of the C1 was for homework assignments for the operating systems class. The C1 had shared memory and read-modify-write instructions, which allowed you to implement cross-process semaphores. We were working on our "Dining Philosophers" assignment (pickup shared fork, eat, release fork, think, repeat), and one of my classmates had a bug in his code (I think he didn't properly init the semaphore library).

Anyway, I vaguely remember a conversation that went like this - "Hey, watch this!", followed by a classmate running his program which brought down the entire system. After a reboot, he tried again.

After a couple of reboots, the operators did a "wall" asking whoever was doing it to stop, and email them the code so they could submit it to Convex with a bug report.
 
Under development I have Draconian (Bosconian)

This is now finished, even managed to get the Atari 2600 to play back the arcade speech samples!


The ROM is available here(link at the top of the post takes you to the current build). Can be played on real hardware via the Harmony Cart or on your computer via the current version of Stella. If you use Stella be sure to follow these instructions to reduce flicker (as computer monitors exaggerate it). You only need to do this the first time you load a new ROM.
  • open Draconian in Stella
  • press TAB on your keyboard for the in-game-menu
  • select Game Properties
  • Select the Display tab
  • change Use Phosphor to Yes
  • click OK
  • select Exit Menu
  • press Control-R on your keyboard to Reload the ROM
 
  • Like
Reactions: scaesare and tga
Surely there are young programmers that still code using assembly?

I was getting my Computer Science degree at the University of Missouri in the 90's, and before I graduated, you couldn't even take an assembly language course because they didn't offer it (word at the time was they didn't have anyone that could teach it). I was going to take an assembly course but couldn't because of that. However, I did have a class in my 2nd year I think it was that did machine language on a simulated microprocessor, which was very similar.

I highly doubt you'll find anyone young doing assembly, unless they are just a massive microprocessor nerd, or in a very obscure line of work that still uses assembly for some embedded systems.

My first PC experience was when my mom brought home an IBM PC that ran at 4.077 MHz I think it was, but it also had a Turbo button that would make it run at 10 MHz. Did my first programming in BASIC on that machine. Then I got into Turbo Pascal. In college it was mostly C and C++. And professionally, I've done a little COBOL, C#, and a boat load of Java. I've been on a Java web development track for close to 20 years now.

I still keep a few interesting trinkets I collected during the evolution of PCs. I still have a Kenwood TrueX CD-ROM drive that could quietly read at 72X by using 7 laser beams with a slower spin speed. And I still have a couple of SuperDisk drives (and some disks too), that were backwards compatible with 1.44MB floppy disks; one nice thing about those you might not be aware of is they could ready 1.44MB floppies faster than regular floppy disk drives.

Probably one of the most exciting PC advancements in the retail space for me as a kid was the introduction of the Sound Blaster. Moving from PC speaker to Sound Blaster was revolutionary to me.
 
  • Like
Reactions: evp and scaesare
This is now finished, even managed to get the Atari 2600 to play back the arcade speech samples!...

And some of us knew it as Bosconian in the arcades...
bosconian_marquee.jpg


Draconian (video game) - Wikipedia