Testing old technology

I have 4500 modules in the CDC 6500, and it isn’t always easy to debug them in the machine, because convincing the machine to wiggle its lines so I can check each transistor on a particular module is difficult.

In order to make this problem a little easier, I have built a cordwood module tester:

It has taken a couple of revisions to get the pin drivers correct, but it does useful things for me when I need it to. The three cables going out the back go to a Mesa Electronics 7i80 FPGA board, which I use for driving signals to the module under test. I have written some hardware for the FPGA, in VHDL, that knows how to talk to the tester board.

I have also written an assembler in Perl, to assemble stimulus commands I write, to the appropriate VHDL that gets included into the FPGA. Here is a sample of what I feed into the assembler:

# P14 = T70 negative pulse
# P17 = clock gate
# set the pins:
p1=h p2=h p3=h p4=h p5=h p6=h p7=h p8=h p9=h p10=h p11=h p12=h p13=h p14=h p15=h p16=h p17=h
p18=h p19=h p20=h p21=h p22=h p23=h p24=h p25=h p26=h p27=h p28=h
# scope sync pulse on unused pin
# run clocks for a bit...
P14=h P17=L

Each line represents what it should do for the next 20 nano-seconds. This results in a table that gets glued together with some header and trailer bits to create the VHDL input file. Here is the output listing:

 # P14 = T70 negative pulse
 # P17 = clock gate
 # set the pins:
 0 0ns 0xffe0000 p1=0 p2=0 p3=0 p4=0 p5=0 p6=0 p7=0 p8=0 p9=0 p10=0 p11=0 p12=0 p13=0 p14=0 p15=0 p16=0 p17=0
 1 20ns 0x0000000 p18=0 p19=0 p20=0 p21=0 p22=0 p23=0 p24=0 p25=0 p26=0 p27=0 p28=0
 # scope sync pulse on unused pin
 2 40ns 0x0000000 p1=0
 3 60ns 0x0000001 p1=1
 # run clocks for a bit...
 4 80ns 0x0000001 P17=0
 5 100ns 0x0002001 P14=1
 6 120ns 0x0000001 P14=0
 7 140ns 0x0000001 P14=0
 8 160ns 0x0010001 P14=0 P17=1
 9 180ns 0x0012001 P14=1
 10 200ns 0x0010001 P14=0
 11 220ns 0x0010001 P14=0

The listing shows the memory location, what time that instruction should execute, the actual bits in hexadecimal notation, and what the source file said.

This handy little tool has enabled me to fix 4 out of 5 of the UA modules I had replaced in the CDC, and to know what was wrong with the other one.


What I learned Mapping Minecraft Worlds

Minecraft is getting a little stale for me now.  I’ve done my exploring, and exploiting.  Nothing left but… to look at the database!

Each Minecraft world has its own folder in the save directory, with other subfolders and a lot of data files.  I noticed that each map created in the world is a separate file, and that file is in GZip format, and there is a library for Python to look at them.  So, I would tediously explore the world, creating maps and then look at the database.  The worlds we have on our server are limited in size plus and minus 1024 blocks.  Each map displays 128 pixels, a pixel being one block at the closest zoom, and can be 16 x 16 blocks at furthest zoom.  Plus, the maps have a funny center offset of 64.  That means at highest resolution, to cover our explorable world, 17 x 17 maps are needed.  First, I would go to -1024, -1024 and create my first map (being Map_0).  Then I would move 128 east and do it 16 more times (to location 1024, -1024).  Then I’d go back to -1024 and go south 128.  That would be Map_17, and so it goes until Map_288.  How tedious (more about that later).  But then I have 289 maps, all of which I know how to unpack, and I could then generate a map!

But I don’t stop there, oh no!  I also can decode other files in the database to find height information and region information, and locations of interesting structures — although labels and making points visible is still a hand-done process.  *** Something Learned ***  PNG files support transparent areas.  Alas, Microsoft products seem to not support it.  However, one may drag a PNG picture into Powerpoint, use the Picture Tools Format tab, go to Color and choose Set Transparent Color.  Then click on the background color of your picture and it will disappear!  Then you may right-click on the picture and save it.  Having transparent areas will let me overlay features on my map.

