The DEC 340 Monitor, The Introduction

My big project this year is to get a DEC 340 monitor working. Here is a picture of one of them.

The DEC 340 was a very early and rare computer monitor dating from the mid 60’s used of course, on DEC computers, their PDP series. Two cabinets of rack mounted electronics.  The 340 is historic and was used in some early work that pioneered modern computer graphic techniques.  It is quite a bit different from Cathode Ray Tube (CRT) monitors used by personal computers we were all familiar with a few years ago.  In comparison it is alien technology.  All circuits are implemented using discrete components and there are no integrated circuits anywhere in the design.  The discrete components themselves are unusual dating from the early days of transistor use.

The DEC 340 I have to work on is missing the cabinet on the right.  It seems to have been lost in the sands of time.  The cabinet with the big tube on the left is the one we have.  It is covered inside and out by a thin layer of rouge desert dust.  A peek inside the cabinet and the dust suggests our DEC 340 could have crashed onto the desert outside Roswell, New Mexico as part of a flying saucer or come from the surface of Mars as alien technology.  My peek inside had looked strange, alien.  It took me a few moments to understand what I had seen.  Then I had an a-ha moment.  I realized this is how DEC computer engineers of the time did analog electronics.  Everything is packaged the same way discrete digital circuits of the day were, as digital circuits of the time had to be connected together because of their complexity and size.  Circuit cards of components in racks of connectors connected to back-planes carried buses of signals in digital circuits but analog signals may not like the same kind of connections as digital connections do.  They may require different considerations.  I’m not used to seeing analog signals jumping from place to place as if electronic noise did not matter.

I can’t be critical because DEC 340 analog electronics obviously worked, but path length is usually kept short when making analog connections.  This keeps noise pick up to a minimum and signals clean.  I was surprised by what I saw in the 340 but DEC did not make radios or TVs.  DEC built computers and I figure their engineers had to do things a certain way.  Maybe even if they knew better.  The layout which to me looks odd must have made somebody happy.  Having all the electronics which connect to the CRT at least be in the same cabinet seems to have been the only concession made to analog design considerations but since it worked that’s OK.  Scrounging for documentation I found that DEC had used the same CRT in other monitors and essentially the same drive electronics on the tube itself, so whatever problems they had only needed to be solved once.  That was a good discovery,  some of that documentation helps me out.

Our 340 is incomplete with parts missing and actually came from a junkyard in Australia where it had been sitting outside for a while.  Arid conditions somewhat preserved this DEC 340 but sadly it is incomplete.  Our 340 is a carcass of missing pieces and this incompleteness enhances the feeling it is something from another world.  Original components to build up missing circuit boards and for repair of  circuits we have can not all be found.  Old components are often not made of the materials modern components are and sometimes they do not age well.  Arid also does not mean it is always dry.

We have the magnetic deflection yoke and tube.  Essential parts which I can’t re-manufacture.

The Sixteen Inch Radar Tube

But an entire cabinet of components is missing.  Racks of digital circuit cards which made the DEC 340 a processing device all on its own.  Circuits which offloaded details of drawing from the host computer to which it was attached to lighten the host processing load.  For these circuits we have only paper documentation.  Output from the missing circuits drove circuits which controlled a big round sixteen inch radar CRT around which the DEC 340 was built.  These circuits I have because they are analog circuits that were mounted close to the display CRT to minimize electrical interference.  These circuits were in the same cabinet as the CRT; the only cabinet we have.  Within the cabinet the analog circuits were implemented using Digital Equipment System Building Block technology where space allowed.

System Building Blocks, are circuit boards mounting discrete components with a heavy duty 22 pin gold plated connector on one end to create a ‘block’ that can be used to build a ‘system’.  The three sides without the connector are wrapped by an aluminum band.  System Building Blocks plugged into a rack mount which could hold up to 25 blocks.  Twenty five side by side connectors were interconnected on each rack mount to create a back-plane which resembled the way typical computer circuits of the day were implemented.  That resemblance aside, System Building Blocks implemented both analog and digital circuits in implementations which today would be called ‘mixed signal’.  Here is one of our modules with dust gently brushed off and blown away by compressed air.

