Introduction

I waited a long time to find a PDP-8/m and the one I finally settled for was in very sad shape. Every board was found to have lots of problems and the 8K memory board set was no exception. The problem with trying to debug such a computer is that you have no place to start. To debug the CPU, you need a working memory. To debug the memory, you need a working CPU. My solution was to build a RAM board for it. Besides facilitating debug, it would serve later to fill out the full 32K memory space of the machine. (The PDP-8 has a 12-bit word, so that’s 32K x 12.) I have plans to run some significant software with the system and within my budget, there is little hope that I would ever be able to buy enough real core to fill it up (even if I could find it). Indeed, it would require a total of twelve memory boards, which won’t fit in my PDP-8/m, anyway. (Each 8K core memory set consists of three boards.)

Note: The first sections of this article cover the design of the RAM Board. If you just want to build the project, you can skip down to the build section.

Design Requirements

Here is how the design requirements (goals) guided the design:

1. Battery backup with long life. Battery change without data loss. I wanted to be able to regard this as being as solid and reliable as core memory. Didn’t want to have to worry about the battery for many years. When I do have to change the battery, I want to be able to do it with the power on, so memory isn’t lost.
2. Inhibit on power fail to prevent memory corruption. Part of making it solid is insuring that there is no way for the memory to be written when power is going down.
3. Easy to build and low cost. This was one of the first steps in debugging this machine. To be honest, from the looks of the critter, I wasn’t sure that it would ever run. I needed to get on with the debug as soon and as easily as possible. I also wanted to make it easy to build for other hobbyists who might want to use the design. If at all possible, it would be best to stay with through-hole parts, to avoid the cost and hassle of SMT carriers. All parts needed to have 5V power, of course.
4. Fits in a single slot. It’s not the board area. It’s the thickness. DEC used 1/2-inch spacing to pack these boards in. The PDP-8/m only has half the slots that the PDP-8/e has, so I could not afford to take up an extra slot, with the thickness of the board. That ruled out using wirewrap construction. It also precluded making a small PCB and mounting it on a carrier prototyping board. Making a full Omnibus-size PCB was prohibited by the estimated $200-plus cost. A suitable prototyping board (model 12-DE-8) was available from Douglas Electronics for about $60. (Quantity matters a great deal in PCB fabrication pricing.)
5. Cooperation with any mix of core memory or ROM boards. To preserve authenticity, I still want to be able to mix in real core memory boards in the system. To support that, any 4K segments of the RAM board can be disabled. In addition, support is provided for overlaying portions of this memory with ROM.
6. Compatibility with the Omnibus. The bus used in these machines has pretty tough requirements and the original driver and receiver chips are rare and low density. This threatened to make the project hard to build. Fortunately, I found ways to employ modern chips, without compromising the bus.

Planning the design needed to address the following questions:

• How do we interface to the Omnibus?
• How do we implement non-volatility?
• What logic is needed to control the RAM?

Interfacing to the Omnibus

Introduced in 1970 with the PDP-8/e, the 144-line (96-signal) Omnibus uses the M8320 terminator board to pull most signal lines up to a high logic level of 3.5-3.8VDC. Four different termination circuits are used, as mentioned in Reference #1, p.9-8. However, it contains some errors, which are corrected here. Terminator circuit “Load-1” (at right) provides a pull-up to 3.8V and presents an AC load of 112-ohms. This tends to damp out transients. Open-collector drivers, used to put data on the bus, must sink about 34mA from this circuit. In Reference #1, the logic low is specified at -0.5 to +0.4V and the logic high is 3 to 5V. Load-1 is used for timing signals TP1-H, TP2-H, TP3-H, TS1-L, TS2-L, TS3-L, TS4-L and others.

Load-2, by pulling up to +15V, supplies more of a constant-current load, speeding low-to-high transitions. Max current is only 10mA though. Signal voltage is clamped at about 3.5V. These loads are used for the Memory Data bus (L), C0-L, C1-L, C2-L, SKIP-L and others.

