Okay, so the Apple II Plus I was using to test the VM4209 monitor worked fine for about a half hour, then smoked a RIFA cap in its power supply. These are a very common known failure in various old microcomputer power supplies, and I really should have already caught this on inspection and shotgunned it. Boy, do they generate a lot of smoke and stink when they go...

Electrolytics in here are also all pushing 40 years at this point and Astec opted for only 85C parts for many of these, so I went ahead and ordered a whole replacement kit from Console5. I replaced the front end filters and anything on the back end that was 85C or looked even slightly bulgy, which ended up being most of them:

Put it all back together and back in business, except noticed an additional problem: DOS 3.3 booted but neither recognized nor loaded the "language card" (soft ROM) present in the machine. Since my machine has Applesoft BASIC in system ROM, this meant no Integer BASIC (and no ROM mini-assembler) for me until this was fixed.

For those who might not be familiar with the Apple II language card, it provides several features. An Apple II or II Plus can have at most 48K of RAM on the system board. The overall memory map looks like this:

 $0000-$BFFF RAM (48K) $C000-$CFFF IO space (4K) $D000-$FFFF ROM (12K)

The first thing the language card provides is a 2K ROM which by default overlays whatever ROM is in the system board socket for addresses $F800 to$FFFF. This ROM holds the 6502 reset vector and the boot monitor; the version provided on the language card has an "autostart" capability that will search for and boot off an attached Disk II floppy. I am not sure why Apple provided this ROM on the language card since the same ROM could be upgraded directly on the fully-socketed system board, and indeed everything after the Apple II Plus came with this autostart ROM pre-installed. Possibly this was done for maximum backward compatibility with Apple's previously-offered "Firmware Card", which also contained this ROM? Third-parties would later offer clones of the language card that did not contain the additional/redundant F8 ROM, and nobody seems to have particularly cared or noticed...

The second thing the language card provides is an additional 16K of RAM. This can be loaded, then write-protected and mapped over the entire ROM space of the machine from $D000 to$FFFF, providing a "soft ROM" capability. Since the available ROM address space is only 12K, the leftover 4K or RAM on the language card is bank switchable at address range $D000 to$DFFF.

Advanced software which doesn't depend on the system ROMs at all can also map the RAM over the system ROM address space and leave it in read/write mode, thus gaining access to a full 64K of RAM (with the caveat of the switched bank at $D000.) The language card programming interface presents as follows: My goal is to be able to run the initial (1980) release of Apple DOS 3.3. This version loads up the language card at boot in soft ROM mode with Integer BASIC and an older version of the F8 monitor ROM, which contains a few extra niceties like a built in mini-assembler and primitive step/trace capabilities. A system so loaded can then be conveniently switched back and forth between BASIC and monitor versions with the DOS "INT" and "FP" commands. But detection of my language card seemed to be failing, so it was never loaded up at boot. Attempts to manually load and activate it also came to naught. So, time to dig in and see what's going wrong... DOS 3.3 does initial checks and setup of the language card via a small machine language program, loaded into RAM at boot by the DOS master disk's HELLO BASIC program. Machine code is used for this part rather than BASIC so the probe/setup code can be placed and run from RAM outside the mapping range of the language card (the BASIC interpreter itself running from ROM addresses within this mapping range). Here is the machine language program, after being POKEd into RAM by HELLO, listed via the ROM monitor: I interpret the actions of this code as follows: • The code first retrieves and stashes the contents of location$E000, within the mappable address range. A read of $C081 then maps the ROMs on the system board (see programming interface above), and the contents of$E000 are checked again. If the contents now differ, the code assumes the card, now in mapped ROM mode, was previously in mapped RAM mode, and it jumps to address $0332 to put things back the way it found them and bail out. • If not, the code reads from address$C083 twice, which puts the card, if present, in writable mapped RAM mode. Two different values are written to and compared back from location $D000. If a language card is not present, this location will still be mapped to ROM on the system board, and at least one of these compares will fail; if either one does, the code jumps to$0332 to bail out.

• Otherwise, we've verified that a card is present and wasn't already in active play. The program now reads from address $C081 twice to move back to mapped ROM mode, but leaving RAM writable to be loaded by the remainder of the HELLO program after return (in this mode, reads will come from system ROMs, but writes will go to the corresponding locations in language card RAM). A success return code is loaded, and the code jumps forward to the exit code at$0334 to return to the caller.

• The bail out routine at $0332 just sets up a fail return code, then falls through to$0334. Code here stores the return code to the return code location and does one last compare between the stashed and current values at $E000 to determine if mapped RAM mode must be restored; if so this is done via a read from location$C080 (RAM is left write-protected). Control is then returned to BASIC.

In any case, the above is what the code does, even if I may have misinterpreted some of its motivations. On my system, the ROM on the language card seemed to be working correctly (monitor ran fine, but if ROM on language card was pulled the machine failed to boot, indicating the monitor was in fact running successfully out of ROM on the card). However, mapped RAM mode seemed never to engage. The machine code snippet above returned "00" without crashing, and the DOS HELLO program assumed no card present. Manually accessing the appropriate control registers also had no effect.

The language card design does not seem to be documented in detail, but a schematic is available and it is not too hard to suss out. The first thing to check would seem to be the register interface. Here is an excerpt from the schematic, with a couple of annotations added:

The register interface is principally implemented by a 74LS175 quad flip-flop at D4. These flip-flops share a common reset at power-on, and a common clock based on the expansion slot DEV_L signal; DEV_L is a slot-specific signal strobed by the system on any bus cycles to IO address space allocated to that slot. Examination of the programming interface along with address line decodes feeding the D inputs here leads to the conclusion that the top-most flip-flop holds RAM/ROM mapping mode, the next one down is RAM bank select, the next is RAM write-enable, and the last is a one-bit count to support write-enable after only two successive reads.

Put a chipclip on at D4, and observed behavior of the flip-flops on the logic analyzer while exercising the control registers via the monitor. Problems were apparent right away: while the bank select and count flip-flops were responding as expected, the mapping mode and wite-enable flip-flops were not. The shared reset and clock appeared correct, and all flip-flops themselves were responding logically correctly with respect to their inputs. The issue was apparently with the incoming D lines to two of the flip-flops. Starting with the ROM/RAM enable flip-flop, then, that D line is fed via C3 and C4. And a visual inspection in preparation for clipping these up for the analyzer revealed that, surprisingly, these two chips had actually been reversed on the board!

The language card is fully socketed, so presumeably this reversal had occured during previous troubleshooting or service by the former owner? In any case, it was easy to swap the chips back to their correct locations, and the logic analyzer showed that the entire register interface seemed to be behaving according to design after that. DOS 3.3 now recognized the card at boot (yay!), but the system would crash after loading and mapping the RAM. So, maybe a bad RAM chip as well?

To troubleshoot the RAM, I followed a technique described in this video on the "Adrian's Digital Basement" YouTube channel. Basically, a couple short machine language programs, entered and executed via the monitor, to copy ROM contents into the language card RAM, then copy back out to another location in system RAM. This allows a comparison of source data in ROM and round-tripped data in system RAM; a mismatch indicates a RAM problem on the card. Here are the two programs I used and, and dumps of the resulting data:

And sure enough, it's quite visible here that bit 7 is having problems. Swapped out the 4116 at A2, and that seems to have done it for this one. Now I need to go find a copy of Choplifter...

