hardware, restoration, software

Fixing 40-year-old Software Bugs, Part One

The museum had a big event a few weeks ago, celebrating the 45th anniversary of the 1st “Intergalactic Spacewar Olympics.”  Just a couple of weeks before said event, the museum acquired a beautiful Digital Equipment Corporation Lab-8/e minicomputer and I thought it would be an interesting challenge to get the system restored and running Spacewar in time for the event.

As is fairly obvious to you DEC-heads out there, the Lab-8/e was a PDP-8/e minicomputer in a snazzy green outfit.  It came equipped with scads of analog hardware for capturing and replaying laboratory data, and a small Tektronix scope for displaying information.  What makes this machine perfect for the PDP-8 version of Spacewar is the inclusion of the VC8E Point Plotting controller and the KE8E Extended Arithmetic Element (or EAE).  The VC8E is used by Spacewar to draw the game’s graphics on a display; the EAE is used to make the various rotations and translations done by the game’s code fast enough to be fun.

The restoration was an incredibly painless process.  I started with the power supply which worked wonderfully after replacing 40+ year old capacitors, and from there it was a matter of testing and debugging the CPU and analog hardware.  There were a few minor faults but in a few days everything was looking good, so I moved on to getting Spacewar running.

But which version to choose?  There are a number of Spacewar variants for the PDP-8, but I decided upon this version, helpfully archived on David Gesswein’s lovely PDP-8 site.  It has the advantage of being fairly advanced with lots of interesting options, and the source code is adaptable for a variety of different configurations — it’ll run on everything from a PDP-12 with a VR12 to a PDP-8/e with a VC8E.

I was able to assemble the source file into a binary tape image suited for our Lab-8/e’s hardware using the Palbart assembler.  The Lab-8/e has a VC8E display and the DK8-EP programmable clock installed.  (The clock is used to keep the game running at a constant frame-rate, without it the game speed would vary depending on how much stuff was onscreen and how much work the CPU has to do.)  These are selected by defining VC8E=1 and DKEP=1 in the source file

Loading and running the program yielded an empty display, though the CPU was running *something*.  This was disappointing, but did I really think it’d be that easy?  After some futzing about I noticed that if I hit a key on the Lab-8/e’s terminal, the Tektronix screen would light up briefly for a single frame of the game, and then go dark again.  Very puzzling.

My immediate suspicion was that the DK8-EP programmable clock wasn’t interrupting the CPU. The DK8-EP’s clock can be set to interrupt after a specified interval has elapsed, and Spacewar uses this functionality to keep the game running at a steady speed — every time the clock interrupts, the screen is redrawn and the game’s state is updated.  (Technically, due to the way interrupts are handled by the Spacewar code, an interrupt from any device will cause the screen to be redrawn — which is why input from the terminal was causing the screen flash.)

I dug out the DK8-EP diagnostics and loaded them onto the Lab-8/e.  The DK8-EP passed with flying colors, but Spacewar was still a no go.  I decided to take a closer look at the Spacewar code, specifically the code that sets up the DK8-EP.  That code looks like this (with PDP-12 conditional code elided):

/SUBROUTINE TO START UP CLOCK
/MAY BE HARDWARE DEPENDENT
/THIS IS FOR KW12A CLOCK - PDP12
/OR PROGRAMABLE PDP8E CLOCK DK8EP
   CLSK=6131      /SKIP IF CLOCK
   CLLR=6132      /LOAD CONTROL
   CLAB=6133      /AC TO BUFFER PRESET
   CLEN=6134      /LOAD ENABLE
   CLSA=6135      /BIT RESET FLAGS