Load-3 pulls up to +15V only during the timing pulse, TP4 (open otherwise). Max current is 32mA, giving the speed benefits of semi-constant current and high current. It’s brief duty cycle reduces power dissipation. Signal voltage is clamped at about 3.5V. Signals served by this load include the Memory Address bus (L) and processor state signals D-L, E-L and F-L. A similar load is used for MD-DIR-L, except that it’s clocked by TP2 instead of TP4.

Load-4 is just like Load-3, except that it pulls towards +30V (but still clamped at 3.5V). Also, it’s clocked by INT-STROBE. Max current of 30mA is about the same. The only advantage that I can see is that it’s a little better at approximating constant current, yielding a slight speed increase. Only the DATA bus (L) and INT-IN-PROG-H use this load.

To summarize the loads, all we really need to know is that all can be driven with open-collector/drain outputs, the levels are like TTL and the max sink current required is 34mA.

Drivers and Receivers

When this project started, I imagined using bus receivers and drivers similar to the ones which DEC had used on the PDP models. Actually, they used different bus drivers/receivers over the years, so Omnibus interface elements vary. However, it turns out that the DEC Unibus uses some of the same drivers and receivers as the PDP-8/e Omnibus. In (Unibus) Reference #2, I found the table at right, which provides key specifications. In addition, driver and receiver capacitance is limited to 10pF max. [The Unibus seems similar to the Omnibus.]

Individual drivers and receivers such as these are both hard to find and typically accommodate only four-bits per dip package. Using them would have compromised Goal #3. Examining the specs, we see that they are close to being standard TTL, with the following additional requirements:

• Low receiver input current of 160/25uA.
• High driver output sink current of 50mA.
• Minimum receiver input low threshold of 1.4V.

The CMOS parts used in this design interface with TTL logic levels and easily meet the receiver input current spec. The 74ABT245 bus transceiver sinks 64mA minimum, covering the driver spec.

DEC’s Little Secret
I did a quick survey of some DEC board schematics to see what other chips they might have used as Omnibus receivers and boy did I find a bunch! In addition to using the DEC380, they often used plain TTL logic gates to receive Omnibus signals. From the brief perusal, here are some examples:

The conclusion from this table is that DEC certainly regarded standard TTL input specs as adequate for an Omnibus receiver. (They did take steps to minimize the impact of the 1.6mA TTL input current, though.) In fact, I found TTL receivers on most board schematics that I looked at. These were employed for timing signals, control signals and for data buses. They certainly used the DEC380 for receiving as well but the regular TTL receivers were anything but rare. We saw above that the modern chips ace the requirements on the driver side.

Omnibus Receiver Input Levels
The DEC380 (Signetics SP380) receivers which are cited in the Unibus Interface Manual have an input threshold voltage of about 1.75V while standard TTL has about a 1.3V threshold. However, from the table above, DEC practice makes it clear that SP380 receiver specs are not considered necessary. We use the RAM chips (CY62256) to receive address. Input levels are specified at 2.2V and 0.8V. The 74ABT245 receives data. It has input levels of 2.0V and 0.8V. Finally, the 74ABT540 receives control signals with input levels of 2.0V and 0.8V. If we estimate the thresholds as the mean of the guaranteed input levels, we get 1.4-1.5V, which is a little closer to the SP380 than TTL.

The fact is that the Omnibus swings good TTL levels and our receivers’ guaranteed logic levels meet TTL specs. TTL Omnibus receivers are endorsed by DEC designs. Moreover, a minor difference in logic threshold won’t make a big difference in noise immunity. The conclusion is that these chips, used as receivers and drivers for the Omnibus, meet the interface requirements pretty well. Sixteen months of solid operation of this board and the good results reported by other builders support this.

Driver Slew Rate

