Fun with Emulation #3 - Running a PDP-11/34 with RSTS/E under Ubuntu Linux

The first "real" computer system upon which I ever laid my hot little hands was a PDP-11/34 at Western Kentucky University.  I was attending WKU during the summer between my 11th and 12th-grade years of high school, and one of my typical "go see what's out there" walkabouts led me to the "computer center."  Now, there were several signs posted which suggested that ONLY those students taking SPECIFIC Computer Science classes could gain access to "the PDP", but I explored the terminal room anyway.  One of the admins came out and started throwing a tantrum about the mess left by all the students.  Inspiration hit - I quickly offered to stop by every afternoon and clean up the terminal room, if I could only get access to the PDP...and the deal was done.  I had no idea that TI Silent 700 terminals generated SO much waste paper.

Nonetheless, I was in.  I started playing around with RSTS/E, which was one of DEC's major operating systems in the educational arena, and BASIC-PLUS-2 was THE language of choice.  (Hey, this was 1980.)  One fine day, I was browsing the system tables and noted that there seemed to be 32 terminals connected to the system, although I counted only 24 in the computing center; when I asked, the admins just said, "Well, he gets a key to the closets."  As it turned out, these guys had commandeered closets (scattered throughout the science complex) and wired in either Silent 700 or--*GASP*--LA-36 DECWriter hardcopy terminals.  SCORE!  Printouts on which you could actually TAKE NOTES!  I spent a great deal of time in those closets, and I found that, yes, one COULD write device drivers in BASIC, given enough system calls.  One could also wreak havoc upon peripherals with PIP if you didn't know what you were doing.  I did both.

