Imlac Emulator Progress

I have a bit of downtime from Imlac repair while I wait for parts to arrive for the extender boards, so I've been spending time this week working on the Imlac emulator.  I started this just a bit over a month ago and I've been making slow and steady progress since then. I've based the entire implementation on the documentation sets available on Bitsavers and Tom Uban's site; in particular the "PDS-1D Programming Guide" and the "PDS-1 Technical Manual."  The Imlac has a nice, simple instruction set (both for the main and display processors) and the documentation is quite good, there are very few ambiguities to deal with.

The emulator says "Hi" for the first time

The first "real" program I got it to run (a few weeks back) was the sample program described in the Technical Manual (p. 70 of the PDF), this draws "HELLO" in block letters on the screen and I've been spending my limited spare time working on it ever since. 

At the moment, the emulator (tentatively called "sImlac" because why not) implements the following:

• PDS-1/1D Data and Display Processor emulation
• 8KW of Core memory, with 8KW display processor modifications
• Vector display support (with slow phosphor simulation because I'm a nerd that way)
• Keyboard emulation
• Basic PTR-1 (Paper Tape Reader) and TTY-1 (RS232 serial) support, using files on disk as a data source.  (No transmit support for TTY)
• Interrupt support
• LVH-1 (Long vector) support
• SGR-1 (Suppressed Grid) support
• MDS-1 (Multiply-nested Display Subroutine) support

 I'm gearing up for an initial release, but I have a few bugs I'd like to track down before then.  I thought I'd share a few screenshots since it's now capable of running a bit of actual software.  All of this software is from Tom Uban's archive.  It's thanks to him that there's any software at all that survived!  (Sorry the shots are so indistinct in their thumbnail modes, the vectors don't show up all that well -- click on them to embiggen.)

"Apollo," AKA "Lunar Lander"

The shot above shows "Apollo" ("newapollo" from the archive) running; this is a simple variation of Lunar Lander which also happens to be incredibly difficult since the rate at which the thrust can be changed is very slow.  Not sure if this is intentional or just a bug in the emulator, but at the moment this game's not particularly fun.

How about a nice game of checkers?

Above is "check" a simple Checkers game that pits the player against a computer opponent.  (Or you can have the computer play itself.)  At the moment it's not rendering quite right, as you can see, but it's very reassuring, telling me that I'm doing OK.  Thanks for the vote of support!

Conway's Game Of Life

Here we have Conway's famous cellular automaton brought to life (as it were) by the Imlac.  Using the arrow keys and the "C" key you can place cells, and then run the automaton using the "R" key.  This seems to be working properly.

Quiche eaters need not apply

And for those times when you need to do some debugging, the above program provides rudimentary disassembly support.

Maze War, sort of.

And Maze War!  Almost.  It's not really working yet, since it wants to talk to a host PDP-10 server to regulate the game.  With a bit of hacking I can get it to show the overhead maze display but it's going to take some extra work to get the game running properly.

I'm hoping to release Version 0.0 sometime in the next week or so (including source).  I'll keep y'all posted.  Until then, don't you go changing!

Eternal Sunshine of the Spotless Memory (or not)

I ordered the parts necessary to build a pair of extender boards for the Imlac, so while I wait for those to arrive I'll be working on other parts of the system (and the Imlac Emulator I'm working on).  Last night's endeavor was to clean up the nicer of the two core memory assemblies and see what I'm up against there.  So, I put on some MST3K ("Space Travelers" -- Gene Hackman's good in anything) and got to work.

Rust = Bad

You may recall from my earlier overview that the memory system is in pretty sad shape.  Because the PDS-1D was stored in a damp environment for some period of time there's a fair amount of rust on the machine. Fortunately most of the circuitry was protected by the chassis.  Not so for the memory -- it is mounted to the outside of the rear panel, and the cover that would normally protect it is missing.  As you can see at the right, this lead to some serious corrosion on most of the socketed chips.  It also wore the identifications off of most of the chips.  As if that's not bad enough, this is the one component of the machine I do not have documentation or schematics for, so I have no references to help debug the hardware.

I believe that this entire assembly (the control logic + core plane) was manufactured by Dataram, even though the control board is labeled Imlac, with Imlac part numbers.  I suspect this because of this blog post that I stumbled on on Dataram's site; if you scroll down this picture, despite its blurry dithering, is a dead ringer for the memory assembly I have.  It has more chips (I suspect it's an 18-bit memory board where mine is 16-bit) but is otherwise identical.

I have sent Dataram a query to see if they still have any documentation for 40 year-old hardware but I'm not holding my breath.  Since I don't have a Dataram part number it's difficult to search for.