Some time back I purchased a Sanyo VM4209 B&W video monitor on eBay. Sold as working, it arrived with apparently working horizontal but no vertical deflection. The price had been right, however, so it was just shelved into the repair queue.

I now have a few DEC VT series terminals to work on and would like to have a small video monitor available on the bench for this, so I pulled down the VM4209 to give it a look. Given the lack of vertical deflection, the first thing to check would be the vertical deflection power transistors, Q105 and Q106 here:

It turns out these transistors are quite well buried in the guts of the monitor on a small aluminum heat sink. Took a while to work my way in to them, and required unsoldering a few leads and removing the CRT:

Sure enough, the lead connecting Q106 collector to ground had been broken, and the part tested bad. Q105 appeared healthy, and there were no other apparent signs of distress in the surrounding circuitry. Q106 is an out of production 2SB474 germanium PNP in the less common TO66 package; I opted to replace it with the "modern" equivalent NTE226. Re-assembled, and was greeted immediately with a functioning raster. Pulled out an Apple II Plus to test with:

This was quite fun for a short while, until a RIFA cap in the Apple II power supply let go, filling the dining room with acrid smoke. So, expect an additional article on that one in the near future :-)

I figured it might be fun to play around a little bit with BASIC-11 under RT11 on the newly-restored PDP-11/34. If I got that working, it could also be included on the RK05 RT11 disk image that I use regularly for demos on the larger PDP-11/45.

The first thing to do was to find a compatible disk image and get it running under simh. Bitsavers had BASIC-11_V2.1_RX02.DSK.zip, which would seem to fit the bill, but the contained image would not mount successfully on simh's RY device. Looking through a dump of the image, there was an apparent "RT11A" signature, so that looked promising. Tried putr under dosbox as well, but it would hang mounting the image. So, off to the cctalk mailing list for some advice...

Glen Slick on the list first noticed a file size discrepancy:

That BASIC.DSK image file has a size of 486,400 bytes. I don't know where that size would come from.

A physical RX-02 floppy should have a sector size of 256 bytes, with 26 sectors per track, and 77 tracks, which would be a total of 512,512 bytes, or 505,856 bytes if the first physical track is ignored.

Indeed, the other RX-02 floppy images available here do have a size of 505,856 bytes: http://www.bitsavers.org/bits/DEC/pdp11/floppyimages/rx02/

Hmm, maybe that BASIC.DSK image file was created by something that only copied the initial allocated logical sectors and ignored unused logical sectors at the end of the floppy, and maybe PUTR doesn't handle disk image files that are not the expected full size?

Example of padding the 486,400 byte BASIC.DSK image file to a size of 512,512 bytes on a Windows system:

FSUTIL FILE CREATENEW BLANK 26112
COPY /B BASIC.DSK+BLANK TEST.DSK

C:\PUTR>DIR TEST.DSK
Volume in drive C has no label.
Volume Serial Number is 14CE-1A29
Directory of C:\PUTR
08/11/2021  12:55p             512,512 TEST.DSK

C:\PUTR>PUTR
PUTR V2.01  Copyright (C) 1995-2001 by John Wilson <wilson@dbit.com>.

COPY mode is ASCII, SET COPY BINARY to change
(C:\PUTR)>MOUNT RX: TEST.DSK /RX02 /RT11 /RONLY
(C:\PUTR)>DIR RX:

Volume in drive RX is RT11A
Directory of RX:\*.*

11-Aug-2021
BSOT0D.EAE    12  04-Apr-1983
BSOT0S.EAE    10  04-Apr-1983
BSOT1D.EAE     9  04-Apr-1983
BSOT1S.EAE     6  04-Apr-1983
BSOT0D.EIS    12  04-Apr-1983
...

...etc. Nice. Still no luck mounting under simh, though. Glen further offers:

As far as I can tell by default PUTR expects to work with logical sector order RX-02 disk images that are 512,512 bytes in size. The BASIC-11 RX-02 disk image available here is in logical sector order, but is less than 512,512 bytes in size: http://www.bitsavers.org/bits/DEC/pdp11/floppyimages/rx02/ PUTR appears to be unhappy with the disk image unless it is padded to 512,512 bytes in size.

On the other hand as far as I can tell by default SIMH expects to work with physical sector order RX-02 disk images. If I mount the logical sector order RX-02 disk image that works with PUTR in SIMH, then RT-11 gives a "?DIR-F-Invalid directory" error. If I translate the logical sector order RX-02 disk image back into a physical sector order disk image (dealing with track shifting, sector interleaving, and track to track sector skewing) then RT-11 on SIMH is happy with the disk image.

and:

One bit of information that I found helpful as a reference when I looked at this quite a while ago was the 2.11BSD RX02 floppy disk device driver source code, which can be viewed online here:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdpuba/rx.c

In particular, the routine rxfactr(), which as the comment says it calculates the physical sector and physical track on the disk for a given logical sector.

I used that as a starting point to write a simple utility to read an RX-02 disk image file in logical sector order and output an RX-02 disk image file in physical sector order.

/*
*  rxfactr -- calculates the physical sector and physical
*  track on the disk for a given logical sector.
*  call:
*      rxfactr(logical_sector,&p_sector,&p_track);
*  the logical sector number (0 - 2001) is converted
*  to a physical sector number (1 - 26) and a physical
*  track number (0 - 76).
*  the logical sectors specify physical sectors that
*  are interleaved with a factor of 2. thus the sectors
*  are read in the following order for increasing
*  logical sector numbers (1,3, ... 23,25,2,4, ... 24,26)
*  There is also a 6 sector slew between tracks.
*  Logical sectors start at track 1, sector 1; go to
*  track 76 and then to track 0.  Thus, for example, unix block number
*  498 starts at track 0, sector 25 and runs thru track 0, sector 2
*  (or 6 depending on density).
*/
static
rxfactr(sectr, psectr, ptrck)
register int sectr;
int *psectr, *ptrck;
{
register int p1, p2;

p1 = sectr / 26;
p2 = sectr % 26;
/* 2 to 1 interleave */
p2 = (2 * p2 + (p2 >= 13 ?  1 : 0)) % 26;
/* 6 sector per track slew */
*psectr = 1 + (p2 + 6 * p1) % 26;
if (++p1 >= 77)
p1 = 0;
*ptrck = p1;
}

An RX02 image shuffled into physical sector order generated by Glen and suitable for use with simh is attached here.

Jerry Weiss further suggested that the original, logically ordered image may work as is under simh if attached as an MSCP device rather than RX02. This turns out also to be the case:

On Fri, Aug 13, 2021 at 9:46 AM Jerry Weiss wrote:
Could you attach logical sector (block?) image as MSCP disk in SIMH? Other than some minor image manipulation for removing track 0 if present, is there any reason this would not be readable?

Hmm, it didn't occur to me to try that. Mounting the logical sector order RX-02 disk image, without any modification necessary, as a raw MSCP disk does indeed appear to work!

sim> ATTACH RQ1 BASIC.DSK
RQ1: 'BASIC.DSK' Contains RT11 partitions
1 valid partition, Type: V05, Sectors On Disk: 950

sim> SHOW RQ1
RQ1     486KB, attached to BASIC.DSK, write locked
RD54, UNIT=1, autosize
RAW format

.DIR DU1:

BSOT0D.EAE    12  04-Apr-83      BSOT0S.EAE    10  04-Apr-83
BSOT1D.EAE     9  04-Apr-83      BSOT1S.EAE     6  04-Apr-83
BSOT0D.EIS    12  04-Apr-83      BSOT0S.EIS     9  04-Apr-83
BSOT1D.EIS     9  04-Apr-83      BSOT1S.EIS     6  04-Apr-83
BSOT0S.FIS     7  04-Apr-83      BSOT1S.FIS     6  04-Apr-83
...

...etc. Armed with the above, I was able to get BASIC-11 into an RT11 image in the Unibone card, and running on the new PDP-11/34. Here's output from the DEC BASIC mandelbrot program at rosetta code:

I have been keeping an eye on Jörg Hoppe's interesting Unibone project for some time -- it is a general-purpose Unibus device emulator and diagnostic tool, built around a BeagleBone Black compute module running embedded real-time Linux. The PDP-11/34 restoration project finally provided enough impetus for me to pull the trigger on getting one.

Sent Jörg an email to order a kit, which arrived some weeks later complete with bundled BeagleBone. The kit is pretty well thought-out and was enjoyable to put together. Had to throw in a few of my own pin headers and jumpers to complete the assembly. The only other small confusions were a few of the resistor packs which did not match the schematic (Jörg informed me these are non-critical values.)

The kit did not include card handles. I decided to try having some 3D printed by Shapeways, using their "processed versatile plastic" process, which is a laser sintered nylon, color dyed and smoothed. I used a card handle model by Vince Slyngstad found here. The results were nice, sturdy, and dimensionally correct. The chosen "purple" color is a rather intense magenta in real life. Not exactly cheap for just a couple parts, but I had been wanting to try their print service.

The Unibone has all sorts of capabilities, and proved itself very useful during the '11/34 restoration:

• Ability to bus master to probe the Unibus address space and run diagnostics on memory found there. This was very useful for debugging the memory card that came with the -11/34 and sussing out its undocumented configuration switch settings.

• Ability to directly load and execute MAINDEC diagnostics, without needing a functioning console emulator or storage subsystem. This is a convenient and speedier alternative to PDP11GUI.

• Subsequently, the ability to emulate entire storage subsystems, very useful for loading and running full operating systems on this -11/34 which otherwise has no storage of its own.

The Unibone goes in a quad SPC slot; I opted for slot 9 on the -11/34, and this entailed removing the NPG jumper on the backplane there to allow the Unibone to bus master. The device worked well straight-away after assembly.

There are, alas, a couple small frustrations with the current design:

• It is desireable to configure the Unibone and backplane to allow the Unibone to bus master and interrupt. However, this leaves grant chain(s) open at boot until the Unibone's own embedded software can boot and take control of the card (which takes on the order of a minute or so). During this time the host system is non-functional or may hang, and it needs to be subsequently reset (this reset can be scripted from the Unibone, but all of this does significantly increase end-to-end boot time of the machine). It would be nice if the Unibone had something like some normally-closed relays on the grant chains, to preserve grant continuity until control is actively assumed.