I have seen postings which claim (without references) that Omnibus drivers should have slew rate limitations. I found no such spec in Reference #1, #2, #3 or #4. Checking the datasheet for the SN7439 TTL device (which has been commonly accepted as the source of the rebranded DEC8881 driver), no slew rate limit was found. Indeed, the 18ns max propagation delay spec there is faster than the logically equivalent 7400, which takes 22ns. Other than the open collector output, the chip schematics (at right) are the same, except for lower resistor values in the beefy 7439. Those are consistent with the faster speed and heavy drive current rating. I conclude that there was no attempt to limit the slew rate of the DEC driver.

Of course, laying specs aside, critics can always object theoretically, saying that the faster chips of today were unknown and that is why slew rate isn’t specified. Critics should remember that the slower chips of yesteryear would also be less sensitive to the shorter dis­tur­bances of modern drivers. I’ve been all over the Omnibus with wideband scopes and haven’t seen any problems from edge transitions from this board. With any newer technology, it’s easy to come up with imaginary fears about all sorts of things. Unless such fears are backed-up with evidence, they can’t be regarded as valid objections to proven, successful products.

The fact is, this memory is so fast and the PDP-8/e cycle is so strung out, that it’s hard to imagine this board kicking up glitches anytime that the processor cares about it. By the time that the CPU or other boards latch something, the memory has been sitting still for ages. As cited above, months of glitch-free operation are a testament that there is no problem with the slew rate of the drivers used here.

The Open Collector Bus Issue

One aspect of driving the Omnibus which isn’t addressed above, is the fact that DEC uses open collector drivers. This automatically precludes fault currents which could be caused by bus contention. Limiting ourselves to an open collector or open drain driver these days would seriously reduce our choices. It would lead us back to small scale, low density chips which would compromise Goal #3. One way to get an equivalent driver would be to use a tri-state buffer and only enable it when delivering a logic-0. This would require a separate tri-state control for each bit though, which would only be provided in low density chips.

I thought long and hard about the MD bus, which comprises the only Omnibus lines that this card is driving. The fact is, only the CPU and memory cards talk on it. The CPU is listening whenever the MD-DIR line is low. Then, only one memory card is addressed to talk. There is no way for a bus contention to occur. So there is no reason not to use a push-pull driver. Going this route greatly simplifies the design, since we can employ the 8-bit-wide 74ABT245 bidirectional transceiver. This works beautifully with the bidirectional data lines of the RAM chips.

ESD Protection

With the CMOS RAM and other chips directly connected to the edge of the card and to the Omnibus, I was much more concerned with ESD questions than the minor threshold issue. There was a time when I would not have designed a board with CMOS inputs wired directly to the edge connector. As mentioned above, I originally thought in terms of using good old bipolar interface chips, which have an excellent reputation for robustness. But I needed to abandon those in favor of more available and effective parts. Studying the ESD specs and data made me realize that protection for CMOS ICs has come a long way in modern times (symbolized by the patented scheme pictured). In our case, the RAM chip is the most vulnerable component and it includes 2kV MIL-STD-883 static discharge and 200mA latchup protection.

A few years ago, I designed a CMOS chip and was all over the I/O protection network thing. Seems to me that they are tough enough, given that you don’t make really dangerous moves. For example, walking across a carpet with board in hand and plugging it in, without first discharging yourself to the computer ground, would be a no-no. I’ve made a point of not babying the memory board. Have had it in and out many times without discharging myself and have left it lying around on the bench. No static bags around here. Works fine. Naturally, you should not insert the card with the computer powered up. And don’t get me wrong: I do recommend that you practice good static control when handling or inserting the RAM board. My efforts to “kick it around” some were just to establish a margin of comfort, concerning its robustness.

Tying Off Unused Memory Data Lines

The simplest way to handle the mismatch of the 16-bit RAM and 12-bit computer is to ignore the four unneeded bits. However, when IC1 and IC2 are receiving data from the MD bus, we cannot let the four unused inputs float. Floating CMOS inputs can result in unwanted current draw and damage the chip. Tying them to ground won’t work because those are also outputs and could source excessive current in that condition. So the solution is to tie those lines to ground through 10K resistors, R1-R4.