*** Something Learned ***  How to make pictures with overlays?  Welcome to CSS.  The key is to make all images placed in the same absolute position.

top: 36px;
left: 0px;

z-index: 10

I also assigned z-index to my photos — just to be sure.

In HTML I installed buttons, stacked my maps: Topological, Regional, Altitude; stacked my overlays: Mine Rails, Spawners, Features, and Grid.  Here is the link to a world I want to become our new Amplified world:

Back to tedious map making.  The reason I stay with Office 2010 products is because later versions reduce functionality for security reasons.  With Excel 2010, I am still able to make system calls and use AppActivate and SendKeys.  Let me tell you how I automated map making.

The first task is to get into the Minecraft world.  Then one must be able to go into creative mode.  My program transports at altitude, to it is wise to start out flying, and looking in an interesting direction, and have nothing in your hands or inventory.  To run the program requires pausing Minecraft, and I use chat.  So, the first thing my program needs to do is to get out of chat.  I put in a lot of time delays using Now and While loops.  Now returns time to the second, so this will wait one second.

t = Now
While t = Now
AppActivate “Minecraft 1.12.2”, False
SendKeys “~”

The ~ is the way to send Enter.  AppActivate selects Minecraft as the active window, and then SendKeys sends the Enter.

Next I set up loops to go from -1024 to 1024 in steps of 128 in both directions.  I found that sending the complete command to Minecraft sometimes doesn’t work, so I send the / to start the command, wait, then send the rest of the command.  The first command teleports me to the chosen location, the next command gives me an empty map, then I right click to use the map, then I send Q to throw the map away (since there will be 289 maps, I can’t hold them all).

I have found that a one second wait after the transport may not be enough.  My current program (not quite perfect) goes “/” one second “tp -1023 160 -1023~” two seconds “/” one second “give sigma9 map~” two seconds, right-mouse click, four seconds, “Q” and wait two seconds.  That’s 53 minutes.

For z = -1024 To 1024 Step 128
For x = -1024 To 1024 Step 128
AppActivate “Minecraft 1.12.2″, False
q = Trim(Str(x)) & ” 160 ” & Trim(Str(z))
SendKeys “/”
t = Now
While t = Now
SendKeys “tp ” & q & “~”
t = Now
While t = Now
t = Now
While t = Now
AppActivate “Minecraft 1.12.2”, False
SendKeys “/”
t = Now
While t = Now
SendKeys “give sigma9 map~”
t = Now
While t = Now
t = Now
While t = Now
AppActivate “Minecraft 1.12.2”, False
‘send a down event
mouse_event MOUSEEVENTF_RIGHTDOWN, 0&, 0&, 0&, 0&
‘and an up
mouse_event MOUSEEVENTF_RIGHTUP, 0&, 0&, 0&, 0&
t = Now
While t = Now
t = Now
While t = Now
t = Now
While t = Now
t = Now
While t = Now
AppActivate “Minecraft 1.12.2”, False
SendKeys “q”
t = Now
While t = Now
t = Now
While t = Now
Next x
Next z
End Sub

I have found that it is wise to do the AppActivate before the mouse events.  One would think one would only need one AppActivate, but no.  Of course, one must then NOT TOUCH anything for the whole hour.  Do not have e-mail open, do not plug in USB, do not lose power.  It is okay to touch the mouse slightly if you want to be sure your computer doesn’t go to sleep.

The point of this exercise is to find interesting worlds.  I prefer a world with multiple region types, several villages, a temple and witch’s hut in the explorable part.  I also like to have water near spawn so I can make a quick getaway.  The world in the map example only has 3 villages, which is disappointing, but it has a lovely ocean (not too much) and two witch huts just right there.  The desert Temple is there in the upper right corner, but it is buried under the amplified terrain.