A 1575 System Building Block

The transistors and diodes used in these circuits became obsolete long ago. Some were made of germanium which was only used as a semiconductor material in the early years of semiconductor electronics. Silicon is used almost exclusively as a semiconductor now. Silicon is a superior semiconductor for common uses, but in the early days of transistors.  Germanium was a semiconductor of choice. Techniques for working with silicon had yet to be perfected.  I can get vintage germanium parts but they are expensive and hard to find.  The numbers on the silicon transistors used I have not seen before.  The vacuum tube era had just come to an end when the DEC 340 was built. Transistors were new and the ones used in the DEC 340 became quickly obsolete and are uncommon.

I would have to pay a lot for replacements, those I could find. There are vendors who specialize in old parts. They don’t have everything.  I would have a great deal of problems replacing components with original parts or parts with even similar specifications.  Diodes this old when put on a curve tracer can sometimes look more like a resistor than a diode.  Gray corrosion coats component leads.  I am concerned about the diodes and transistors which have leads that were not gold plated.  The hermetic seal on some of those components is sure to have failed.  The plating on the steel rack which holds the circuit cards shows spots of corrosion documenting that condensation has visited the components.

I only have one rack of circuit cards that contain System Building Block cards like that shown above. These circuits control to the CRT.  All of the other electronics are missing.  An entire cabinet full of card racks. All the signals to the cards I do have came from this second cabinet of cards that I only have paper documentation for.  A second rack mounted below the first was cooled by forced air and is show here.  The components on this rack are part of System Building Block schematics with components too big and which ran too hot to be mounted onto System Building Block circuit cards in a rack that takes thin plug in cards mounted side by side.  Shown here are these two rack mounts removed from the cabinet they came in.  A patch panel which jumped wires to the CRT from these racks is also shown.  It was mounted in space inside the cabinet behind the racks and holds components on the other side.

The Electronic Carcass (removed from rack)

So what to do? My first decision upon reviewing the documentation and physical parts I had was to decide to reproduce the electronic circuits using modern components on new circuit cards. I might enjoy getting the original electronic circuits working but it is too risky and I do not have them all to begin with. I look at the glass diodes on the circuit cards and cringe. I don’t trust any of them. They have experienced morning dew and have corroded. We already know that the glass seal on old diodes can fail with time and a desert is not needed for that. Even if the diodes work I’d not trust them to keep working for long.  Working on stuff knowing replacements are not available is scary. I would not want to plug in a one of a kind circuit and see smoke.  I also know that the traces on circuit boards this old lift very easy so it is easy to damage these circuit boards when changing components.  Even a little heat can turn circuit boards this old brown and lift traces.

Reproducing the function of all the original circuits seems my best path. I located schematics for all the circuits so I can understand how they work and work together. My goal is to get the big radar tube working as it once did. Accomplishing that task using modern components based on original schematics will be fine and if something burns up I can replace it. Had the whole 340 made it to the desert to be found I might have decided to get the old circuits working and scramble for parts but with half our 340 missing, building all the electronics from scratch seems the best way to go for my best chance of success.  That the DEC System Building Blocks were made using a proprietary connector has no small influence on my decision.  I can create work alike versions using printed circuit cards which plug into easily obtained edge connectors but mixing and matching that arrangement just to accommodate the few System Building Blocks I do have makes no sense at all.  It will be far easier to rebuild everything around a common connector that I can get than to rebuild the back plane using half new and half old parts which are actually incompatible in physical size to begin with.

Another consideration is the issue of interface.  The original System Building Block circuits interfaced to DEC equipment logic levels which range from ground to a negative voltage.  We will be implementing the DEC 340 logic functions using modern technology which uses logic of a positive voltage, so I need equivalent System Building Blocks which interface to positive voltage.  None exist, the only way I am going to get those is if I make them.  A level of voltage translation circuitry between existing cards might cause timing problems best avoided.  Another reason not to use the cards I have but to make work alike copies is the extra work of translating voltages cancels out the cost and work of reproducing circuits with voltage translation built in.  As will be explained in basic operation, for its time, the DEC 340 was a high performance device and I must pay close attention to timing requirements.