Choosing a Non-volatile RAM Solution

My initial inclination was to use a CMOS RAM chip with battery backup, as it seems like a simple, straightforward approach. I perused Jameco, taking their somewhat limited offerings as a good sign of popularity and availability. There, the 32Kx8 CY7C199 caught my eye. (The idea was to use two chips and just ignore the extra four bits, not needed for the 12-bit word of the PDP-8/e.) It’s just $1.95, it’s very fast (35ns) and it’s asynchronous. That last item means that I wouldn’t have to worry about clocking the read; just apply an address and the output data updates. The 2003 datasheet touted 10uA max standby current in the data retention mode.

Alas, this chip was not to be: The datasheet only supported the data retention mode for the “L” version of the part. Although the Jameco catalog description included the abbreviation, “LP,” there was no “L” in the manufacturer’s part number. Checking with Jameco confirmed that theirs was not the L-version. Unfortunately, neither Mouser nor Digi-Key stocked the L-version in a through-hole package, either. I noticed that a more recent datasheet has removed all references to the L-version and now specs standby current at 3mA. So that chip was out.

NVRAM Devices and a RAM Solution

Looking around for RAM chips, I noticed that self-contained nonvolatile RAM modules (which I will call “NVRAMMs”) are available. Let’s distinguish these from flash memories, which aren’t appropriate for this application: Flash chips write in blocks and have a limited number of write cycles. What we need is a device which writes individual words on an unlimited basis. The NVRAMMs that I found, contain a regular RAM chip and either a battery or a flash memory for backup. Flash types automatically transfer the contents of the RAM to flash when the power falls and restore it when the power comes back up.

The 32Kx8 Maxim DS1230 (similar at right), a Lithium battery type, costs $16 at Mouser and is good for 10-years. The problem with that part is apparently, you can’t replace the battery of the through-hole version. I also looked at the 32Kx8 Cypress STK16C88 flash-type NVRAMM, which costs $13 at Mouser. It’s being phased out and the replacement is neither 5V nor through-hole. Nevertheless, since the STK16C88 is still in production, I considered using it. After all, the prospect of getting rid of the battery altogether is very attractive. Unfortunately, I could not find any ESD specs in either the commercial or military versions of the datasheet. This, along with the fact that it is being discontinued and has some spooky voltage/timing/retention requirements, discouraged me from using the part. Not to mention that the two required would cost $26, versus the $4 we would have paid for a pair of CY7199s.

So, it was back to looking for a battery-friendly CMOS RAM. Specifically, I needed one with a low-voltage, low-power, data retention mode. The chip I found and ended up going with is the Cypress CY62256 (at right). [The Alliance AS6C62256 appears to be a second source.] This part features good ESD protection, data retention current of typically 0.1uA, 70ns speed, automatic power-down when deselected, 5V operation, 2V data retention, TTL input levels and it comes in a through-hole package for $3.85 at Mouser. In short, it has everything we want!

Is F-RAM a Solution?
After this article was published, some folks on the cc-tech list suggested that Ferroelectric Nonvolatile RAM might be a better solution than the battery-backed-up CMOS RAM. It appears that suitable parts do exist. At the time of this writing (March, 2014), parts are available on eBay and Octopart. The parts mentioned were FM18L08 and FM1808, formerly made by Ramtron, which was absorbed by Cypress. The pinouts appear to match the CY62256 chosen above but the F-RAM parts will not work with the existing control logic (see “Timing Differences” below). The FM18L08 is a 3-Volt logic part and so isn’t directly applicable here. The FM1808 itself appears to be obsolete but has a drop-in replacement, FM18W08. One problem for this project is that through-hole versions of the parts are harder to find. Our design Goal #3 precludes SMT.