I will be exploring more world possibilities.  Try LCM+L for the seed and you will get Antarctica.



hardware, restoration

Detecting Nothing

The IBM360/30 gets stuck in a microcode loop.  The documentation indicates that a branch should be taken if the Z-bus is zero, and the branch should be taken.  The branch is not being taken.

A previous annoyance was that the microcode would stop at address 0xB46.  As the documentation indicates for that location, it is checking that a register is zero.  Hmm… checking for zero?  That is the problem with the loop not stopping.  So I dug deeper into this stop.  There was a stuck bit!  And here is what I found:

The circuit is an AND-OR-Invert gate and the output of the AND was high.  The above circuit is the AND gate.  If any of the inputs on the bottom go low the output should go low.  The output was not going low.  However, there is nothing on this circuit to force it low, but rather it allows the output to go low.  So, the problem was the input to the OR gate:

Aha!  That transistor with an X on it is not good.  Fortunately, we have spares of this SLT module, and replacing it fixed the problem with the first microcode stop.  However, the microcode loop with the non-taken branch is still not working as documented.  Dig deeper…


New peripherals for old Computers

Five years ago, when we were getting done with restoring our PDP10-KI, we were running out of working disk drives to run it from. We were down to one set of replacement heads, two working drives, and we didn’t have a source for new ones. We found some folks that said they could rebuild the packs, but it turned out that they couldn’t re-write the servo surface, so if we lost that we were in trouble.

Alright, what else can be done? The Digital RP06, the drive of choice for the KI, has lots of registers available from the MASBUS. The MASBUS is kind of a UNIBUS, with a synchronous data channel for moving the actual data. We had been having difficulty keeping track of everything on an existing project, so I looked into doing things a different way.

My idea was to use an FPGA, (Field Programmable Gate Array) to emulate the behavior of the control unit inside the RP06. This is like the ease of writing software, but for hardware. No wires to change, no cuts, when I mess up the logic. The PC would be responsible for handling the actual data for the disk, or possibly tape.

I spent a while poking around the Internet looking for an FPGA card that would plug into a PC. There were a lot of expensive, and some less expensive evaluation boards out there. I eventually happened across I had heard of these folks before from my experiences with LinuxCNC, which runs my milling machine at home. These folks have been doing this for a long time, and since they have to deal with industrial environments and big motors, their products are very robust.

For the MASBUS Disk Emulator, (MDE), I chose the Mesa 5i22 card, which has 96 I/O’s I can play with, and a Spartan3 Xilinx FPGA. The 5i22 doesn’t remember what the Xilinx configuration is, so the PC pours in the correct bits each time.

Bob Armstrong, down in the Silicon Valley, wrote all the software for the PC, and we eventually emulated RP06’s, RP07’s which hold twice the data, and TU77 tape drives. Here is a picture of our main collection of MDE’s.

There are 3 Industrial PCs, and 8 MASBUS Cable Driver/Receiver boxes. These are running both PDP10-KL’s, and the PDP10-KS’s. There is a real TU78 tape drive, to the left of the MDE rack. The PDP10-KI, and the PDP11/70 each have their own located elsewhere in the museum.

I also used the 5i22 for all of the emulations that we needed for the CDC6500:


Here we have one Industrial PC, and 6 6000 series channel attach Driver/Receivers, along with one 3000 series channel Driver/Receiver. We emulate the dead start panel, the DD60 Display, Tape drives, disk drives, printers, card readers, card punches, the serial terminal interface and the 6681 channel converter so we could talk to the real 405 card reader. Bob Armstrong also wrote the PC code for all these emulations.

Jeff Kaylin has also used 5i22 cards on the Sigma 9, with Bob doing the software, and Craig Arno and Glen Hermannsfeldt used one to emulate the card reader and punch on the IBM 360/20.

All is not sweetness and light however, after making the 5i22 for over 10 years, the parts are getting hard to obtain, so Mesa Electronics has stopped production of that board. We ordered all their remaining stock of the 5i22s. They no longer make the 5i22, but they make lots of other similar boards, so we ordered some 7i61’s and 7i80’s to play with.