Bringing back RSTS/E turned out to be the easiest of my emulation projects to date.  After compiling the pdp11 simluator from the SIMH package (linked below), I found the RSTS V9 Archive, which provides a prebuilt, full image of RSTS/E V9.6 on an RP04 disk image; the latter site even provides configuration files for SIMH.  This was literally a ten-minute project, and I had RSTS/E up and running under Ubuntu Linux.  (RSTS/E is text-based only, so I won't bore you with a screenshot.)  If you're longing to write code like:

100 OPEN User_keyboard$ AS FILE #1

Tmp$ = SYS(CHR$(118)+CHR$(18))

LINPUT 'Enter the first line of text';User_input$

...then hie thee to the links below.

The Computer History Simulation Project

RSTS/E V9 Archive

 

Beer CAN Aid Your Memory!

As I've been playing with emulators, my knowledge of programming languages has been put to the test.  Sure, many of us can say that we've written code in dozens of languages, but how many of them can we REALLY remember today?  I'll be the first to admit that my recollection of many languages is somewhat fragmented and/or jumbled.

I was looking around for some ALGOL code when I happened across this wonderful resource.  Put simply, it celebrates the "99 bottles of beer" song from our childhood by providing code examples (in 1400+ programming languages!) that print the song in its entirety.  If one stops to think about it, such code must use simple computation, looping/test constructs, and text manipulation; I find reviews of this source code to be a WONDERFUL memory-jogging tool.  For instance, here's the MACRO-10 version I used to test my PDP-10 emulator. Enjoy!

99 Bottles of Beer

Fun with Emulation #2 - Running a DECSystem-10 on Ubuntu Linux

Fun with Emulation #2 - Running a DECSystem-10 on Ubuntu Linux

I can honestly say that the 36-bit DEC-10 was the machine that took me from "gee whiz, this is keen!" to actual coding/hacking. If one could schmooze a faculty member into signing the authorization form, students could get access to the DECSystem-10 (#1059) at the University of Louisville at a screaming 1200 baud.  I fell in with a group of similarly minded folks who were happy to share their knowledge, and that was that.  Within a week or so, I was writing my first assembler code; to this day, the early PDP instruction set is THE most intuitive, mnenomic assembler I've ever used.  I wrote my own (condensed) version of SYSTAT, played ADVENT (considered the first text-based adventure game, inspiration for PC Zork) and DECWAR (one of the greatest of the early computer games), and dove deep into machine internals for the first time.  I still remember the night we hacked the controller on one of the university's high-capacity copiers with a paperclip (this was 1981, remember) and spent 4 hours pirating the DEC-10 Monitor Calls Manual and Hardware Reference Manual.

In my current exploration of the emulation universe, I ran across SIMH, which emulates dozens of old minicomputer and mainframe systems.  I was delighted to learn that the PDP-10 is among them, and that ready-to-run images of TOPS-10 7.03 exist.  The build under Ubuntu Linux was near-trivial, and bringing TOPS-10 up went smoothly as well.  The result?

It may not be as visually impressive as are some emulators (notably Hercules Studio, about which I've already written), but it was incredibly satisfying to be working with MACRO-10 once more.  The TOPS-10 image I loaded supports COBOL, FORTRAN, BLISS-36, ALGOL and (of course) assembler, so my next project will be building DECWAR 1.2 from source.  In these days of IDEs, visual editors and code management systems of all types, there's something...GOOD about plain old text-mode coding.

If you want to join in my wave of digital nostalgia, you can find emulators and TOPS-10 images at the links below.

Next up: RSTS/E, or "Writing printer drivers in BASIC?!"

DEC PDP-10 Emulation
TOPS-10 pre-built image

Fun with Emulation - Running VM/370 under Ubuntu Linux

When I first arrived at university in 1981, I was planning to study Medical Technology (e.g. clinical pathology) with an eye toward medical school.  That all changed when, as part of the University Honors Program, we were given a tour of the Computing Center and I laid eyes on the school's IBM 3081 (later 3090) mainframe.   It basically filled the basement of the center, as you can see in this historical review from IBM, and we were told that it cost some then-obscene amount of money.  Well, the notion that I could basically command this thing to do my bidding flipped a switch inside my brain, and I was hooked.  Many were the hours spent punching cards, learning all the stuff they DIDN'T teach us in my PL/1 and assembler courses, and finally "graduating" to a 3270 terminal with XEDIT.  I spawned REXX and assembler code to do all sorts of things, and only a few of them landed me in compelled audiences with the Director of the Center and/or the Dean of Students (but those are other stories).

I had thought those days long gone...until last week.

Somehow, I stumbled across the Hercules project.  Long story short - these great folks have written a cross-platform emulator that allows one to run various IBM mainframe operating systems in virtual machines on Windows, Macintosh or Linux platforms.  Well, that was all I needed to see; I promptly downloaded the source tarball for the latest build of Hercules and compiled it on my ThinkPad T41 running Ubuntu 11.04.  A little bit of digging led me to Robert O'Hara's "Six Pack" build of VM/370 R6 (the public domain VM/370 release), and a bit of tweaking had that up and running.  The final piece of the puzzle was finding Hercules Studio, a GUI frontend for Hercules.  The end result is...well, this:

Yes, that's an x3270 session in the lower right, green screen and all.  The Sixpack VM/370 build comes with several programming languages (including GCC, ASMF, FORTRAN and REXX), so I'm ready to dust off some old code and get back to some old-school coding.  The interesting thing is that Hercules will apparently support z/Linux as well, so I'll be playing with that on the "real world" side of life.  If this strikes your fancy, start with Hercules and Hercules Studio at the links below.

The Hercules System/370, ESA/390, and z/Architecture Emulator
Hercules Studio

Next up - emulating other hardware (and operating systems) of my hacking youth...

Peeking Past the Proxy - Using Wireshark to Estimate "Second Hop" Latencies

Peeking Past the Proxy - Using Wireshark to Estimate "Second Hop" Latencies

When discussing network latency, most people only think about two adjacent endpoints; we aren't often called upon to evaluate latencies between intermediate devices along the network path.  Well, I was recently called upon to do just that, and--between documentation of the network path and knowledge of the protocols in use--I was able to take data from one endpoint and make reliable estimates of some intermediate latencies.  Consider the following packet capture, which illustrates the initiation of an SSL connection through an HTTP proxy:

Now, the first three packets--the TCP handshake--give us a straightforward indication of the network latency between the client and the HTTP proxy; in this example, it's roughly 12ms.  We then see our client issue an HTTP CONNECT method to establish a tunneled TLS connection to the true destination; here's where we put our higher-level protocol knowledge to good use.  We know that, according to the HTTP and TLS RFCs, the proxy device is not allowed to return a 2xx code to a CONNECT request unless/until its connection to the remote endpoint is complete.  So, then, the elapsed time between the proxy's ACK of our CONNECT request and its "200 Connection established" response is a reasonable measurement of the latency between the proxy and the device that is handling the "other end" of the TLS connection.  In this case, the latency we "see" is 132ms; however, we know that 12ms of that is the latency between the client and the HTTP proxy.  So, we can estimate the latency between the proxy and the "other end" of the TLS connection at 120ms.  Taking this a step further, the Client Hello/Server Hello exchange indicates a latency of 128ms (140ms raw - 12ms client-to-proxy-latency).

To be fair, these raw numbers include a certain amount of overhead, in that the proxy burns up a few milliseconds managing the transactions on both ends; still, taking this measurement over a collection of connections to the same destination can give us a reliable AND reasonable estimate of "effective latency" between not only points A (client) and B (HTTP proxy), but also between points B (proxy) and C (SSL termination at the destination).

You can't do this in every case of course, but the lesson is simple - the more you know and understand about the higher-level protocols (like HTTP and SSL/TLS), the more valuable your network analysis skills can be.  Go have fun with it!  If you don't have Wireshark, GO GET IT NOW...