• It would be desireable to be able to power the embedded BeagleBone in isolation, in place in a system, without having to having to have the entire host system powered at the same time (e.g. for maintenance of the Unibone's embedded software stack, maintenance of locally stored storage system media images, etc.) There is a relay on the Unibone which switches in Unibus power when available, but unfortunately, the design is such that if the BeagleBone is also externally powered the relay remains engaged when the host system is shut down. This could lead to the BeagleBone trying to power then entire Unibus via its 5V supply/connector, which could obviously be problematic... For now it seems best just to pull the card in order to run it in isolation, which is a little less than convenient.

That said, the designs and software are open source, and the card comes with some generous prototyping areas built right in, so some mods to address these issues could be a fun project. All in all, Jörg has put together a fantasically useful bit of kit, and I'm certainly glad to have it in my toolbox!

This spring I worked on repair/restoration of a friend's PDP-11/34. The system was in fairly good shape, but missing a few bits and pieces and with the usual sorts of issues for 45-year-old kit. Started per usual with disassembly, cleaning, and inspection. The BA11-K chassis was in pretty decent shape; just a few scratches requiring some sanding and a little touch-up paint to inhibit future corrosion.

Date codes on the chassis and CPU cards are from 1976, but other components in the chassis are a bit of mix-and-match (a KY11-LB console interface and a third-party Monolithic systems memory board date from 1981, and a DL11-W SLU/RTC card is from 1977). Serial number is 2001. There is also a sticker for "OHIO NUCLEAR", which was an early manufacturer of CT devices.

Foam problems here were limited to a decayed air pre-filter at the front of the chassis and some padding on the cable retaining bar at the rear. A heat gun and a paint scraper are your friend for removing the leftover cellophane adhesive strips that were used to secure the foam. For the replacement pre-filter, I opted for 3M Filtrete carbon pre-filter sheet (part ‎FAPF-UCTF2PAMZ) which comes in sheets large enough to cover the front of the chassis and is easily cut to size with scissors.

The front panel brackets ended up being a bit of a puzzle to reassemble -- I unfortunately failed to pay close attention to how exactly the lower fasteners were configured during disassembly. Most of the wisdom out in the restoration community seems to pertain to a newer, and much more convenient, version of these brackets (or the ones that arrived on this system were mismatched?) Here's a picture of the brackets that I have, and a shot of the arrangement I finally opted for for the flange-blinded mounting hole at the bottom of the chassis: machine screws driven from the back of the bracket with Keps nuts toward the front. I also added some 1/8" nylon spacers so the pre-filter could be extended across the entire front of the chassis, behind the brackets, and everything still remains square when tightened up. A serviceable replacement power knob was tracked down here.

The BA11-K chassis has an integrated H765 power supply. The power-controller unit was in pretty good shape, but I replaced the line cord since the old one had some fairly serious nicks in its outer jacket. Also replaced cap C1 (50uF) which seemed to be drifting off value. Replaced the .1uF across-the-line caps mounted on the power transformer with modern X2 safety caps. The DC regulator modules (2x H744 +5V and 1x H745 -15V) were disassembled and cleaned. Reformed all the large electrolytics, then load tested the reassembled regulators individually. Nothing out of sorts here except the usual replacement of burnt out incandescent indicator bulbs.

I filled out the system with a near-side M9301 bootstrap-terminator (recent eBay purchase), some G727 "knuckle buster" grant continuity cards, and an M9302 SACK turnaround far-side terminator. New on this restoration was a UniBone Linux-to-Unibus bridge, used to emulate storage devices among other things (more on this in a separate article soon). Checked/adjusted NPR continuity on the backplane (continuity wire wraps in place for all slots except slot 9, to accommodate the UniBone). Module utilization as follows:

A B C M7266 CPU control M7265 CPU data path M9301 boot term M7859 console Monolithic Systems 303-0158 64 KiB memory M7856 serial / line clock G727 G727 G727 M9302 SACK term UniBone

Connected up a VT100 to the serial card, and fired things up. Good signs of life from the front panel, but the machine immediately halted without producing a boot monitor prompt. Was able to reset the machine from the front panel, though, and then examine and deposit various memory locations from there.

Boot ROM memory locations were readable, and the contents looked correct. RAM addresses were generally readable and writable, but bit 10 appeared incorrect (sometimes always set; sometimes always clear). I was also able to successfully write to the console XBUF register from the front panel and see characters appear on the VT100.

A bus init from the front panel followed by manually punching in the boot ROM entry point produced a functional ROM monitor on the VT100. Deposits and examines to RAM done from the boot monitor produced results identical to those seen using the front panel (same bit 10 problem).

One of the cool features of the KY11-LB console is a maintenance mode that can run Unibus bus cycles on its own without a CPU. This gives a way to do limited testing of cards in isolation: just set up the M7859 on a powered, terminated backplane segment and plug in cards to be tested one at a time. Deposits and examines can then be done using the buttons and display on the front panel.

Interestingly, when running this way with just the console and memory cards in place the bit 10 errors were no longer apparent. Some other card was apparently corrupting bit 10 on the bus; by checking one at a time the problem was quickly isolated to the M9301 boot terminator card.

The M9301 drives the implicated bit onto the Unibus via an 8881 bus driver at position E9, as seen below. The signal coming in from the bottom here is ENAB DATA H, which is meant to enable these drivers only when the M9301 detects a valid address decode. Verified that data was being incorrectly driven on BUS D10 L at E9 pin 13, regardless of the state of pin 12, indicating a faulty driver. Pulled this, socketed, and replaced (with a compatible ECG 7439), and the bit 10 problem was fixed.

There was still some problem with auto-boot to the M9301 monitor, however; the monitor prompt would now begin to print at power up, but the machine would halt a few characters in. The front panel bus init plus manual jump to monitor entry point workaround was still working though, so put off further investigation of this issue until later.

At this point, given the workaround, the system was working well enough to begin loading and running MAINDEC diagnostics over the serial line with PDP11GUI. Relevant diagnostics, from the PDP-11/34 System User's Manual:

DFKAA, DFKAB, and DKFAC all ran without issue. DFKTG, DZKMA, and DZQMC all reported various errors, so time to look into the memory board.

The board is a Monolithic Systems 303-0158:

I could not find any information on the board on the internet, but much can be figured out by inspection and testing. First, the board is using 4116 (16Kx1) DRAMs, pretty usual for the era. There is space for 4 banks of 18; each bank would be 16K words (16 data bits plus two parity bits per word.) Here we see two banks populated, minus one of the parity chips. So we'd expect to see 32K words (64 KiB) mappable (or 28K words [56 KiB] with address translation disabled, to accommodate the 4K word [8 KiB] I/O page.) The missing parity chip is unlikely to cause any trouble in this application; in an '11/34, there is no memory parity support without the optional M7850 parity board installed, and this system does not have one.

One of the capabilities of the Unibone is to probe the full 18-bit Unibus address space, looking for active pages. These tests indicated that the memory board as configured was responding to the lower 128 KiB of addresses, even though only 64 KiB was populated. One would suppose that the mapped address range was configured via the DIP switches on the board. Some experimentation with various switch settings yielded the following:

SW1: Memory start addr, 000000 + values as follows
76543
0....400000
.0...200000
..0..100000
...0.040000
....0020000
SW2: Memory size, 020000 + values as follows
4321
0...200000
.0..100000
..0.040000
...0020000

After setting the switches appropriately for the amount of memory physically present, memory test errors went away and the MAINDEC memory diagnostics (excepting parity tests) also ran successfully.

So the Last thing to fix was the problem with the boot monitor at startup. For this, the boot ROM card went back out on an extender so I could get at it with a logic analyzer.

A PDP-11 generates power down and power up traps, through location 024, based on transitions of the AC LO and DC LO Unibus signals. In handling this trap, the processor first reads the PC from location 024, then the PSW from location 026. Many PDP-11s had core memory or battery-backed RAM; this allowed for orderly recovery from power failure events.

PDP-11 boot ROM cards like the M9301 or its younger cousin the M9312 use a hack to obtain control at boot. They monitor AC LO and DC LO, and when detecting a boot condition they jam higher order address bits on the Unibus for a the first couple bus cycles. This causes the PC and PSW to be fetched from locations within the address space of the boot ROM card. Here is most of the circuitry responsible for this:

The bus drivers that jam the address bus are seen on the right. The central player here is E21, a 9602 one-shot. CLEAR ADDR L is supposed to arrive after the first two bus cycles (fetch of PC and PSW) and release the bus; the one-shot is set up to timeout after about 300ms and release the bus in any case.

On the logic analyzer, we can see an issue here:

MSYN delimits bus cycles mastered by the CPU. Here we can see that CLEAR ADDR L never arrives, and so the higher-order address bits remained jammed by the M9301 for the full duration of the one-shot timeout. This is okay for the first few instructions, which are executing out of the ROM anyway, but things quickly go awry...

Here is the circuitry responsible for CLEAR ADDR L:

The desired pulse is mediated by 270 uF capacitor C36 in one leg of gate E20, so this is a good thing to check first, and... it is actually missing from the board! (Visible in the M9301 gallery picture above.) Replaced this cap, and now we are in good shape:

With this, the machine is fully repaired. Spent a little time with it, booting and running various operating systems from emulated storage on the Unibone card. Frieda also approves:

Some friends of mine own vintage arcade games. Two of them had Atari Tempest machines (one a full-size upright, one the rather more rare "cabaret") that had ceased to play, so I offered to look at them both if they could be dropped off here at my home. Some time later, and here they are in the garage (the Space Duel upright in the background is my own):

Overall, these are not too complicated, and pretty easy to work on:

• There is a straightforward linear supply in the bottom of the cabinet, known as the "brick", which provides +10.6 VDC and 50, 36, and 6 VAC.

• A separate card, the "AR2" (downstream of the brick, also linear), derives +12, +/-5, and +/-22 VDC, as well as hosting audio power amplifiers for game sound.

• The "brains" of the game are a control board with a 1.5 MHz 6502A processor, ROMs, RAM, and GPIO for settings DIP switches, coin door etc. Since Tempest is a vector game, a fair bit of the control board is also dedicated to vector generation; Tempest uses an "analog vector generator" where vectors are swept by analog integrators with rate inputs fed by DACs. The control board has a daughter-card which has 4x AMD2901 bit-slice ALUs to assist the 6502 with math, and a couple of custom Atari chips ("POKEYs") for sound sound generation and game control input.

• Last, there is a color vector CRT, the WG6100. This has X and Y deflection amplifiers similar to an oscilloscope, and accepts RGB inputs for color/intensity.

These games are quite common, so all of these components have well-understood failure modes; you will find these discussed in various arcade repair online forums and FAQs. The stuff I always look for:

• Brick: There is a large electrolytic, known as "big blue", which is the primary filter for the +10.6 VDC. If it is still the '80s original, it is probably worth a check. Modern drop-in replacements are available for ~\$15 USD.

There is also a fuse block wired in with crimp quick-disconnects. They are problematic because they may oxidize or rattle loose, causing increased resistance and eventually thermal runaway as the currents here are in the multi-amp range and the brick is located at the bottom of the cabinet where air circulation is not great. It is not uncommon to find toasty wiring and/or melted plastic fuse blocks; if doing repairs in this area I'll generally just clip off the quick disconnect connectors entirely and solder the wires down directly to the fuse block tabs to avoid future reliability issues.

• AR2: Common fails here are also generally thermal issues. Recap kits for these boards are available from the arcade parts houses, but in my experience aren't often required. Each of the supplies on the AR2 is pretty easy to bench test, but make sure you test with at least a minimal load in place as some of the linear regulators here will behave unpredictably when unloaded. I've never personally seen a failure of the integrated audio amplifiers on the AR2, so I generally don't bother to test them up front; if I have an audio problem with the game I will come back and give them a look later.

The +5 VDC supply here works with a remote sense, which is a matter of some controversy. There can be an appreciable (and variable between cabinets) voltage drop from the AR2 to the game boards over the molex connectors, wiring harness, and game board edge connectors in between. Atari seems to have gone for a remote sense design to automatically compensate for this. The problem is that it is not uncommon for the board edge connectors to loosen over time and/or accumulate dust and oxidation, increasing resistance, and leading to another thermal runaway situation as the supply keeps upping the juice to overcome ever-increasing resistive drop. It is not uncommon to see toasted wiring, toasted AR2, and/or even burnt board traces.

Some techs advocate short circuiting the remote sense at the AR2 (known as the "sense mod") with the argument that it is less destructive to fail into a game-board-under-voltage condition than to fail into an over-current-until-something-burns situation. Others insist the original design is fine as long as board and harness connections are well maintained. I tend to leave things stock unless there is evidence of a problem. If a particular cabinet looks like a chronic +5 burner, though, I'll go ahead and implement the sense mod as well as repairing/replacing the board edge connector; I also add some additional beefy supply and ground wires directly between the AR2 and voltage test terminals on the game boards to shed load off the board edge connector.

For a toasted +5 supply, check Q3, the TO3 series pass transistor on the large heat sink. Sometimes this fails just because of poor thermal connectivity with the heat sink; replacing the stock mica insulator with a silpad and a very thin coat of fresh thermal grease can help here.

• WG6100 color vector display: This is its own odyssey :-) Lot's of good info on trouble-shooting and repairing these is available on the web. In particular, there is a low-voltage supply section on the deflection board which is quite failure-prone. There are drop-in replacement supply circuits available; you pull all the components in the original section and solder in a small pre-fab daughter board in their place (google "LV-2000"). This upgrade increases the long-term reliability of the WG6100 to such a significant extent that I always opt to install one of these if not already present.