The 7i61 uses USB to talk to a PC, and has 96 I/O’s to play with. The 7i80 uses Ethernet to talk to the PC, but only has 72 I/O’s. To conserve 5i22’s, I converted my CDC 6681 6000 to 3000 channel converter to the 7i61 because it needs all 4 cables for 96 I/Os. I used my code, along with open source code from Peter Wallace, of Mesa Electronics, to load my code into the serial flash chip on the 7i61, so the PC is no longer involved in the 6681 emulation. After turning on the power to the Mesa card, it knows how to be a 6681 automagicly! I no longer have to remember to type the proper incantation into the PC to get it loaded up, this is a GOOD thing!

After getting the CDC 6500 working, I had several broken modules that I wanted to fix, so I built a Module tester, using the 7i80 card:

You can see the 7i80-HD card under the cables down from the test card.

It took me a while to collect the appropriate bits of Peter Wallace’s code, so that I could have the Ethernet interface live in with my test code, all at the same time, but perseverance pays off, and it all works now. I have fixed 4 out of 5 broken UA modules, and I know why I am not going to fix the other UA, and the ED module that I replaced in CP1.

I have to confess: the module plugged into the tester, is not really from the 6500, but it is the same form factor, and technology.

I love these Mesa Electronics “Anything I/O” cards! As their name says, I can teach them to be most Anything!

Bruce Sherry 20180418.


That Pesky PS Module!

When we last left our hero, he had re-soldered all the Via rivets on one of the 510 “PS”, core memory sense amplifier modules in the CDC6500, and the machine was working.

That lasted about a day, and the memory went away again. What was wrong this time? You guessed it, bit 56 in bank 36 was bad again. Third time is the charm: I am going to replace this module! I head off looking for a spare PS module. Where did we put all those spare parts we got with the machine? Oh wait, we didn’t get any spares with the machine. Bummer!

This is where I get to practice my “MAD Skillz”, and make some spare PS modules. What does a PS module look like? What does CDC give me?

On the left side we have an actual schematic of one of the 4 amplifiers on the module, YAY! Having been around this block before, I take apart the offending module and check to see if it matches. Wiring wise, yes it matches, but the values have been changed to protect the innocent.

After a while playing with the newest version of Eagle, I ended up with this:

The easy part is done, now the fun starts! The circuitry for the module is split between two printed circuit boards, one that connects to the odd pins on the connector, and has odd numbered transistors, and one for the even bits. Eagle really doesn’t understand this, so I have to fool it. First I put test points on each side of all components that go between the boards. I have to then add in the wire jumpers that also go between the boards, and I end up with another schematic:

I take this schematic and duplicate it into odd and even sides, then I write an Eagle script to delete all the between boards components, and all the test points that belong on the other board. Here is what the schematic for the odd board looks like, pretty terrible:

Now I have two schematics: PS_O and PS_E, and I do the PC layout thing. I have the original boards to use as an example, which I follow very closely so that timing and signal integrity will be as close as I can to the original module. Here are pictures of the odd and even layouts:

But wait, I’m not done yet! Remember Eagle doesn’t understand the whole module. I now have to verify that the two boards, together with all the components that go between, match that original schematic I started with.

I go over every line on the board pairs, and the schematic highlighting them as I go, until EVERYTHING is highlighted.

Done yet? Grumble, grumble: No! I have forgotten to identify which end of the diodes and polarized capacitors have the band on them! If I want them assembled properly, I guess I should do that before they go out to FAB!

Back to the PC mines…

Bruce Sherry 20180201 10:57AM


IBM360-30 Read Only Storage

The IBM360-30 uses Printed Card Capacitor storage for microcode.

The cards were created by printing Silver ink on Mylar:

Or etched copper:

304 cards make up the microcode.  I scanned them all.

My procedure was to remove one card, clean it, scan it, and then replace it before removing the next card.  My original thought was to clean the cards thoroughly using water, possibly with soap, as the machine was stored in a damp location.  However, the cards turned out to be quite clean, and only required wiping.