Two issues with F-RAM give me concern: They have a limited number of read/write cycles and a limited data retention time. Depending on the particular part, I’ve seen 10¹² and 10¹⁴ cycles specified. My question was whether this is effectively unlimited life span in a PDP-8. To explore that, let’s round the memory cycle time to 2us. For a machine running continuously at that rate, 10¹⁴ cycles will last about 6-years. 10¹² cycles will last about 23-days. I don’t think I would be happy with the shorter life span. While I wouldn’t consider the longer one virtually unlimited, I have to admit that in vintage computer service, it would be unlikely to be a problem.

As far as data retention is concerned, depending on the part, I have seen figures of 10, 38 and 45-years. The lowest figure seems a bit short but I guess the longer ones shouldn’t be an issue. So it comes down to exactly which parts are available. This of course, changes with time, so info here only applies as I write this. On eBay, I see that FM1808-70-P (through-hole) parts are available for $12-18 (China/HK). Unfortunately, the 1808 is only specified for 10¹² cycles. However, the newer FM18W08 is offered by one seller, Sisitronic (HK), in a through-hole package for $17.50 (at left). That part is specified for 10¹⁴ cycles and 38-year retention. Mouser Electronics also sells the FM18W08-PG through-hole version. So at the moment, it appears that there is a usable F-RAM solution, albeit at about $25 higher total cost, 6-year continuous access lifetime and required changes to the control logic.

Timing Differences
The FM18W08 and the CY62256 used in this project are different animals with respect to timing. As a result, the memory control logic described below is not appropriate for the F-RAM device. While the CY62256 has asynchronous reads, the FM18W08 latches address on the falling (leading) edge of the /CE pin (slash indicates asserted low). That holds true for both read and write cycles. The existing design operates /CE from the EMA address lines, which do not change during the processor cycle. Thus F-RAM addressing would not get updated. Certainly, the logic could be modified to accommodate F-RAM though.

Expected Battery Life

At this point, I could make a guess about battery life: I chose a common 3V Lithium CR2032, which is rated at 180mAh, depending on brand. Allowing 0.2uA for the typical load of two RAM chips and another 0.2uA for the BAT86 Schottky diode, this would work out to 51-years. Of course, battery shelf life would come before that and is said to be 5-10-years. There are two other things to consider: On the positive side, shelf life is typically rated at 20% loss in capacity. Since our load is almost nothing, the data can survive as long as the virtually open-circuit battery terminal voltage is maintained above 2VDC. That would be long after battery capacity is officially exhausted. So, data should be retained long past normal shelf life of the battery. On the negative side, the RAM data retention current is rated at 2VDC and nothing is said about what it is at 3VDC. While I imagine that it doesn’t rise much, we can’t say that for sure. In any case, it could rise by a factor of five and still not challenge the shelf life.

One key point is that the power fail inhibit powers down the chip, well before the 5V power supply goes down. As a result, there should not be any transient load on the battery. Thus, the battery should not see any additional loading. My guess is that 10-year data retention is highly likely; maybe a lot more. Who knows how long an unloaded Lithium-MnO₂ battery can maintain 2V or more across its terminals?

Is Leakage an Issue?
Some might be concerned that the battery might leak electrolyte. Lithium coin cells are far less prone to leaking than the cylindrical dry cells that are notorious for that. No doubt, they could leak if abused but they are routinely designed for ten-year life span. They have had enormous usage in PCs and I’ve never seen a problem with them. Lithium coin cells don’t worry me as much as some other components do. If it’s still a concern, higher reliability models are available (e.g. Panasonic BR2032).

Memory Control Logic

The next step was to work out the logic needed to cause the memory to read and write data at the appropriate times. The basic idea is to mimic what a DEC core memory board does. This required studying the PDP-8/e memory cycle, shown in the thumbnail at right.

Write Timing