Next most common are fails with the through-hole cable pin connectors. Solder connections here break from repeated mechanical stresses of plugging and unplugging connecting cables, and for some reason the original factory solders here seem pretty shoddy. Always worth giving these a reflow with some fresh solder.

TO3 deflection transistors are mounted off board on the monitor chassis, using the chassis as one big heat sink. These are frequently a casualty of some other cascading failure in the monitor. Flying leads to the sockets holding these transistors sometimes break loose from mechanical stresses, or the old sockets may fail, or mica insulators may develop shorts to the chassis (silpad etc. treatment is generally a good idea here too.)

One thing to be careful of here is that there seem to be a lot of counterfeits of these particular transistors (2N3716/2N3792) on the market. Counterfeits will mostly work, but can exhibit some strange instabilities at cross-over which can manifest as ringing and parasitics in the deflection amplifiers causing "wiggly" vectors that can be difficult to troubleshoot (see pictures from another WG6100 monitor repair immediately below). Make sure to order from one of the larger, more reliable, parts houses for these.

The HV supply in these monitors seems particularly hard on its electrolytic caps; I've seen more cap failures in these HV supplies than anywhere else in these games. Generally worth just doing a recap kit on the HV board if the caps don't look fresh when you get there; it can help improve the stability and appearance of the monitor a lot. After achieving correct and stable B+ on the HV supply, if there still seem to be brightness problems, check C503 on the neck board and refresh if necessary.

• Game boards: there are eight small PCB mount potentiometers for trimming the analog X/Y outputs. The stock parts are open-frame and seem to collect dust and get twitchy and intermittent (open wiper contacts here can be a cause of loss of video output). I generally just go ahead and freshen these before starting in on the boards, as I hate working with them when they are intermittent/unreliable.

Solder fails in the large interconnect between the mother and daughter boards are also common; these are also worth a preemptive reflow.

These two games from my friends were no exception to the above, and after working the standard stuff for both I had two working bricks, two working AR2s, two working monitors, and one working board set. The second board was producing no output of any sort, didn't appear to respond to its reset switch, and required further investigation.

Okay, like any microprocessor project, start with power, clock and reset... Power looked fine. Clock, not so much. Here's the clock circuit:

12 MHz crystal with some pulse shaping scoped out fine. Master clock then goes to counter chip C4 to divide down to various derived clocks, including the crucial PHI0 for the 6502. Turns out this counter wasn't counting because its clear input (pin 14, seen arriving from below) was being continuously driven. That input comes from the watchdog circuit and power on reset circuit:

Reset was continuously asserted here because of a dodgy Molex connector which was not delivering +10.6 VDC to TL082 K11 at the left. After fixing this, the machine came out of reset, the reset button was working, and there were signs of activity on the 6502 data and address busses. But the game wasn't really running, and the watchdog was repeatedly timing out, so it seemed to be executing incorrect code.

Pulled the game ROMs, and used a burner/reader to verify their checksums against published values from the arcade game forums (all good). Checked for shorts around the sockets (found none) and reseated the ROMs. Pulled the 6502 and manually drove address bus lines to verify proper operation of the ROM address decoders (all fine). Okay, so time to watch the microprocessor busses on a logic analyzer and see what's going on...

Now, I love my old HP 1660 logic analyzer, lots, but a friend had recently loaned to me a compact 34-channel USB logic analyzer (Intronix LA1034) to see if I might be interested in buying it, and I decided to give it a try for this project. It was pretty easy to probe up the 6502 with a DIP clip, and the software for the analyzer (Windows only) installed and ran without difficulty on my Windows 10 VM.

When the 6502 comes out of reset, it fetches its reset vector from locations FFFC and FFFD, then jumps to that address. Looking at the Tempest ROM listings, the reset vector is supposed to point to address D93F. Watching the 6502 address and data busses, and setting a trigger for address FFFC, we can immediately see a problem:

Here, the top line is the 6502 address bus, and the middle line is the 6502 data bus. The bottom line is the output on the ROM bus, upstream of the driver which gates it onto the data bus.

The 6502 comes out of reset, and attempts reads of locations FFFC and FFFD, as visible on the address bus, but it is receiving incorrect data (C82E vs. the expected D93F). It then jumps to the incorrect address, and from that point onward we are off in the weeds. Interestingly, we can see here that the ROM is, in fact, presenting the correct data.

So the first thing was to try replacing the bus driver between the ROM and the 6502 data busses, but this did not fix the issue (sadness). Besides this and the 6502 itself (already verified by swap with the other working game board) there are only two other drivers on the processor data bus: H2, leading to the daughter board, and F2 leading to the RAM bus. ROM bus seen entering here from the bottom:

One of these two drivers must be dragging down a couple of lines on the data bus; nothing to do here but try swapping them out one by one. Tried F2 first, and got lucky! Game code began to run, and the game board produced vector outputs. Correct reset sequence after the fix:

From this point forward, just wrap-up:

• The X positions on the ends of some vectors on the second game board set looked slightly incorrect, beyond what could be adjusted with via the associated rate op-amp offset ("BIP", in Atari-speak) trimmer. This usually indicates a failing rate DAC. Replaced the X rate DAC on this board and the problem was addressed.