Scans were captured at 24-bit color, 600-bpi resolution.  The captured area was 3.15″ x 7.25″, and saved as .BMP files (24MByte).  I used different color backgrounds, and chose the sky-blue background as providing the best contrast for my eyes.  Processing of the images used the Blue channel.  Determining a threshold of hole/not hole was tricky, as there were two types of card, and each card had two areas to decode: the first 10 columns as card ID, and columns 11 through 70 for microcode data.  Registration of the scans was quite consistent for row alignment, but column alignment was variable.  Only one card needed adjustment vertically, but all card images were trimmed to align the first column.  Data was decoded from the card images and stored in a card archive.

hardware, restoration

Chasing the Pesky Ratio!

It seems like I did something really silly! I had to come up with some goals for 2018. I hate this time of year, I think everybody does. OK, what can I put down that is measurable and achievable? How about keeping the CDC6500 running more than 50% of the time? That might work. Oops, did I hit the send button?

“Hey, Daiyu: How do I tell what users have been on the machine?” Daiyu Hurst is my systems programmer, who lives Back East somewhere. If it is on the other side of Montana from Seattle, it is just “Back East” to me. She lives in one of those “I” states, Indiana, or Illinois, not Idaho, I know where that is. After a short pause, she found the appropriate incantations for me to utter, and we have a list of who was on the machine, and when they logged in. I had to use Perl to filter out those lines, but that was pretty easy.

What is all this other gobble-de-gook in this file:

 03.14.06.AAAI005T. UCCO, 4.096KCHS. 
 03.16.09.AAAI005T. UCCO, 4.096KCHS. 
 03.18.11.AAAI005T. UCCO, 4.096KCHS. 
 03.20.12.AAAI005T. UCCO, 4.096KCHSUCCO, 4.096KCHS. 
 05.00.30.SYSTEM S. ARSY, 1, 98/01/24.
 05.00.30.SYSTEM S. ADPM, 11, NSD.
 05.00.30.SYSTEM S. ADDR, 01, LCM, 40.
 05.00.44.SYSTEM S. SDCI, 46.603SECS.:
 05.00.44.SYSTEM S. SDCA, 0.032SECS.:
 07.32.30.SYSTEM S. ARSY, 1, 98/01/24.
 07.32.30.SYSTEM S. ADPM, 11, NSD.
 07.32.30.SYSTEM S. ADDR, 01, LCM, 40.
 07.33.07.AAAI005T. ABUN, BRUCE, LCM.:
 07.33.37.SYSTEM S. SDCI, 116.108SECS.:
 07.33.37.SYSTEM S. SDCA, 0.078SECS.:
 07.33.37.SYSTEM S. SDCM, 0.005KUNS.:
 07.33.37.SYSTEM S. SDMR, 0.004KUNS.:

The line with “ARSY” in it is when I booted the machine, at 5:00 this morning, from home. It crashed before I got in, and I booted it again at 7:32. Then we get to 7:33:07, and the “ABUN” line, where I login from telnet.

From the first few lines we can see that the machine appeared to still be running and putting things in its accounting log at 3:20, but it crashed before it could print a message about 3:22.

OK from this, I can mutter a few incantations at PERL, and come up with something like:

1054 Booted on 98/01/23 @ 07.39.30
 Previous uptime: 0 days 5 hours 59 minutes
 Down time: 0 days 17 hours 28 minutes
 1065 Booted on 98/01/23 @ 13.38.30
 Previous uptime: 0 days 1 hours 23 minutes
 Down time: 0 days 4 hours 35 minutes
 1068 Booted on 98/01/23 @ 14.12.30
 Previous uptime: 0 days 0 hours 0 minutes
 Down time: 0 days 0 hours 33 minutes
 1392 New Date:98/01/24
 1498 Booted on 98/01/24 @ 05.00.30
 Previous uptime: 0 days 13 hours 7 minutes
 Down time: 0 days 1 hours 40 minutes
 1503 Booted on 98/01/24 @ 07.32.30
 Previous uptime: 0 days 0 hours 0 minutes
 Down time: 0 days 2 hours 31 minutes