STCLK, 0
   CLA CLL        /JUST IN CASE   
   TAD (-40       /ABOUT 30CPS
   CLAB           /LOAD PRSET
   CLA CLL
   TAD (5300      /INTR ON CLOCK - 1KC
   CLLR
   CLA CLL
   JMP I STCLK

The bit relevant to our issue is in bold above; the CLLR IOT instruction is used to load the DK8-EP’s clock control register with the contents of the 8’s Accumulator register (in this case, loaded with the value 5300 octal by the previous instruction).  The comments suggest that this sets a 1 Khz clock rate, with an interrupt every time the clock overflows.

I dug out the a copy of the programming manual for the DK8-EP from the 1972 edition of the “PDP-8 Small Computer Handbook” (which you can find here if you’re so  inclined).  Pages 7-28 and 7-29 reveal the following information:

DK8-EP Nitty Gritty

 

The instruction we’re interested in is the CLDE (octal 6132) instruction: (the Spacewar code defines this as CLLR) “Set Clock Enable Register Per AC.”  The value set in the AC by the Spacewar code (from the octal value 5300) decodes as:

  • Bit 0 set: Enables clock overflow to cause an interrupt.
  • Bits 1&2 set to 01: Counter runs at selected rate.
  • Bits 3,4&5 set to 001: 1Khz clock rate.

(Keep in mind that the PDP-8, like many minicomputers from the era, numbers its bits in the opposite order of today’s convention, so the MSB is bit 0, and the LSB is bit 11.)  So the comments in the code appear to be correct: the code sets up the clock to interrupt, and it should be enabled and running at a 1Khz rate.  Why wasn’t it interrupting?  I wrote a simple test program to verify the behavior outside of Spacewar, just in case it was doing something unexpected that was affecting the clock.  It behaved identically.  At this point I was beyond confused.

But wait: The diagnostic was passing — what was it doing to make interrupts happen?

DK8E-EP Diagnostic Listing

The above is a snippet of code from the DK8E family diagnostic listing, used to test whether a clock overflow causes an interrupt as expected.  The JMS I XIOTF instruction at location 2431 jumps to a subroutine that executes a CLOE IOT to set the Clock Enable Register with the contents in AC calculated in the preceding instruction.  (Wait, CLOE?  I thought the mnemonic was supposed to be CLDE?)  The three TAD instructions at locations 2426-2430 define the Clock Enable Register bits.  The total sum is 4610 octal, which means (again referring to the 1972 Small Computer Handbook):

  • Bit 0 set: Enables clock overflow to cause an interrupt
  • Bits 1+2 unset: Counter runs at selected rate, and overflows every 4096 counts.
  • Bit 3, 4+5 set to 110: 1Mhz clock rate
  • Bit 8 set:  Events in Channels 1, 2, or 3 cause an interrupt request and overflow.

So this seems pretty similar to what the Spacewar code does (at a different clock rate) with one major difference:  Bit 8 is set.  Based on the description in the Small Computer Handbook having bit 8 set doesn’t make a lot of sense — this test isn’t testing channels 1, 2, or 3 and this code doesn’t configure these channels either.  Also, the CLOE vs CLDE mnemonic difference is odd.

All the same, the bit is set and the diagnostic does pass.  What happens if I set that Clock Enable Register bit in the Spacewar code?  Changing the TAD (5300 instruction to TAD (5310 is a simple enough matter (why, I don’t even need to reassemble it, I can just toggle the new bits in via the front panel!) and lo and behold… it works.

But why doesn’t the code make any sense?  I thought perhaps there might have been a different revision of the hardware or a different set of documentation so I took a look around and finally found the following at the end of the DK8-EP engineering drawings:

The Real Instructions

Oh hey look at that why don’t you.  Bit 8’s description is a bit more elaborate here: “Enabled events in channels 1, 2, or 3 or an enabled overflow (bit 0) cause an interrupt request when bit 0 is set to a one.” And per this manual, setting bit 0 doesn’t enable interrupts at all! To add insult to injury, on the very next page we have this:

More Real Info

That’s definitely CLOE, not CLDE.  The engineering drawings date from January 1972 (first revision in 1971), while the 1972 edition of the PDP-8 Small Computer Handbook has a copyright of 1971, so they’re from approximately the same time period.  I suspect that the programming information given in the Small Computer Handbook was simply poorly transcribed from the engineering documentation…  and then Spacewar was written using it as a reference.  There is a good chance given that this version of Spacewar supports a multitude of different hardware (including four different kinds of programmable clocks) that it was never actually tested with a DK8-EP.  Or perhaps there actually was a hardware change removing the requirement for bit 8 being set, though I can find no evidence of one.

So with that bug fixed, all’s well and our hero can ride off into the sunset in the general direction of the 2017 Intergalactic Spacewar Olympics, playing Spacewar all the way.  Right?  Not so fast, we’re not out of the woods yet.  Stay tuned for PART TWO!

hardware, software

The Xerox Alto: An Introduction

In this series of articles I’ll go into the Alto in detail — the low-level hardware implementation and microcode, the software and languages and ideas that this hardware made possible, and the environment at Xerox PARC where the Alto was designed and used.  But before we dive down to the bedrock, let’s start with a bit of background.

Alto History

In the early 1970s, Alan Kay, a computer scientist at PARC, had a vision of a personal portable computer that he called the Dynabook.  In many ways, Dynabook was similar to modern laptops or tablets – it weighed under two pounds, contained a keyboard, display, and pointing device, and had a tablet form-factor.  The goal of the Dynabook was to be “a personal computer for children of all ages,” a portable educational computer.  Kay’s vision wasn’t technically feasible at the time – but the vision behind it was a driving force for the research he lead both during his tenure at PARC and beyond.

Alan Kay's Dynabook. Image courtesy of Wikipedia.
Alan Kay’s Dynabook. Image courtesy of Wikipedia.

In 1972 Kay proposed the idea of building a small personal computer (which he termed “KiddiComp”) to allow experimenting with the kinds of ideas he envisioned for the future Dynabook – in particular user interface design, education and computer-literacy for children.  This was centered around a programming language he called “Smalltalk” which made use of unique hardware for the time:  A high-resolution bitmapped display with a pointing device.  Unfortunately, when Dr. Kay submitted a proposal to the management at PARC to get a few KiddiComp systems built, he was denied funding.

Enter Butler Lampson and Chuck Thacker.  When PARC’s request for the purchase of a DEC PDP-10 for their research work was turned down in 1971 these two brilliant engineers figured they could design and build their own PDP-10 within eighteen months.  And they did – MAXC (pronounced “Max”) was a microcoded recreation of the PDP-10 architecture using semiconductor memory rather than core, and a pair of them were used at PARC for the next decade.  By 1972 Lampson and Thacker were both itching for a new project.

From Alan Kay’s “Early History of Smalltalk”:

In Sept [1972] … Butler and Chuck came over and asked: "Do you have any money?" I said, 
"Yes, about $230K for NOVAs and CGs. Why?" They said, "How would you like us to build 
your little machine for you?" I said, "I'd like it fine. What is it?" Butler said: 
"I want a '$500 PDP-10', Chuck wants a '10 times faster NOVA', and you want a 'kiddicomp'. 
What do you need on it?" I told them most of the results we had gotten from the fonts, 
painting, resolution, animation, and music studies. I asked where this had come from 
all of a sudden and Butler told me that they wanted to do it anyway, that Executive "X" 
[the executive who shot down Kay’s KiddiComp request] was away for a few months on a 
"task force" so maybe they could "Sneak it in", and that Chuck had a bet with Bill Vitic 
that he could do a whole machine in just 3 months. "Oh," I said.

Thacker and crew started the skunkworks project on November 22, 1972 and by April of 1973 the first Interim Dynabook (aka Alto) was up and running and displaying graphics:

The first Alto. From Alan Kay's
The first Alto. From Alan Kay’s “Early History of Smalltalk.”

The Alto featured a bitmapped display of 606×808 pixels with the approximate dimensions of an 8.5”x11” sheet of paper, 64KW (in 16-bit words) of semiconductor memory, a microcode clock rate of 170ns (approximately 6Mhz) and local storage of 2.5MB on a removable pack.  In 1974 the design and implementation of Ethernet networking was completed, and became standard Alto hardware.  All of this was implemented in a couple hundred ICs and fit under a desk.  Over the next 10 years, approximately 2,000 Altos were manufactured for use within PARC and at research labs and universities around the world.

The Alto was designed as a research vessel for efforts within PARC, and in that regard it was an astounding success.  Over the next decade, the Alto was involved in experiments in:

  • Human/Computer interaction
  • Education
  • Programming languages (BCPL, Smalltalk, Lisp, and Mesa)
  • Networking and distributed computing
  • Desktop publishing, word-processing and laser printing
  • The Graphical User Interface (GUI)
  • Computer-generated music and audio
  • Computer-generated graphics and animation
  • Computer-aided circuit design

Most famously, the Alto (running Smalltalk) served as the inspiration for the modern Graphical User Interface.  As the story goes, in 1979 teams from both Apple and Microsoft saw what PARC had been working on and were inspired, integrating aspects of what they saw into the Macintosh and Windows, respectively.

Smalltalk was important in early computer education and HCI studies and lives on to this day in the Squeak programming language.

The Mesa programming language originated on the Alto and was instrumental in the development of the Xerox Star desktop environment.

The Bravo word processor introduced WYSIWYG editing to the world and is in many respects the great-grandfather of Microsoft Word – Bravo’s author Charles Simonyi took what he’d learned from Bravo with him to Microsoft when he left PARC in the early 1980s.

The Ethernet networking research done with the Alto at PARC lead to the definition of Ethernet as an industry standard and was a major influence on the design of TCP/IP and associated networking protocols.

The Alto’s success was due in no small part to its clever, minimalist hardware design.  This design made the Alto extremely flexible and easily adaptable to whatever crazy idea or experiment that needed to be investigated.

In the forthcoming articles in this series, I will go into detail about the Alto’s hardware and demonstrate how the Alto achieved this flexibility.

 

software

Apple 1 INTEGER BASIC #2

Okay, if the Apple 1 computer does not have screen addressing, how am I doing SPIROGRAPH?

7000 REM SET PIXEL (X, Y) 0-39, 0-47
7010 Z = 1 : Q = V(10*(Y/2)+X/4+1) * 2
7020 FOR S = 1 TO 4 – X MOD 4
7030 Z = Z * 4: Q = Q / 4
7040 NEXT S
7050 Q = Q MOD 4: Z = Z / 4
7060 IF Y MOD 2 = 0 THEN 7080
7070 IF Q MOD 4 = 0 THEN V(10*(Y/2)+X/4+1) = V(10*(Y/2)+X/4+1) + Z: RETURN
7080 IF Q MOD 4 = 0 THEN V(10*(Y/2)+X/4+1) = V(10*(Y/2)+X/4+1) + Z * 2: RETURN

8000 REM PRINT SCREEN 40 * 48; TBTBTBTB
8010 FOR Y = 0 TO 23
8020 FOR X = 0 TO 39
8030 IF Y = 23 AND X = 39 THEN RETURN
8040 Z = V(Y * 10 + X / 4 + 1) * 4
8050 FOR S = 1 TO 4 – X MOD 4
8060 Z = Z / 4
8070 NEXT S
8080 Z = Z MOD 4
8090 IF Z = 3 THEN PRINT “:”;
8100 IF Z = 2 THEN PRINT “‘”;
8110 IF Z = 1 THEN PRINT “,”;
8120 IF Z = 0 THEN PRINT ” “;
8130 NEXT X
8140 NEXT Y

As the screen is 40 x 24 characters, it would be nice to make that 40 x 48 — using ‘ , and : to double vertical resolution.

First I made an array of 240 integers.  It would have been nice to make an array of 40 x 48 integers, but there isn’t enough memory, and two dimensional arrays are not supported.  So I had to fit two vertical dots and 4 horizontal dots into one integer.  Then, using shift-by-divide and the MOD function, I could calculate what I wanted on the screen, and finally print it all out at once.  However, I didn’t print out the last character, as that would have scrolled the screen.

Spirograph is round, so the 48 lines vertically are not needed.  And, this is important, because the program actually loads, but does not run — getting an out-of-memory error.  Deleting some of the many REMarks frees up enough space to run.

software

Hello MULTICS …

You are protected from preemption.
SMJones.SysAdmin logged in 03/18/17  1933.1 pst Sat from ASCII terminal “none”.
Last login 03/04/17  1014.3 pst Sat from ASCII terminal “none”.