• Various small mechanical repairs to the cabinets, replacement of bits of missing hardware, and cleanup of a hacked-up wiring harness on one of the machines.

• The cabaret machine had a failed fluorescent tube fixture for its marquee light; after checking with the owner, pulled this and replaced with an LED fixture for greater reliability (I like this one, which is a 120v fixture that doesn't need a separate transformer or supply.)

• Another upgrade I really like for Tempest machines is a set of brass bushings for the spinner (available here). These make the spinner quiet and smooth as butter.

All done now, and ready to be returned to their owners (after some extensive "burn in" play testing, of course! :-)

[A catch-up article from Christmas, 2020]

My family knows I have a fondness for puzzles, so my son will typically gift me a few each year at Christmas. Among the puzzles received this year was the Project Genius Pyramid:

This is pretty entertaining to play with -- since the planes and angles are not orthogonal, the fits of the pieces are less familiar, and I found it more difficult than usual to use "geometry brain" to think ahead while exploring solutions.

I have recently been playing around a bit with Knuth's "Dancing Links" algorithm, described in his paper here. This is a relatively short paper, and if you are unfamiliar with it I'll say I feel it is really worth a read! The gist is a relatively straightforward backtracking algorithm for efficiently finding exact covers of binary matrices, packed with the usual Knuthian tricks and insights. As many classes of problems lend themselves to expression as an exact cover over a set of constraints, the algorithm has broad applications including tiling/packing problems (e.g. Pentominoes, Soma), general n-Queens, Sudoku, logic puzzles, etc. Having coded up an implementation (on Github here), it seemed it would be fun to extend it to explore the pyramid puzzle.

As a tiling puzzle, the first thing to understand was the cell geometry of the pieces and the space to be filled. The base geometry here is an alternated cubic honeycomb, composed of octahedra and tetrahedra. The complex in this case is further sliced into layers which bisect each octahedron, resulting in cells that are tetrahedra and upward- and downward- facing pyramids:

It turns out that the centers of these cells are arranged on a simple rectilinear lattice. The "flavor" (up-pyramid, down-pyramid, tetrahedron) of each cell is simply determined by its position in the lattice; for a cell at coordinates $$x, y, z$$:

$$$$\operatorname{\mathit{cell\ flavor}} = \begin{cases} \operatorname{\mathit{up-pyramid}} & \text{when}\ (x+z,y+z)\ \text{is}\ (even, even)\\ \operatorname{\mathit{down-pyramid}} & \text{when}\ (x+z,y+z)\ \text{is}\ (odd, odd)\\ \operatorname{\mathit{tetrahedron}} & \text{otherwise} \end{cases}$$$$

So, a simple three-dimensional array and indexing scheme may be used to represent the puzzle space, so long as sufficient care is taken with restricting possible piece placements to preserve flavor-invariance.

A further choice of the puzzle makers was to break a symmetry of the puzzle by choosing a layer height such that the cell-center lattice, while rectilinear, is not cubic (the octahedra in the fundamental complex are taller than they are wide/deep, and the tetrahedra are similarly stretched.) I am not sure whether this was done to avoid having the final pyramid look too squat, or if it was done deliberately to reduce the solution space. In any case, this means that we need only consider "right-side-up" and "upside-down" orientations of each piece; the potential "sideways" orientations do not fit the puzzle space.

A final consideration for the solver is restriction to essentially unique solutions by elimination of rotations, refections, and permutation of repeated pieces. This puzzle has some pieces that are chiral without reflected versions, and no repeated pieces otherwise, so reflected and permuted solutions do not exist. To account for rotations, I chose to restrict one piece ("E") to a single orientation (the "E" piece can only appear in solutions in its right-side-up configuration, because if placed upside-down it blocks any other piece form being able to occupy the apex of the pyramid).

These considerations were pretty straightforward to cast into code for the dancing-links solver; a subsequent run quickly produced an atlas of 80 essentially unique solutions. When physically replicating these with the puzzle, it takes a little practice to get used to moving from the rectilinear cell-center space in which the solutions are printed to the isomorphic pyramid/tetrahedron space in which the puzzle physically exists, but this becomes pretty easy once you've played around with it for a bit.

Of the 80 solutions found by the program, only one seems to be generally known on the web, which is the one published by the makers of the puzzle. It is solution 30 as found by the program:

#30:
┌───────────────┬───┐
│ A   A   A   A │ B │
├───────┬───────┤   │   ┌───────┬───┐
│ H   H │ E   E │ B │   │ I   I │ E │
│   ┌───┤       │   │   ├───┐   ├───┤   ┌───┐
│ H │ G │ E   E │ B │   │ G │ I │ F │   │ I │
├───┤   ├───────┴───┤   │   ├───┘   │   └───┘
│ C │ G │ J   J   J │   │ G │ F   F │
│   ├───┴───────┐   │   └───┴───────┘
│ C │ D   D   D │ J │
└───┴───────────┴───┘

For puzzle fans who may own this puzzle, here is an additional challenge based on some inspection of the atlas: some solutions found by the program have a contained sub-puzzle of a smaller pyramid with base 2x3 (in physical puzzle space, where the larger pyramid is considered to have base 3x3.) Can you find any?

[A catch-up article, documenting events of June/July/August 2020]

Something a little different this time! A friend of mine asked if I could help restore a late-40's portable AM radio set that had belonged to her grandmother:

I have done a lot of work with vintage tube instrument amplifiers, so familiar with many of the principles and challenges, but this would be my first radio. So quite a bit to learn!

Researching this a little, here is the schematic:

It turns out that there were some very common designs for AM sets in this era, copied and tweaked slightly and produced by many different manufacturers. One cornerstone was the AA5 ("All-American 5"), a five tube superhet design. The tubes had their filaments wired in series, each dropping a bit of the input line voltage, so a power transformer was not required, reducing cost, weight, and size. The lack of a power transformer also lead to some of these radios having a "hot chassis" design, which was not without safety hazards -- more on this later...

There is much information available on the web concerning the theory and operation of the AA5 circuit, and a lot of restoration videos are also available. Interested parties are encouraged to Google, but for the purpose of exposition, I will summarize here in brief. Uninterested parties can scroll a few paragraphs past the indent to pick up the narrative :-)

Following circled numbers from the schematic above, one coil of transformer 44 and one half of ganged tunable capacitor 50 in parallel form a tunable resonant tank. Tube 1 provides gain, and the output is fed back positively via the second coil of transformer 44, forming a tunable oscillator. Antenna 43 and the other half of ganged tunable capacitor 50 in parallel also form a weakly selective tank, which picks up RF and dumps it onto an additional grid of tube 1. Tube 1 is arranged such that the a mix of the two signals (oscillator and weakly selected RF) appears at the plate.

The oscillator and RF thus mixed heterodyne against each other, forming frequency images in the output signal at both sum and difference frequencies; the difference frequencies will be of interest to us here. Since the frequencies in the weakly selected RF and the oscillator track each other, their differences are always centered on a fixed frequency, called the "intermediate frequency", or "IF". The remainder of the circuit need only be concerned with further selection, detection, and amplification at this fixed IF. In this set, the IF has been designed to be 455 KC (KHz).