Last uptime: 0 days 0 hours 1 minutes

Total uptime: 2 days, 1 hours 37 minutes in: 0 months 7 days 0 hours 14 minutes
Booted 15 times, upratio = 0.29

Here is where the hunt for the Pesky Ratio comes in: See that last line? In the last week, the CDC has been running 29% of the time. That isn’t even close to 50%. I KNOW the 6000 series were not the most reliable machines of their time, but really: 29%?

What has been going on? A week ago, I was having trouble keeping the machine going for more than a couple of minutes. Finally, it occurred to me I might see how the memory was doing, and it wasn’t doing well. It took me a while to find why bit 56 in bank 36 was bad. I had to explore the complete wrong end of the word for a while, before I realized that end worked, and I should have been looking at the other end. I chased it down to Sense Amplifier (PS) module 12M40. When I put it on the extender, the signal would come and go, as I probed different places. I noticed that I had re-soldered a couple of via rivets before, so I re-soldered ALL the via rivets on the module.

What do I mean “via rivets”? In those days, either one of two things were true: either they didn’t have plated through holes in printed circuit boards, or they were too expensive. None of the CDC 6500 modules I have looked at have plated through holes. Most of the modules do have traces on both sides of the two PCBs that the module is made with. How did they get a signal from one side to the other? They put in a tiny brass rivet! Near as I can tell, all the soldering was done from the outside of the module, and most of the time the solder would flow to the top of the rivet somehow. Since I have found many of these rivets not conducting, I have to assume that the process wasn’t perfect.

After soldering all the rivets on this module, I put it back in the machine, and we were off and running. Monday, I booted the machine at 8:11, and it ran till 2:11. When I got in yesterday, the machine wouldn’t boot. Testing memory again found bit 56 in bank 36 bad again! I put module 12M40 on the extender, and the signal wasn’t there. I poked a spot with the scope, and it was there. I poked, prodded, squeezed, twisted and tweaked, and I couldn’t get it to fail.

This is three times for This Module! I like to keep the old modules if I can, but my Pesky Ratio is suffering here! I took the machine back down, and brought it back up with only 64K of memory, and pulled out the offending module:

There are 510 of these PS modules in the machine, three for each of the 170 storage modules, or about 10% of all the modules in the machine. Having a spare would be nice. My next task will be to make about 10 new PS modules.

In the time I have been writing this post, the display on the CDC has gone wonky again. This appears to happen when the Perpheral Processors (PP’s) forget how to skip on zero for a while. Once this happens, I can’t talk coherently to channel 10 or PP11. I have a few little tests that copy themselves to all the PP’s, and they will all work, except the last one: PP11.

I have yet to write a diagnostic that can catch the PP’s making the mistake that I can see on the logic analyzer once a day or so. Right now the solution seems to be to wait a while, and the problem will go away again. This is another reason while the Pesky Ratio is so difficult to hunt, but I fix what I can, when I can.

Onward: One bug at a time!



hardware, restoration

Surface-Mount Prototyping

I thought I’d glue a surface-mount 7414 onto a resistor pack, just to make it easier to prototype. Then I thought, hmm… a resistor pack would be useful to pull down signals when the driving logic hasn’t be initialized.
So, here is the picture:

I soldered wires onto the resistor pack first, then submerged them in water so they wouldn’t come undone when I soldered the other end.
Works like a charm (0.1″ prototyping spacing).

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

   CLSK=6131      /SKIP IF CLOCK
   CLLR=6132      /LOAD CONTROL
   CLEN=6134      /LOAD ENABLE
   CLSA=6135      /BIT RESET FLAGS

   CLA CLL        /JUST IN CASE   
   TAD (-40       /ABOUT 30CPS
   CLAB           /LOAD PRSET
   TAD (5300      /INTR ON CLOCK - 1KC

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!