Will it really be a DEC 340? Yes it will. The tube will be original or an original replacement (I found one at a surplus store) and the deflection coil, which drove the tube, will be original as there are no replacements for that anywhere to be found. Function of the original DEC 340 will be achieved in a work alike reproduction driving an original tube.  The electronics will reproduce the function of the original and if parts fail, replacements will be available.

This article introduces my big project for the year but I have been working on it for a while.  I have been creating schematics of the circuits I need and have been planning how it all goes together.  I have been buying parts I know I will use.  My original plan with this blog post was to write about the circuit on the 1575 System Building Block I show above.    It is a fascinating and interesting circuit that I had to understand in great detail to implement right.  I can base my circuits on original circuit topology and honor the basic method and forms but using new components with characteristics that don’t match exactly means I have to check that all the math works out right.  This changes the values on some resistors and capacitors, so components are biased correctly.  I simulate the circuits in a circuit analysis program so they have the best chance of working without needing later adjustments after I build them.

I could not write about the 1575 System Building Block circuit without introducing my project.  I still need to describe the basic operation of the DEC 340 before discussing the operation and function of the 1575 circuit.  Understanding a circuit is a lot more fun if you know what it is used for.  I find it can make the difference between being fascinating and boring, though the 1575 circuit is fascinating on its own.  In my next blog post I’ll describe basic operation of the DEC 340.  Eventually I will explain what Q4 and Q5  do in the 1575 circuit.  They are in the center of the below schematic.

1575 System Building Block Schematic

In the original circuit they are germanium transistors in a place where germanium seems to actually be a better circuit choice as will be explained.  It is an unusual circuit I have only seen a few times in my life and the way it works is subtle.  It is used to switch a voltage under very specific requirements.  It is fascinating because it seems to work better than it should and some thought on transistor physics is needed to understand why. I will be implementing two missing DEC 340 Digital to Analog converters and a 1575 type circuit takes the voltages produced by these D to A converters to feed downstream amplifiers.  But first I’ll describe the basic operation of the DEC 340 and how it differs from the later computer monitors which became the mainstream standard for many years.

 

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
p1=h
p1=L
# run clocks for a bit...
P17=h
P14=L
P14=h
P14=h
P14=h P17=L
P14=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.

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…

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.

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!

 

 

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

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!

Minecraft World Boundary

The worlds created on the LivingComputers minecraft server have boundaries. One may go from -1024 to 1023 in both directions.
If one gets outside the boundary, one may not move. And if one is far enough outside the boundary, one suffocates in a wall.
There are 2 methods to get outside the boundary: transport there (if you have that permission), and dismount from transportation. Getting off a boat or a minecart may put you outside the boundary. If the boat or minecart are still in position, you may remount it, and reenter the world.
Villagers may not pass through the boundary. However, it is possible to trade across it.
Water passes through the boundary.
Arrows pass through the boundary.
Trees grow through the boundary.
I believe when blocks are destroyed, their remains may end up across the boundary. I believe if you get close enough you can capture it.
I have yet to observe monsters across a boundary, and I suspect I can be shot, but I don’t know if a creeper can blow me up. (I’m not sure I want to find out).

Dynamite will destroy blocks across the boundary.  Water may be poured across the boundary (and fetched.)  A creeper blowing up on my side of the boundary did not seem to destroy blocks across it.

Minecraft Python coordinates

Using setBlock() to place blocks requires some attention.
Blocks are placed at Integer locations. You may pass a floating point value to the function, but it is converted to integer.
It is the converting to integer which may aggravate you:
The function int(x + dx) does not necessarily return the same value as int(x) + int(dx). If you are placing blocks around the origin (0,y,0), any -1 > dx < 1 will be truncated to 0. However, away from the origin, say x = 14, x – 0.5 will go to 13, where x + 0.5 will go to 14.
I assume your x and z will be integers already, so make dx and dz integers before you add them to x and z.
setBlock(x+int(dx), y, z+int(dz), 0)