There is a complication for the write operations: A core memory must write after every read. That’s because reading destroys the data at the location being read. So after each read, it immediately writes the data back into the location. The complication for our RAM is that we don’t want to do that. Rather, we only want to write when new data is be deposited. When that occurs, write-data comes from the CPU Memory Buffer register, by being gated onto the MD bus. That would generally be when MD-DIR-L is high. To narrow it down, we need to gate it with the WRITE signal. Next, we need to make sure that our RAM will write at the same instant that a core memory would. That is how we can insure that data must be valid. For read or for write, the core is actually activated by the coincidence of the SOURCE and RETURN signals. Since SOURCE is shorter, we can just take that one. So our RAM memory should write when we have MD-DIR-L & WRITE-H & SOURCE-H. This is our WriteEN signal. Referring now to the RAM board schematic represented by the thumbnail at right, you can see that IC7A produces the inversion of this to enable the RAM chips to write.

Read Timing

If the CPU has made MD-DIR-L low, it is okay for memory to read data onto the MD bus. Thus, we use this and the card select signal to enable the bus transceiver to transmit. In general, memory will drive the MD bus, unless the CPU needs to write to memory.

Card Select Logic: Disabling Memory Fields

The PDP-8/e organizes its 32K words of memory into eight, 4K fields. DEC memories for the Omnibus were built in 4K and 8K board sets. I wanted to be able to install any combination of original memory boards and have this new RAM board fill-in the rest of the 32K. Hence, eight dip switches are provided to disable individual 4K fields. IC5 decodes the fields from the Extended Memory Address lines (EMA0, 1, 2), which are really just an extension of the 12-bit MA bus. Fields selected by the switches are summed by IC6 into a Disable signal for the card. (Note that the switch at S1-1 is for Field-0 and the one at S1-8 is for Field-7.) If Disable is low, the card is being addressed by the EMA lines in an enabled field. Disable is gated into ReadEN. It also controls writing by operating the RAM chip enable lines (CE), through Q1, which is normally turned on by the PWROK-H signal.

The PDP-8 family has support for Read-Only-Memory (ROM) which can overlay and preempt portions of RAM. Omnibus signal ROM-ADDR-L goes low when ROM is being addressed and is used to disable RAM cards. That is implemented here by connecting it to the Enable input of IC5.

Power Fail Inhibit Function

It’s vital that a reliable circuit be provided to insure that the RAM is inhibited from writing before power goes down. Else, RAM data could be corrupted, as logic levels in the machine become undefined. To insure this, the RAM chip’s CE line must go high before power fails and remain high. DEC provides the PWROK-H signal from the power supply, which goes low prior to actual loss of DC power. Obviously, it wouldn’t work to use a logic chip powered from the 5V supply, to combine PWROK-H with Disable. However, NPN transistor Q1 does this function very reliably. When PWROK-H goes low, Q1 is turned off, allowing CE to be pulled up by R7, disabling the RAMs.

Capacitor C2 is provided to eliminate any delay between the Disable signal and CE. However, when PWROK-H goes low, C2 will delay CE going high. That’s okay though, because the delay is only 30us or so and PWROK-H gives many milliseconds of advance warning of power failure. We have chosen the high 100K value of base resistor R6, to keep PWROK-H bus loading low, per Omnibus specs.

Backup Battery Circuit

The RAM chips and CE pullup resistor are powered from the +5V supply, combined with +3V from the CR2032 Lithium battery. Two BAT86 Schottky diodes provide the summation. The diode is chosen to support 25mA or so worst case power consumption and yet keep leakage down to the 0.4uA range in backup power mode. A 22uF ceramic bypass capacitor keeps AC impedance minimal for the RAMs, while not adding appreciably to the backup power leakage, as an aluminum electrolytic would. The availability of such large value, inexpensive, thin-layer monolithic ceramic caps in recent years has materially improved the performance and reliability of sensitive circuits, which need a large cap, yet cannot tolerate much leakage. In contrast, bypass cap C10 for the main card power can be an ordinary, low-ESR aluminum electrolytic.

Possible Changes