Transformers 45 and 46, with their integrated capacitors, form cascaded selective bandpass filters at the IF. Tube 2 in-between provides gain and impedance matching between these stages. Tube 3 rectifies (negatively) the now highly selected IF carrier, and cap 18 drains away carrier signal components above the audio range, leaving just the amplitude envelope. Tube 4 provides a final power gain stage at audio frequencies, impedance matched through output transformer 40 to speaker 41.

One interesting refinement here is the "A.V.C." ("Automatic Volume Control"). This taps the detected audio signal and runs it through a long time-constant low pass RC filter, producing a slowly varying DC signal that tracks the audio volume. This is fed back as a bias to the tanks at the front end of the circuit, effectively "turning down" overly strong local stations, so they don't boom out of the radio inconveniently loud compared to more distant stations.

As a portable, this set could be operated off batteries as well as line voltage, but it required two types of batteries: an "A" battery, 1.5V, much like a modern "D" cell, and a "B" battery, 90V, long obsolete. I did not bother with battery support during the restoration.

A lot of the wiring in the radio had rubber insulation, which had hardened and begun to flake away. The wax-covered paper caps all certainly needed replacement, as probably did the multi-section cap in the power supply. One of the tube sockets, supporting a lot of the point-to-point wiring, was cracked and broken. The tuning dial string was broken. There were a few small tears in the speaker cone. Line cord insulation was brittle and broken, and the line cord itself was unpolarized. Rubber grommets holding the tuning capacitor had hardened and shrunk. Given all this, it seemed the best thing to do would be to break down the set completely to better be able to inspect, clean and make mechanical repairs. After this, the Hickock tube tester comes down off the shelf to check the tubes:

The 117Z3 rectifier was shot. Someone had substituted a 1T4 for the stock 1U4 in the IF interstage. And the 1R5 and 1S5 were weak. Ordered up some replacement tubes, caps, line cord, grommets, and a new tube socket.

Testing showed that the multi-stage power supply cap was indeed leaky, but I was not able to find a replacement of same dimensions (a 1" outside-diameter tube). I ended up making a replacement with a bit of model-rocketry body tubing, which I stuffed with some modern electrolytic caps of the appropriate values. The result can be seen in the middle picture below, where you can also see some speaker cone repairs done by brushing over the tears with a couple coats of thinned PVA glue. The last picture here shows the completed point-to-point rebuild:

A few words on hot-chassis design and safety: looking at the schematic above, you can see that there is no safety ground, an unpolarized plug, and one side of the AC line is connected through the power switch directly to the B- bus. This means if the line plug is put in one way, B- could be connected directly to AC hot when the radio is on; or if put in the other way, B- would be connected to AC hot when the radio is off, through the resistance of the tube filaments. On some radios slightly older than this, the B- bus is further connected directly to the radio chassis! That means you can get a nasty and dangerous shock off the chassis of such a radio, when the radio is either on or off, depending on which way you plugged in the plug. These radios depended on wooden or plastic cabinets and knobs to keep you from making direct contact with the chassis, but there were still often exposed bolts which connected to the chassis on the backs or bottoms of the cabinets. You were expected to know better...

This Trav-ler radio is a slightly later design, where the chassis is at least isolated from B- by a .1 MFD cap and 220K resistor in parallel. While you won't get such a nasty shock from the chassis of this radio, you can still get an uncomfortable and unsettling "tingle". And if that .1 MFD cap should fail short, your are straight back to danger-ville (on older instrument amplifiers, the capacitor in this particular role became known as the "death cap".)

An improvement for both situations is to replace the line cord with one with a polarized plug, and rewire the radio slightly to a) connect the now known-to-be-neutral side of the line directly to the B- bus, and b) move the power switch to interrupt the hot side of line. EMI filter caps (including the above mentioned "death cap") should be upgraded to modern X or Y safety caps, which are designed to fail open if they fail at all, so as to prevent fire or shock hazard.

Hot chassis designs also pose a challenge (and potential for some surprising moments) with your test equipment. You will often want "ground" for measurement purposes to be B- when working with these things. If this is at or near the hot side of the AC line, and your scope or test gear connects "ground" to safety ground (as most/many do), you are likely to explode the ground lead of your scope probe and/or damage the scope's input amps when you hook it up, with attendant arcs, smoke, and surprise... To reasonably work with hot-chassis designs, you must power them via an isolation transformer, so any point in the circuit under test can "float" relative to the ground of your test equipment. I strongly encourage people unfamiliar with this situation to research it on the web a bit before jumping in on servicing something like this for the first time.

Okay, back to the restoration... After hooking all this up, plugged it in and let it warm up, and while it did come to life and started pulling in AM (!) stations, it was far from optimal. Well, okay, so it needs an "alignment", which means adjusting the tracking on the oscillator and antenna circuits, and tweaking the IF selection transformers to peak up right at design IF. This is done on the bench with an RF test oscillator and a scope or analog meter (topic for another article!) After this, things were better, but there was still a lot of static when tuned in to stations, kind of a granular hiss. So, more research...

It turns out sets like this commonly suffer from something called "silver/mica disease". The IF transformers (45 and 46 on the schematic, the tall silver rectangular parts in the pictures) each have a pair of adjustable coils, and a pair of internally integrated capacitors. The caps in the transformers are typically made with a sheet of mica sputtered with sliver on each side, then sandwiched between a pair of contacts. Both capacitors within the transformer will typically share a single mica sheet substrate. In AA5-like circuits, one of these caps is operating at high potential relative to the other, and over time, dirt and grime provide a path that allows silver ions to migrate between the caps, eventually providing a bridge which rapidly arcs out. As this continues, the mica and silver plating are deteriorated and carbon deposits start to collect accelerating the process.

The cure for this is to open the transformers and remove the deteriorating mica capacitors, then add replacement caps either within the cans or beneath the chassis across the transformer legs. Below you can see some pictures of disassembly of one of the transformers, and the integrated capacitor contact legs at the bottom rolled back out of the way after the deteriorated mica sheet had been removed. Unfortunately, it seems I didn't catch a picture of the damaged mica itself, but a web search will show plenty of similar pictures:

The values of these deteriorated caps cannot be reliably measured, and their design values are not always marked on the schematics. Getting these right to the order of 10 pF or so is important; if they are too far off the available adjustment range of the ferrite slugs in the transformers will be insufficient to properly align the set. A handy approach here is to temporarily tack in some trimmer caps covering the appropriate range. The ferrite cores can then be set in the middle of their excursion, and the set aligned using the trimers; the trimmers are then removed and measured and fixed caps are selected to closely match their set values. An AC bridge is useful for accurate measurement in this range; here you can see a Fluke 710 which was salvaged from the lab:

After this final repair and another alignment, the set started to work quite well! I got lucky with timing and managed to pull in some era-appropriate material from Radio Yesteryear on KTRB while I was testing:

This was a really fun project, and I learned a lot along the way -- looking forward to doing a few more like this in the future!

I recently had need to assess and repair several DL11 serial interfaces in my stock of spares. One of these had had some sort of end-user hack applied; in the course of putting the board back to factory condition, I did some analysis of the hack and its intended purpose, documented here.

Easy enough to beep this out and reverse to a schematic:

So, the hack appears to dynamically alter the CSR address and interrupt vector of the card, choosing between two hard-wired presets, based on whether P1A/P1B are connected together or not.