My initial plan was to remove each socketed chip and clean its legs and socket as well as possible.  The legs are carefully cleaned with an XActo knife (gentle scraping with the sharp knife edge does wonders) and the sockets are cleaned with a spritz of contact cleaner (that's about the best that can be done -- the sockets do look to have fared better than the chips, fortunately.)  This took a long time and by the end my fingers were pretty tired, but in general things cleaned up pretty well.  About a dozen chips had legs that were so corroded that they were falling off so I marked those for replacement.

The other memory board is in considerably worse shape.  I pulled a random selection of chips from their sockets and all of them had legs that were corroded through.  I don't feel great about getting the first memory board running, but this one will take a miracle.

This afternoon I catalogued the chips on the boards.  The identifying numbers are very worn on both boards, but after cleaning the surface of the chip, under just the right light (and with a magnifying glass) I managed to get them all identified (see the picture at right).  Some of these chips are going to be difficult to find (in particular the Q2T3725 multi-transistor packages; there's an NTE equivalent but even those are hard to find and cost $7-$10 each -- there are 26 of them between the two boards.  Ouch.  The rest of it is standard 7400-series logic and I don't think those should be hard to find, though they're still not cheap ($3-$5).  If it weren't for the cost, I'd consider just replacing all of the chips pre-emptively, it'd probably be easier.  Maybe I'll do that anyway...

As an alternative, Tom Uban managed to replace his core memory with a small board containing modern semiconductor memory, it might make sense to do something similar.  It would definitely make debugging the CPU easier.

Decisions, decisions...

Update:  Just about 20 minutes after posting the above I actually stumbled on the manual/schematic set for the core memory!  As I suspected, it was manufactured by Dataram; it's a Dataram DR101 variant.  I've put a copy of the schematic (a whopping 64mb) here, if you care to look.  Maybe I stand a fighting chance now.

Signs Of Life (this time it's for real)

Two fairly major bits of progress were made yesterday on the Imlac restoration.

First, I got the 5V supply working properly.  I replaced the faulty power transistor, but this made no appreciable difference; the voltage went up from 1.25V to 1.5V so it had a small effect but this was still far off from correct.  There's a large heatsink for the four power transistors Q1-Q4 and I noticed that after being powered on for just 30 seconds or so this was getting extremely warm -- this hinted to me that something was drawing a lot of current, possibly a short or a faulty component somewhere.

Mystery Coil.

I immediately suspected the component to the right which is mounted on the rear panel along with the memory system. I'm unsure entirely what its intended purpose is; I've been discussing with my (much more knowledgeable) friend Ian and he suspects it's used for current limiting purposes.  However, the way it's wired up makes no sense to either of us.  The yellow wire is connected to the +20V unregulated supply, and the blue wire is the +5V regulated power supply.  I have no schematics for this particular section so right now it remains a mystery.

At any rate, it was also getting incredibly warm so it was a good candidate for being the current sink that was drawing the 5V supply down so dramatically.  I disconnected it from the +20V supply, powered the system up again and now the 5V was at 5.02V.  Nice.

Until I work out what the mystery coil is for, I won't be attempting to power up the memory boards, but until then I still have plenty of work to do on everything else.

The 5V supply under load

I hooked the 5V supply up to a moderate load (a 12V automotive bulb) and let it run for a half hour or so.  The voltage remained stable and ripple free.

Since everything checked out it was time for the fun part:  Powering up the CPU for the first time in 20-30 years.  I reinstalled the cards I'd previously removed, and powered it up.  Nothing exploded and the universe didn't collapse in on itself.  Voltages were nominal.

I powered it down again and installed the cabling to the "Control Console," and reapplied power.  LEDs lit up -- now we're cooking with gas. 

The Imlac, running for the very first time

Amazingly, many many front panel functions are working properly.  There are a few stuck bits -- Bit 3 the Memory Address register is stuck on; Bit 1 of the Memory Buffer register behaves erratically; Bits 3 and 6 of the Accumulator register are broken, and Bit 15 of the Program Counter behaves oddly.  But all of the registers increment properly when incremented using the "Read Next" or "Store Next" toggles, and I can load data into the registers mostly successfully (ignoring the stuck bits). 

Hitting the "Start" toggle causes the "Run" light to come on (though it doesn't do much since all memory is zeroes) and the processor seems to go through the motions of single-stepping and single-cycling if I enable those toggles.

This is a very encouraging sign -- I was honestly expecting no response at all -- having just this basic functionality working means that a good deal of the main CPU logic is at least minimally functional.  Though if all of the stuck bits are any indication, there are likely to be a lot of faulty components to trace down.

I spent an hour this evening debugging the stuck bit in the Memory Address (MA) register.  Bit 3 is stuck on (note for those playing along at home, the bits on this machine are numbered differently than most modern systems -- bit 0 is the MSB, bit 15 is the LSB).  The question is, what component is at fault here?  There are several possibilities:

1. The front panel is incorrectly displaying bit 3
2. The front panel is incorrectly loading bit 3 as a "1" all the time (a broken switch, for example)
3. The buffer in the CPU that holds the address has bit 3 stuck
4. Logic between the front panel and the buffer in the CPU is mangling data
5. Gremlins

#1 and #2 are immediately suspect, since Bit 3 behaves correctly for other registers on both load and store.

A pair of Buffer Control boards

To further rule out the front panel, we can try invoking some operation that updates the Address independently of the panel.  The only operation we have at our disposal is incrementing (via Read Next or Store Next).  With bit 3 already a "1," loading bits 4-15 with "1" and doing an increment should normally cause overflow into bit 2 and reset bits 3-15 to zero.  However, on the Imlac bit 3 remained on and bits 4-15 were reset to zero (bit 2 was untouched).  These simple tests eliminated #1, #2 and #4 from the above list -- the front panel is not at fault here.

The Buffer Control boards at right are used for control and storage for most of the registers in the machine (the Accumulator uses a different set of boards).  These are generic and interchangeable -- each board stores 8 bits of a register, so each register uses 2 of these cards.  The MA register is implemented as cards 208 and 209, for example.  208 controls bits 1-7, and 209 controls bits 8-15.  (Note that 208 does not control bits 0-7 -- the PDS-1D is limited to a 32K address space, so the MSB is not used).

1/2 of a Buffer Control board

From the schematic at the left you can see that the logic is fairly simple; we have a 74161 4-bit counter which provides the incrementation support, the outputs of this are connected to a 7495 4-bit shift register.  This provides the ability to shift the address by one bit in either direction -- but for the MA register these lines are unused and are not connected to anything on the backplane (the Memory Buffer register does use these lines to provide support for the shift and rotate CPU instructions).  The input to the 74161 passes through a 74H52 AND/OR gate which collects inputs from various sources (the front panel, the Program Counter (PC) or Display Program Counter (DPC)).

So, if bit 3 is stuck, who's to blame?  My first guess would be the 74161; since it's responsible for incrementing the upper 4 bits of the MA value, and since bit 3 does not change when bit 4 of MA is incremented it seems a very likely culprit. I 'scoped out the input (pin 4) and output (pin 13) and pin 4 was a steady 1.8V, pin 13 was a steady 3.8V and were completely unaffected by inputs from the console.  It's still possible that the 74H52 is pulling the input to pin 4 down but it's difficult to prove, at least given my still limited debugging skills.

I took a gamble and replaced the 74161.  Afterwards, Bit 3 was still stuck on, but I could occasionally get it to go out now, however the behavior was pretty random -- setting Bit 4 and then clearing it would cause Bit 3 to go out.  Any other operation would cause Bit 3 to come back on.  Weird.

At this point I figured it had to be the 74H52 so I replaced it as well.  Success!  Bit 3 works correctly now, and now the MA register seems to be 100% working.

With the MA repaired I can now address the boot ROM, which lives at address 40 (octal).  I can successfully read the boot ROM using the front panel (modulo the bug in the Memory Buffer register)!  This means that the memory addressing logic is working correctly, which is another bit of good news.

That's enough for tonight.  I plan to do two things to make debugging and repair easier:

• I need an "extender" board (similar to these, only smaller) for Imlac cards, so I can access the logic more easily.  (I debugged the MA board by tacking wires onto the chip leads with a bit of solder -- this is a royal pain in the ass.)  I plan to construct one or two of these before I continue the repair work.
• Having a better supply of 74XX series logic on hand would be very useful so I don't need to run out to the store every time I find a faulty chip.  I plan to order a small sampling of the chips commonly used in this machine so I'll have them when I need them; even if I don't use them in the Imlac they'll be useful for other repair projects.

 Egads, it's late.  That's all for now, catch you on the flip side, Kidd Video!

Quickie: Signs of life!

More details later, but I wanted to share this because I'm pretty damned excited:  5V supply works, and with the cards installed, I get basic signs of life on the Control Console!  I can walk through memory and put things in the Memory Buffer and Accumulator Registers.  Sure, there are a few stuck bits but who's counting?

Whoo!

(More to come...)

Power Supply Rebuild #2

Decided to bite the bullet and finish off the main power supply for the Imlac this evening.  Put on some MST3K ("The Mole People," man is John Agar insufferable) and got to work.  I'd replaced the big can capacitors last week, but I had yet to take care of sundry details like installing a new power cord.  (The old one had deteriorated into an extremely dangerous fire hazard.)

The newly re-capacitored power supply.  Shiny.

Armed with experiences from the last supply rebuild, I also cleaned all the fuse holders and cleaned the regulator PCB's edge connector.

The wiring harness for the main power supply

For testing, I opted to pull the cards from the backplane rather than undo the backplane power wiring.  There are a lot of wires and it'll be easier to check voltages with them screwed down.  Pulling the cards is simple and also ensures that if I miss a wire somewhere (or if there's an unfortunate short I didn't find in the backplane, for example) I don't destroy the CPU if the supply's way out of tolerances.

Having done all of this, I plugged the new power cable in and flipped the On/Off switch.  The power indicator lit up, the fans spun up and there were no loud bangs, smoke, sparks, or fire.  That's a good start!  Checking the outputs from the regulated supply, the -5V, -15V and 15V supplies were good, but the 12.5V was at 2.5V and the 5V was at 1.25V.  Hm.  Voltages at the unregulated end (+20V, -20V and +10V) were all fine.

Partial schematic for the regulated supply

Powered down and double-checked connections but it made no difference.  Time to do some deeper checking. I figured I'd start with testing the power transistors, these are TO-3 units (the four transistors on the upper-left side of the schematic).  As luck would have it, Q4 was bad!  For good measure I tested the other three, and they all tested out fine.

Bad transistor! Bad!

These are 2N3055s which are still in abundant supply so it should be an easy part to find.  Looks like I'll be making a stop at Vetco tomorrow to pick up a replacement.

So, that's the progress for today.  Perhaps tomorrow we'll have a working supply, and if so I'll be seeing how the CPU runs (or doesn't).  Stay tuned!

Weekend acquisitions (and tiny Imlac update)

A brief departure from Imlac repairs for today (the 18V supply tests fine under load as well -- now onto the main supply...)

Took a drive down to Goldendale, WA this weekend to take a look at some interesting computer junk/stuff that a fellow collector was offloading, and I ended up picking up a few items of note.

A very dirty Motorola EXORmacs development system

The first computer is a Motorola EXORmacs system, with EXORterm 155 terminal.  This is an early 68000-based system (1979/1980, which is about as early as the 68000 goes) primarily meant to be used as a platform for development of other systems that were to use the 68000 processor, but it's a pretty full-featured system itself.  It features the VERSAbus, the grandpappy of the VMEbus which was used in a wide variety of systems. 

The extremely dirty VERSAbus backplane

The picture to the left does not do justice in describing just how filthy this particular computer is.  It is also incapable of capturing the unique odor it emits.  This computer will require a lot of cleaning before I even bring it in the house.  But it is complete, sans any sort of mass storage.  I'm fairly sure it used bog-standard 8" drives so it shouldn't be too incredibly difficult to interface something to it, provided I can find something to run on it to make such an effort worthwhile.  There's precious little information out there about this system, let alone any kind of software.  It did come with a box of documentation, however, and I hope to get that scanned at some point in the not-too-distant future to remedy the lack of info on the 'net.  For now, this system's going to sit in storage until I have some time to disassemble it and give every part a thorough scrubbing.

Interestingly, the EXORterm terminal itself can also be a standalone computer; it has its own backplane (currently empty) that can house EXORbus cards.  As it is, it's just a dumb terminal (but one based on the Motorola 6800 8-bit CPU).

Mini-Micro Designer MMD1

Item two from this weekend is a cute 8080 prototyping board, a Mini-Micro Designer MMD1, from 1977 or so.  I love these early single-board computers for some reason, and I couldn't pass this one up.  The keypad's a bit rough but other than that it's in good shape.  512 bytes of memory (in 4 2111 RAMs) and a very basic monitor (256 bytes) in a 1702 EPROM.  The area on the bottom left is meant to be filled with a breadboard area, but it appears to never have been installed on this one. I haven't powered it up yet (need to find my supply that does 5/12/-12) but I bet it works fine.  And if it does, I can use it to read all of those 1702s I have that I've been wanting to dump.  (1702s are early enough that I've had a heck of a time finding something capable of reading them.)

HP 9000/332

Number three on our computer scavenging operation is an HP 9000/332 workstation, with matching 35731A monochrome monitor.  I believe this machine started life as a 9000/310 -- this was a 10Mhz 68010 based machine.  It has been upgraded to a 16Mhz 68030 machine with 68882 FPU and 4MB of memory.  Sweet!  The keyboard does not appear to be working at the moment (I have a spare somewhere) and I don't have any HP-IB drives on hand to install anything to, but I hope to get NetBSD running on this at some point.

I think I've saved the best for last:  A Metheus Omega 400/DS Display Controller, circa 1983.

The Metheus Ω400 Display Controller (cover removed)

This is an external display interface used in conjunction with a host machine (such as a PDP-11 or a VAX) to produce high-resolution graphics.  The Omega 400 supported a variety of host/processor interfaces, including RS-232 and parallel data interfaces.  The host computer sends the Omega drawing instructions (for points, lines, arcs, polygons, etc) and the Omega 400's bit-slice processor (using good ol' AMD 2901s) would transform them into raster graphics on the fly. 

The Metheus Omega 400-series supported resolutions up to 1024x768 at 256 colors out of a palette of 16.7 million (with a refresh of 33Hz - ouch), with hardware accelerated line, rectangle, arc and polygon rendering, as well as zooming and rasterop support.  This was pretty amazing stuff in 1983 (and it still impresses me)!  As I said before, the processor is built off of AMD 2901s and it's microcoded; the microcode could be updated to accelerate new functionality if needed (I'm unsure if this was documented publicly, however.) 