• Octal inverter/buffer IC8 (74ABT540) could be replaced by a more common hex inverter, such as a 74ACT04. The octal part was specified before the control logic was simplified and before we realized that 74ACT logic had sufficient ESD protection. Hence, IC7 pins 2, 4 and 5 can go directly to the Omnibus connections, instead of being buffered by pairs of inverters. The inverters which remain would be IC8A and IC8G.
• FYI, IC7 was specified as a dual 4-input NAND before the logic was simplified. As you can see, a triple 3-input NAND will work as well, leaving a spare gate. Unfortunately, the spare can’t really help, since two inverters are needed and the spare could only replace one of them.

Building the Project

While it’s probably not for beginners, I would say that this project is not difficult. There are a lot of fine wires to cut, strip and solder but that just takes patience and decent soldering skills. I’m slow at it and I guess it took me a few days of work to solder all the connections. I recommend that you print a copy of the schematic and the top and bottom pictures, to work from.

Ordering the Parts

The project is built on a prototyping board available from Douglas Electronics. This is a small, hobbyist-friendly company, so don’t worry about calling them to place an order. (They also have on online order form.) Important note: There is a critical change which you must make to the Douglas 12-DE-8 prototyping board: The trace on the top side indicated in the photo below left must be cut. Otherwise, it shorts the +15V Omnibus line at DA2 to the +5V Vcc Bus on the card. This is board tab-D.

I also needed to do a bit of filing on the card tabs for a better fit to the Omnibus slots. I narrowed the width of the tab and also rounded the corners which enter the Omnibus slot, as seen in the photo.

Click on the thumbnail at right for a PDF-format parts list, from which you can order the rest of the kit. The Excel-format file of the parts list is here. Links to other vendors: Mouser Electronics     Jameco

Wiring Technique

I secured the longer runs to the board using small amounts of super-glue (cyanoacrylate). My technique is to dab a little on a 1” (or less) length and then hold it down for 60-seconds. I use the waxed paper backing from pressure-sensitive labels to protect my fingers from being glued down. With your fingers on it, it’s fairly easy to keep multiple wires in a run, lined-up, together and flat on the board. To secure a very long run, you can secure one end and then the other, while pulling the wire tight. Then you can secure points in between, if needed. As you can see at right, the glue almost disappears and results in neat wiring.

Laying Out the Sockets

You can place the sockets and dip switch, using the high-resolution photo linked from the thumbnail at left. Those can be secured by bending corner pins slightly away from center. Mounting the battery at the top edge of the board, gives you a shot at being able to change it with the power on to avoid data loss. I rotated the battery holder until it’s pins aligned with a hole from the top row of the ground bus and a hole in the upper corner dip pattern, then soldered. The terminal making contact to the edge of the battery is positive. Note that the Q1 transistor shown in the photo is not the 2N3904, currently specified. The old one has a different package and pinout. The correct package and pinout is shown at right.

Wiring the Bottom Side

A high resolution photo of the bottom is linked at left. You can use that as a guide to the wiring. I made the IC pin labels shown there and they proved to be very helpful. Click here for a PDF file which you can print to make the IC labels. I credit those and the partial labeling of the edge connector pins with the fact that the card worked the first time it was accessed. That was a big relief because, as mentioned above, the rest of the computer had problems and I really needed to start with a good memory board.

About the Omnibus Pin Designations

Each slot of the Omnibus has four edge connectors, which mate with the four edge tabs of a card. Pin assignments are illustrated below. The connectors are designated A, B, C and D, from right to left, as seen from the component (top) side of the card. The 18-positions of each of the four edge connectors are labeled from A to V, skipping G, I, O, Q. These are also in right to left order, as seen from the top of the board. It was done this way as a measure to confuse the competition and to prevent customers from hacking. (Just kidding :) To paraphrase the old Army quip, “There’s a right way, a wrong way and the DEC way.” <har>