The CSR jumpers on a stock DL11 operate with pull-ups upstream of the address decode logic, so these can be directly driven by the hack so long as the jumpers for the bits-to-be-hacked are left open on the board. The vector address bits, however, must be driven by the DL11 onto to the Unibus contingent on an appropriate global enable. On a stock DL11, drivers for all configurable vector bits are activated by a single global enable, and jumpers downstream of the drivers control which of these activated bits will be admitted to bus. So, for the vector address part of the hack to function, hack control must be asserted instead of the global enable for each of the to-be-driven bits, and the corresponding jumpers for these bits must be left in. And indeed, upon inspection of the DL11 there are trace cuts that have been done (marked here with "X") to lift the global enable and allow individual hack control of each of the affected bits:

Last, we can look at the board jumpering and the wiring of the hack to determine the specific CSR and vector addresses at play:

A11A10A9 A8A7A6 A5A4A3 A2A1A0
P1 Open 1 1 0 1 0 1 0 0 1 0 0 0 776510
P1 Closed 1 1 1 1 0 1 1 1 0 0 0 0 777560
V8V7V6 V5V4V3 V2V1V0
P1 Open 0 1 1 0 0 1 0 0 0 310
P1 Closed 0 0 0 1 1 0 0 0 0 060

We see from these specific addresses that closing the contacts of P1 would dynamically re-jumper the board from assignment as the 2nd non-console interface to assignment as the console interface. So perhaps this was once used (in conjunction with another similarly hacked interface?) to swap console terminals with the flip of a single switch.

[A catch-up article, documenting events of April/May 2020]

In late April, I offered to give a video demonstration of the '11/45 to some interested work colleagues. Since I hadn't had it on in a while, I fired it up to make sure everything was still in working order. The machine behaved well from the front panel and was able to boot both V6 Unix and RSTS V06C. Great! Typed a very simple demo program in to RSTS (print a multiplication table) and that ran, but produced some very strange results. Uh oh...

Asked RSTS to PRINT PI, and it spat out a value somewhere around 3.7... :-)

So, time to try the floating point MAINDECS... Sure enough, failures all over the place, starting with the very first diagnostic in the floating point suite, CFPAB0. This diagnostic covers utility operations like LDFPS/STFPS, SETI/SETL, SETF/SETD, etc.

I do not have listings for the diagnostics in this suite, but it is usually simple enough to reproduce failures with short toggle-in programs given the names and descriptions of the failing diagnostics. In this case, the following simple code to exercise an LDFPS/STFPS sequence from the front panel switches and lights showed that bits 10 and 11 of the floating point status/control word would come back erroneously toggled:

 1 2 3 4 5 001000 170137 START: LDFPS @#177570 ;LOAD FPS FROM SWITCH REGISTER 177570 001004 170237 STFPS @#177570 ;AND STORE BACK TO DISPLAY REGISTER 177570 001010 000773 BR START ;REPEAT

First things first, check power to the FPU and its clock; these look fine. Next, plug the KM11 into the floating point slot and check the FPU microcode sequences while executing LDFPS and STFPS instructions. These also look fine:

• For LDFPS @#177570 I see RDY.00, RDY.10, RDY.20, RDY.30, RDY.70, LD.50

• For STFPS @#177570 I see RDY.00, RDY.10, RDY.20, RDY.30, RDY.80, STR.30, STR.08

Most of the data paths of interest regarding the FPS register are on the fraction low (FRL) board, so this goes out on extenders so the microcode can be stepped and gate-level logic inspected with a logic probe.

Here is the block diagram of data paths in the FPU, for reference in discussion below:

FP11-B data paths

So, one thing to note with regard to the FPS register is that it is gated through the ACMX multiplexer and written into scratch pad register AC7[0] during microcode state RDY.00 which is the first state in the common prolog of every FPU instruction:

FP11-B microcode prolog

Stopping in state RDY.00 and examining the ACMX inputs, selects, and outputs for bits 10 and 11 immediately reveals a problem. These bits of ACMX are implemented by a 74153 dual 4-input mux, E71 on sheet FRLB of the FP11-B engineering drawings:

FP11-B ACMX <11:10>

Inputs from the FPS register on pins 6 and 10 appear correct, as do the selector signals on pins 14 and 2. But outputs on pins 7 and 9 appear to be inverted. So E71 appears bad. Pulled this, socketed, and replaced. After this fix, LDFPS/STFPS function correctly in the toggle-in test program, and MAINDEC CFPAB0 passes.

Not out of the woods yet, though... Progressing down the sequence of MAINDECS, diagnostic CFPDC0 (add/subtract) now fails :-( For this, we bring back the simple "add two floats" diagnostic used during previous FP11 debug:

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 000000 AC0=%0 000001 AC1=%1 000000 .ASECT 001000 .=1000 001000 170011 START: SETD ;SET DOUBLE PRECISION MODE 001002 172467 000014 LDD D1,AC0 ;FETCH FIRST ADDEND FROM D1 001006 172567 000020 LDD D2,AC1 ;FETCH SECOND ADDEND FROM D2 001012 172100 ADDD AC0,AC1 ;ADD THEM (RESULT IN AC1) 001014 174167 000022 STD AC1,D3 ;STORE RESULT TO D3 001020 000000 HALT 001022 040200 000000 000000 D1: .WORD 040000,000000,000000,000000 ;0.5 001030 000000 001032 040200 000000 000000 D2: .WORD 040000,000000,000000,000000 ;0.5 001040 000000 001042 000000 000000 000000 D3: .WORD 000000,000000,000000,000000 001050 000000 001000 .END START

Sure enough, this is producing incorrect results. The microcode flows for add/subtract/compare are a bit more involved than the simple load/store sequences above. The sequence starts with common prolog RDY.00, RDY.10, RDY.20, RDY.30, same as above. The first fork after RDY.30 goes to RDY.60, since add/subtract/compare are "no memory class" instructions (FP accumulator register operands only). The second fork after RDY.60 takes us to ADD.00 on sheet FP11 FLOWS 8.

The left side if FLOWS 8 is a decision tree for zero operands and/or whether or not we are executing a compare instruction. Traversal of these states sets up fraction and exponent operands and, if necessary, a comparison of operand exponents in the EALU. In our case (addition of two double-precision non-zero operands), the sequence is: ADD.00, ADD.04, ADD.06, ADD.02, ADD.08, ADD.12.

We then end up at state ADD.22 at the top of the right side of FLOWS 8. The previously set up exponent difference is used to index into a 256x4 "range ROM"; output bits from this ROM inform the subsequent microcode fork which determines which operand shift, if any, to apply before the upcoming fraction ALU operation.

Here a problem is evident. We should fork to ADD.24, for equal exponents, but instead we end up add ADD.30, for destination exponent less than source exponent. Putting the FXP board out on the extender and pausing in this state, the operands and operation codes on the EALU bit-slices appear to be correct, but signal FRMH ALU CIN L is erroneously asserted at E34 pin 7 (sheet FXPA). This extra carry (borrow, really, since the operation is a subtract) into the least significant bit-slice causes the EALU output to be -1 instead of 0.

Moving back to the source of this signal on the FRM board, it turns out that FRM E20, a 74H40 dual quad-input NAND, is outputting an invalid logic level at pin 8. Pulled this, socketed, replaced, and the problem appears to be fixed.

After this second repair, the full suite of FP11-B diagnostics is passing again. And RSTS/E has a much less fanciful interpretation of PI...