A close up of the processor memory and logic

I don't know a ton about the history of either Metheus or this particular piece of hardware that they created.  Metheus was based out of Hillsboro, OR and made a number of high end graphics systems (standalone and later for PCs) over the years.  They were bought out by Barco in 1999.

In addition to the Omega 400, I have a number of interface boards (serial and parallel) and an interesting Front End Processor (FEP) board.  I believe that an Omega 400 equipped with this FEP board becomes an "Omega 2000" series -- the FEP board (also referred to as a "Graphics Preprocessor) provides extra hardware interfaces and a higher-level graphic API.  The documentation I have states that the Omega 2500 can draw vectors, characters and filled polygons at a rate of 1.5 million pixels/second. 

The FEP/Graphics Preprocessor board

From the manual's description of the Graphics Preprocessor:

"The purpose of the graphics preprocessor is to translate high level, device independent graphic instructions, such as those described in the Graphical Kernel System (GKS) and the virtual device interface (VDI) specifications, into instructions recognized by the display processor.  In addition to translation, the graphics preprocessor supplies the input/output ports for host and peripheral communications.  Together, the graphics preprocessor constitutes a heirarchical display-list processing system with the following capabilities:

• Segment structures
• 2D transformation and clipping
• Graphics primitives for points, circles, arcs, polygons, polylines, and polymarkers
• Graphics attributes such as color and style
• Graphics text and text attributes such as font and spacing
• Pixel operations
• Input support for locator, pick, and button-type logical devices
• Macro capability
• Keyboard and terminal display window functions"

The FEP's 68000 CPU

I have a very complete set of documentation for this thing; everything from the user manuals to schematics, microcode tutorials and blueprints for building the chassis.

I foresee having a lot of fun with this thing.  I'm thinking of perverse things like, oh, a SWTPC 6800 with a 256 color 1024x768 framebuffer...

Power Supply Rebuild #1

Well, the replacement capacitors arrived from Mouser this week, so what better way to spend a Friday night than fixing up a rusted old power supply?  I cleaned off some space on the workbench, put on some MST3K ("The Screaming Skull") and got to work.

The 18V Memory Power Supply

I thought I'd start with the 18V supply for the core memory.  It's mounted to the outside of the chassis, it's easy to disconnect, and it looks like it needs the most actual work -- why not start with a challenge.

Do you know the Muffin fan?

As you can see from the above photo, we've got a big ol' transformer on the left, a Muffin fan in the middle, and the rest of the power supply on the right.  You might also notice some extra rust on a few power supply components...

Uh oh.

Can't say I was happy to see the heavy rust on the two potentiometers here.  These are labeled "LIM ADJ" and "OVP ADJ," which I would wager stand for "Limit Adjustment" and "Over Voltage Protection Adjustment."  I don't have schematics or documentation for this power supply, so I have no idea what values these pots have, nor do I know how to properly adjust them.  Given that, my plan was to clean them as well as possible and hope I could either find identifying marks or at least be able to measure the range of values and the current settings myself.   You can also see a bit of rust on some of the output transistors, but this shouldn't affect operation.

So, let's start with these, shall we?  I desoldered the pots one at a time and gave them a nice long (15 min) bath in "Blaster PB," a strong smelling rust remover that I used extensively on a rusty Nash Metropolitan a few years back.  This stuff is nasty, so I cracked a few windows...

This loosened the rust quite well and the potentiometer wipers now turned freely.  They still looked pretty ugly.  I scoured them a bit with some Scotchbrite and that got a lot of the surface rust off, but they're never going to look all that nice again.

One potentiometer, now slightly less awful.

I gave them a bath in soap and water to remove the Blaster residue, dried them out and gave them a nice go over with some contact cleaner.  Amazingly, they now read nice clean resistance values from one end of the wiper to the other -- no dead zones or otherwise.  The insides are nice and clean.  So, I guess for now I'll continue using them.  I returned the wipers to their original positions so they wouldn't be too far off their original values.

There are four capacitors in this power supply that I'm going to preemptively replace.  I tend to go for a "shotgun" policy on old capacitors since capacitors this old are basically ticking time bombs.  Given the condition of this machine, I don't trust these things at all even if they do test good.

The capacitors to replace are:

• 11,000mfd 50V (large can, screw leads)
• 1,000mfd 50V (axial leads)
• Two 470mfd, 35V (radial leads)

Some quick desoldering and the job's complete.

All cleaned up.

Now we wire up an AC cord, cross our fingers, and plug 'er in...

The fan spun up (and sounded good, which is nice... I don't have to replace the bearings or anything fun like that) but I only got about 0.5V from the supply.  I powered it down and checked a few things for continuity.  The fuse tested good earlier, but I never checked that it was making good contact with the holder.  It wasn't.  Some contact cleaner and Scotchbrite rectified that.  On the next powerup I got 18.8V.  Not bad (sometimes the simplest things are the problem -- I prefer it that way...)  I adjusted this down to 18V with the voltage adjustment pot (the one on the far right in the photo above), though this will need to be re-adjusted once it's running with an actual load.

Lookin' good!

I'll need to do some more testing under an actual load tomorrow, but the initial checkout looks promising.  A nice steady 18V with no appreciable ripple.  I'll take that for tonight.

My new project

My PDS-1D, serial number 277

As you may be able to tell from the above, my Imlac is in pretty sad physical condition.  There's quite a bit of rust on the chassis and it's been banged around a bit.  But I'm remaining optimistic, I think under the rust-covered exoskeleton is a heart of gold.  Or silicon.  Or not.  Anyway, we'll see.  Let's take a closer look.

With the front cover removed, we can see the card cage, with a few dozen cards installed.  These contain the majority of the logic that comprises the computer -- both data and display processors, I/O and display controllers. These are installed in wire-wrapped slots; you can see a few empty slots indicating potentially missing hardware -- not really a great way to start things off.  Fortunately, it does not appear anything vital is missing (more on this later).

Of interest is the blue wire-wrapped prototype board in the lower-right corner.  I'm not entirely sure what purpose it serves yet, but it incorporates 3 74181 4-bit ALU chips, likely forming a 12-bit ALU.  Based on this and its location, I suspect that it is a hand-made equivalent of the LVH-1 "Long Vector" hardware option which normally would sit in the slots directly adjacent to it (and is currently missing.)  (The LVH option allows the Imlac to draw "long" vectors -- without this hardware, any vector longer than 9 units or so has to be manually split into many smaller segments, adding a great deal of computational and memory cost.)

To the right is a close-up shot of one of the cards installed in this machine.  This particular example is a D/A converter board used to drive the X output to the display.

 Now let's traipse on over to the rear of the machine.  The rust's looking a bit more fierce here.  Other PDS-1D's I've seen just have a rear cover here, but mine has a set of core memory (two 8K core planes) and an extra power supply to run it.  The cover for the core memory is missing and as a result, the core logic board has been exposed to the elements for awhile, resulting in significant corrosion to many of the components on it.

A close-up shot on the exposed core memory logic board.  That's not the kind of thing I like to see.  Cleaning that up and ensuring good connections is going to be a pain.

Two captive screws unscrewed and that back cover (plus memory assembly) swings out to reveal the wire-wrapped backplane.  Fortunately, things here look great.  No signs of corrosion, tampering, or damage from small rodents.  And it's wonderful that the backplane is so easily accessible -- this will greatly aid in debugging.

A closer shot of some of the wire wrapping.  Kind of a maze of wires.  Hopefully I don't have to spend too much time tracing this out.

On the right side of the machine is one half of the main power supply.  This is a fairly standard unregulated linear supply, which is fortunately pretty simple.  We have two gigantic transformers to take the 120V AC and drop it down to something closer to the lower voltages we'll need to run the computer, a set of large diodes to rectify that AC, and some gigantic electrolytic capacitors (those big silver cans) to smooth the supply out into happy clean DC.

On the left side of the machine is the regulator for the supply -- this takes the unregulated DC from the right side and regulates it to a nice even 5V, 12.5V, and 15V for the computer to use.  Both sides of the power supply look very good -- there's a bit of corrosion but not on anything that should impede operation.

I was fortunate to get the "Control Console" along with this machine.  This is a separate unit from the main processor, and plugs into the backplane via two very long ribbon cables.  Using this console, one can examine/modify memory, single-step or halt the CPU, or examine processor registers.  This will be absolutely essential in debugging this machine.

The console's in great shape and hopefully will not need too much work to get going.

And of course no machine is complete without a keyboard.  This is effectively an ASCII keyboard (8-bits parallel output) with a few interesting keys on it (see below).  It's in great condition and I don't foresee any issues with it.

 

The interesting keys on the Imlac PDS-1D keyboard, apparently geared toward some manner of text processing.

So that's a brief tour of the machine.  Here's a rough assessment of what I've got ahead of me:

The Good:

• Based on the schematics, the boardset I have is fairly minimal, but complete.  I have the main CPU logic, the X/Y D/A converters, two Asynchronous serial ports, one synchronous serial port, the IOT controller and a DMA controller.  The memory system I have is different than the one in the schematic set, but it looks to be complete.  I do not appear to have the Long Vector hardware, but it may actually be provided by the wire-wrapped prototype board.  The Long Vector hardware isn't required to run the machine, but a lot of fun software (like Maze War) requires it, so it would be really nice to have.
• The wire-wrapped backplane is solid and should not be a source of issues
• The Control Console and Keyboard are in great shape, as are the power supplies.
• I actually have documentation for 90% of the stuff in the machine, both hardware and software.  While it's not extensive, it's far better than nothing.

The Bad:

•  Astute readers may have noticed there was no display covered in the tour.  That's not an oversight -- the display is missing.  As this was a custom vector-based display, this is unfortunate: given the tiny number of Imlacs left in existence, the chances are approximately zero that I'll be able to find another.  On a positive note, it should not be incredibly difficult to hook up an oscilloscope as a makeshift replacement -- the Imlac appears to output simple analog X/Y signals.  I hope that long-term I can build a suitable replacement, perhaps using a vector display from an old Asteroids arcade game or something similar. 
• The corrosion on the core memory control boards is going to be a pain to clean up.  I expect that many chips will need to be replaced.
• The rust on the chassis doesn't look incredibly pleasant.
• The 10% of the hardware I lack documentation for (namely the different core memory system and the custom wire-wrapped board) may end up being a source of problems.  Keeping my fingers crossed.

Basic Plan of Action:

Roughly, I plan to attack the restoration of the machine as follows:

1. Document what I have; take lots of pictures and scan the individual boards for future reference.  Check the boards for obvious damage or other faults while I'm at it.  This is already done.  I've put up these pictures and scans here and here, feel free to peruse them.
2. Rebuild the power supplies.  This entails (at minimum) replacing the old electrolytic can capacitors with new ones.  Some people believe in reforming old capacitors rather than replacing, I happen to think it's voodoo, especially with capacitors pushing 40 years old.  I'll be holding onto the originals so I can restore the system to its original state if I need to.  Once I have the power supply running within tolerances I can move onto step 3.
3. Power up the CPU, sans memory subsystem.  I should be able to drive the CPU from the Control Console to do very minimal functional testing.  Let the debugging commence!
4. Clean/repair/test/debug the memory subsystem.
5. Rig up an oscilloscope as a display, test/debug!
6. Test/debug I/O so I can load programs from a host PC.
7. ...
8. Profit!

I see a lot of debugging in my future.

Until next time, keep watching the skies!

The Imlac, continued

An early PDS-4 at RAL (from here)

So let's pick up where we left off, shall we?

Peripherals

Of course, a computer's not all that useful without ways of getting information into and out of it.  The PDS-1 had a decent set of peripherals available for a machine that was intended to be a smart terminal.

Storage

The staple of any computer in that day was Paper Tape.  Simple, durable, and foolproof though quite slow, paper tape (via the PTP-1 option) was a good way to store programs and data for the PDS-1.  The REL-1 option offered cassette-tape based storage. There weren't too many other local storage options -- in many cases program and data storage was provided by a larger remote host (a PDP-10 or PDP-11 or an IBM mainframe) that the PDS-1 was linked to over an asynchronous serial (usually RS-232) interface. 

The PDS-1D introduced a removable disk option (the IODISC 2002) with a capacity of up to 48 million bits (6MB or 3MW).  I've read anecdotal reports that these drives were not particularly reliable, and I do not know how many of them were actually used.

The IODISC 2002 removable pack drive

Input

The Imlac PDS-1D Keyboard (mine)

In addition to the standard Keyboard (see above) one could also outfit a PDS-1 with a light pen, a digitizer tablet, and a mouse for interacting with objects onscreen.

Software

The PDS-1 was used for all manner of applications, most of which have been lost to the mists of time.  It was commonly used as a terminal, and several terminal emulation packages were available (probably the most popular was of the Tektronix 4010). 

An Imlac display, showing a circuit design application (from here)

Applications for graphical editing of circuit designs (shown above) were available, as was a graphical frontend for FRESS, an early hypertext document editing system.  There were compiler packages available for FORTRAN which was (understandably) very slow, and the usual suite of assemblers, linkers, and other utilities.

But of course no discussion of the Imlac would be complete without covering Maze War, which may be the first multiplayer 3D-shooter ever created.  Played between two Imlacs linked together, or between multiple Imlacs linked to a larger PDP-10 host, Maze War pitted players against each other in a 3D Maze (as might be inferred from the game's name).  Players hunted each other down and the last man standing was the winner. 

Maze War started on PDS-1s at NASA in the early 70s.  Tons of information about the original Maze War and its many many offspring can be found on the DigiBarn site here.

Other Imlac Computers

The PDS-1 was quickly followed by several other models.  Some of these were simple revisions, while some had major enhancements over the original.  Unfortunately, information is very scarce on many of these -- if you have any information about them, please do drop me a line!

An Imlac PDS-4

• PDS-1D: Introduced around 1972, this was a cleaner design of the PDS-1.  It's rumored that the "D" stood for "Density" as the PDS-1D had a more dense configuration of components, allowing for greater expansion.  This is the Imlac model that I will be working on restoring over the coming weeks and months.
• PDS-1G: Introduced in 1973.  I can find nothing of substance about this model, other than that it existed.
• PDS-4: Introduced in 1974.  A faster machine capable of refreshing many more vectors in the same amount of time as the PDS-1D; it also had hardware support for mirroring and rotation (in 90 degree increments) better scaling support, support for variable beam intensities and blinking (very, very important!)  I have very little information about this machine, other than an instruction cheat-sheet.  The instruction set is very similar to the PDS-1 series.
• Imlac Dynagraphics "Series II" Terminals.  In 1979, Imlac was bought out by Hazeltine (a maker of terminals) and this appears to be the last terminal made with the Imlac name on it.  From Wikipedia: "It had 2Kx2K resolution, 192 kilobytes of ram, and an 8086 microprocessor, all inside the monitor unit." 

What's next?

Well, now that we're all nice and acquainted, we can start talking about my project:  A PDS-1D (S/N 277) that's seen better days.  In my next post, I'll go over what I've got, where I'm going, and how I hope to get there.

An introduction to the Imlac PDS-1

The Imlac PDS-1, c. 1970

The Basics:

The PDS-1 was introduced in 1970 and was, as the Technical Manual describes it, "either a Very Smart Terminal or a pretty fair computer with display."  For around $8300 you got a system with:

• 4KW of core memory (in 16-bit words)
• A 16-bit data processor operating in parallel with a display processor
• 2 microsecond instruction time (500Khz)
• A 14" vector display, refreshed at 40Hz, with 1024x1024 addressable points (technically 2048x2048 in 1/2 scale "increment" mode.)

The system could be expanded up to 32KW of memory, and could be attached to all manner of peripherals from Paper Tape Readers to light pens, mice and disk drives.  While it was most often used as a "very smart terminal," as a standalone computer it was actually fairly capable, especially given the (relatively) low cost.  All of this was enclosed in a handsome (ahem) desk, perfect for your local university or research lab.

If you look at it just right, the PDS-1 could be considered a very early graphical workstation.  It was also host to a number of interesting games thanks to its graphics capabilities.

The Data Processor:

I've often seen the PDS-1's main (or "data") processor described as "a 16-bit PDP-8" and that's really not far from the truth.  There's one 16-bit Accumulator register, and the instruction set is remarkably similar in scope and behavior to the PDP-8's.  It does have a couple of enhancements over the PDP-8 -- aside from the wider wordsize, it's also able to address a full 32KW of memory in a flat address space whereas the 8 had 8 4K "fields" that took extra steps to address.

The Display Processor:

The display processor runs in parallel with the Data Processor and its only job is to refresh the vector display.  It does so by processing a set of instructions (a "display list") created by the main Data Processor.  These instructions generally fall into two distinct modes (though there are others provided by different expansion options): Processor and Increment.

Processor mode instructions provide operations to control the flow of execution of the display list.  It should be noted that there are no conditional branches available -- only unconditional jumps and unconditional subroutine calls.  Further, these instructions cannot modify memory, only read from it.  In addition to flow control, Processor mode includes instructions for directly manipulating the X/Y positioning of the vector display.

Increment mode instructions are used to do the bulk of vector drawing, and it is generally intended for drawing text (though with a bit of ingenuity you can do just about anything).  In Increment mode, each 16-bit memory word is treated as two 8-bit instructions, each of which describes a short vector (+/- 3 points in both X and Y).  A scale of 1/2, 1, 2, or 3 may be applied to these vectors to facilitate drawing larger glyphs.

Vector Description of the Letter "d" (from the Programming Guide)

By having separate increment-mode subroutines for each character, the bulk of the display list can consist of nothing more than a set of subroutine calls, one per character.

When running, the Display Processor steals memory cycles from the Data Processor -- this means that a display with a lot of text (for example) will reduce the amount of CPU time available.

Whew, that's probably enough for now... I'll talk a bit more about the PDS-1 in my next post.  In the meantime, if you want to read up on the technical details, Bitsavers has the Programming Guide and Technical Reference manuals available -- see here.