I also need to mention that at each edge connector position, the contact on the component (top) side of the board is designated #1 and the contact on the solder (bottom) side of the board is #2. On the RAM Board schematic, I have labeled Omnibus connections using the standard DEC format of XYN, where X is the connector letter (A-D), Y is the position letter (A-V) and N is the board side (1-2). So the top side contact on the far right end of the edge connector is AA1. The bottom side contact on the far left end of the edge connector is DV2.

Operating and Testing the Completed RAM Board

Setup

Insert the CR2032 coin cell in the battery holder, positive side up. You can check the voltage across diode D1, to verify low current drain. I saw about 27mV across it, with a 10Mohm meter. From testing a BAT86 diode in the lab, that indicates about 0.36uA of current drain, which is remarkably close to the 0.4uA drain estimated above. One would only be concerned if it were above say, 2uA.

Set all dip switches to off, unless you have other memory boards in the system. If you do have other boards, turn on one switch for each 4K field that you want to disable. The switch at the Pin-1 end of the switch is for field-0, the lowest part of memory. So if you have one 8K core memory board, turn on the switches at Pin-1 and Pin-2.

Installation

It doesn’t matter which slot of the Omnibus you choose for this card. I like to keep it close to the CPU, though. The computer should be turned off for installation. While touching the ground bus on the bottom side of the board, touch a ground terminal on the computer to discharge static electricity. Then insert the board in an Omnibus slot, with the components facing the front panel of the machine. Since the Douglas prototyping board material is a bit thicker than most DEC boards, you might find the insertion a little stiff. One good thing about this is that the board is held securely vertical and does not wobble as other boards do. Also, the board is not quite as high as DEC boards.

A real test requires running a memory diagnostic or a large program but of course, most of us would be tempted to deposit a few values into various locations examine them. If you won’t be running a diagnostic, it’s a good idea to at least check locations in each field, since most DEC software would rarely access memory in those dizzyingly high addresses, like field-7. Address 77777₈ — man, to many PDP-8 owners back in the day, that was practically infinity!

Results

My RAM board has been running for about sixteen months now and I’ve been very pleased with its performance. Works great with the data break interface of the RK8E disk controller. I have to admit that it took me quite a while, before I really trusted that the code would still be good when I would power it up after an extended rest. But I’ve never had a data loss that I couldn’t explain by a program that went wild or something, so I’ve come to really treat it like core.

Similarly, the system as a whole has been running OS/8 and applications very solidly and hasn’t given me any cause to suspect flaky RAM operation. Initially, I ran it along with an 8K core board set. However, one of the bits of the core data words has become stuck, so the computer has been running on just the RAM board for most of the time. Fixing the core memory is awaiting its turn in the priority queue.

I’m always interested in any comments and will be happy to answer any questions that you might have. Happy vintage computing :)

News of a Similar Project

After publishing this article, reader Lou-N2MIY on the Vintage Computer DEC forum was kind enough to let me know about a project which is remarkably similar to this one. It was designed in 2006 by Charles Dickman and you can read about it here. (Scroll down to the “Hardware Projects” heading.) It is based on a 62256 RAM chip, which I presume is the same as the CY62256 used in my design. That gives me a good feeling about the popularity of the chip.  Lou built the excellent implementation shown at right and also provided schematic markups shown on Charles’ site. You can see more pictures of Lou’s project, as well as his PDP-8/a, here.

References

1. Digital Equipment Corporation. (1973). PDP8/e PDP8/m & PDP8/f Small Computer Handbook. Maynard, MA.
2. Digital Equipment Corporation. (1970). PDP11 Unibus Interface Manual. Maynard, MA.
3. Digital Equipment Corporation. (1973). Logic Handbook 1973-74. Maynard, MA.
4. Digital Equipment Corporation. (1979). PDP11 Unibus Design Description. Maynard, MA.

Copyright © 2013-2014 by Stephen H. Lafferty. All rights reserved.

Reader Comments

Add your comments here...

_