Bottom platter of 7906 not damaged, working on drive emulator and diagnostics all run fine

HP 1000 SYSTEM RESTORATION

7906 disc drive

I opened up the drive, removing the cover over the fixed lower platter to inspect it better. The really great news was that the lower platter is not damaged. It appears that the line I thought I saw was a reflection of the cover above.

Undamaged fixed platter surface

Thus, I have some crash debris on the top head for the removable cartridge and an unusable cartridge, but with luck, if the head can be cleaned properly, I can restore this drive to operation and use a fresh cartridge. The easy way is to get it clean in-situ, otherwise after removal I will need to do an alignment (without a CE cartridge). 

HPDrive emulated disc drive construction

In case I can't get the physical 7906 drive working, I am building a backup to still allow me to run the HP 1000 system with its RTE operating system. Ansgar Kückes has created the HPDrive software that runs on a PC, in conjunction with an HP-IB adapter board, to act as an emulated disk drive (and more). 

This only works well with National Instrument HP-IB boards. They come in ISA and PCI flavors, but the ISA version forces the use of older machines and versions of Windows. Ansgar has written a driver for the PCI board, easily installed (albeit with a bit effort to override the Microsoft paternalistic ban on installing unsigned 64 bit drivers). 

I will need an HP-IB cable connected to the HP 12821A adapter board which supports HP-IB based disks on the HP 1000 mini. Initially I will borrow that board from Marc Verdiell, but eventually I will buy one once I see this working. I have the PCI board and a suitable windows desktop system on the way to me, courtesy of eBay and Amazon. 

Diagnostic failures

Each time I disturb the ribbon connector that runs from the CPU board and FAB below the IO cage up to the FEM board in slot 10, as well as disturb the backplane for peripheral cards, the machine has gone balky and won't work properly. I suspect the connectors and will clean them with Deoxit Gold - both the IO board to backplane and the FEM to ribbon cable ones. 

Everything cleaned, still some signs of the problem, so began board swapping yet again. It does appear that one of my 12966A serial cards will consistently cause the problem when plugged into the top IO cage slot. With that removed, I could run diagnostics.

As I tried to run the diagnostics for the floating point, scientific and fast fortran instructions (FPP/SIS/FFP) it would hang with the machine stopped but the console unresponsive. I couldn't switch to check other register contents until I did a PRESET on the machine. 

Something is hanging and not returning to the basic microcode - more reason to suspect connectors, either the ribbon cable between the FEM and main CPU board or the ribbon cable between the floating point box underneath and the console panel.

I ran the builtin microcode diagnostics for the FPP, SIS, FFP and VIS and quickly discovered that my likely candidate is the FEM board or its ribbon cable. I could run the FPP routine successfully but the system ignored the codes for the others, which are essentially firmware (microcode) routines. They didn't respond at all the codes. 

These tests are run by setting a code in register A (Accumulator), putting 0 in register P (instruction address) and hitting INST STEP. The codes and logic they test are:

• 100000 - test memory and basic CPU
• 105004 - test floating point hardware
• 105337 - test the scientific instruction set
• 105477 - test the vector instruction set
• 105200 - test the fast fortran program instruction set
• 105242 - test the RTE IV extend memory function

The first two routines run properly and report 102077 in the S reg at completion to indicate everything passed. The final four were nonresponsive. These worked previously thus the erratic cable/connectors is my suspicion, but we also could have a failure on the FEM board or in the ROMs. Since this spans multiple ROM chip sets on the board, the board or cable are the chief suspects. 

I moved the FEM board up to slot 11 so that I could use a different connector on the ribbon cable. Now, every test performed perfectly. I then booted the tape diagnostics in conversational mode and ran the full test for the FPP/SIS/FFP and got a fully successful run. Definitely flaky connectors/cables as I suspected. 

Still chasing phantom issues probably connector related in HP 1000, suffered disc head crash

HP 1000 SYSTEM RESTORATION

HP 1000 Processor

I have a feeling that flaky connectors are an issue in some of the erratic behavior I am seeing. I removed the floating point unit, reseated everything and checked the power supply output. Once I reseated it, the system ran through the floating point processor, scientific instruction set and fast fortran program tests (FPP/SIS/FFP) much better.

The diagnostic stopped on one error in the fast fortran routines, complaining that the .SETP operation was not interruptible during parameter fetch. This was the only error otherwise it completed just fine. Further, it passed that particular test fine a second time. This could have as easily been an interrupt failure from the HP-IB controller card it was using to force interrupts.

I reassembled everything, all IO cards and cables, then attempted a boot of the tape diagnostics again. Alas, my erratic problem where the tape can't be read by the boot loader has reappeared. This has to be limited to the tape drive, cables, tape controller card or some aspects of the basic processor function (less likely).

I pulled the tape cables, reseated the boards and reinstalled the cables, in an attempt to restore proper operation. It didn't work. Will get back to this tomorrow.

7906 Disc Drive

After more cycles of spin-up and plenty of time with the blower forcing out any dust, I let the drive complete a spin-up and drop the heads. I didn't hear anything but my nose detected a burning smell so I switched off and inspected.

Head crash on the top platter of the removable cartridge! I didn't both to look at the other surfaces or the fixed platter below because this is already a show-stopper for me. I only had the one removable cartridge. The platter is cut in a nice thin circle down to the aluminum substrate.

Scratched top platter of removable cartridge

Hard to see scratch on top of fixed platter

If I am to run RTE on the system, my options now are restricted to attempting to find another drive and cartridge or to engineer an adapter to use solid state or modern disk drives in lieu of the 7906. This will take some time and effort.

2645A terminal alternate characters

Marc and I are working to build PROMs to use with the display enhancement board. We do have good examples of the existing character sets from a fully populated such board, which we plan to read and burn onto new PROMs.

The challenge is to select appropriate chips, since HP has not identified the type of chips used. Further, they make use of a very unusual PROM chip that we have never seen in the wild - 1024 words of 9 bits each. Not for every character set. Most use 1024 x 8 bit chips but any 'microvector' character sets require the mystery components.

ROM socket - 8 or 9 bit data path depending on chip and contents

The PROM socket and wiring is compatible with the Signetics 82S181C TTL Bipolar PROM, which works at the proper speed and source voltage to handle the regular character set PROMs. It is not going to work as the 1024x9 part necessary for microvector character sets.

I found a surface mount EEPROM, National's NM27C210, which is 5V, fast enough for the job and has more than enough capacity. In fact it is a 65536x16 component, which is sufficient to delivery 9 bits of the 16 for 1024 of the 64K addresses.

The plan would be to build a small PCB the size of the regular 24 pin DIP socket used for the Signetics part. The NM27C210 would surface mount on the top and the board would route the signals to pins soldered through the board at the locations of the holes in the socket below. It would provide zero bits for the high order addresses and handle the enable lines from the socket to produce the relevant signals for the new chip.

We would need to work out a jig or fixture to program the chips, probably by providing small additional pins sticking up through the top of the PCB to feed the address, data and control signals for writing to the chip before it is plugged into the HP display enhancement board. 

7906 disk fault corrected, working on 2645A tape drive capstans and debugging some HP 1000 F processor faul

HP 1000 SYSTEM RESTORATION

Tape drives in 2645A terminal

The capstan tires I ordered will slip over the metal capstan wheel as a replacement for the rubber coating that liquified with age. This failure of the rubber rollers is quite pervasive across many types of tape mechanisms from audio to video to computer peripherals, affecting almost every mini cartridge drive mechanism in existence. 

Capstan wheel with remnants of liquified rubber still to remove

I cleaned the existing rubber sludge from the metal capstans in preparation for the new tires, but had to set everything aside waiting for the tires to arrive from China in 2 to 4 weeks. Once these work, the terminal can be used to read and write data, programs and even as a device for booting the HP 1000. 

7906 disc drive

When I left off, prior to my trip, the drive was displaying a disk fault error. There are several causes of this, differentiated by small LED lights on the controller board. The failure I see is either loss of one of the critical power supply voltages or a fault in a line of microswitches, jumpers, thermal switches and other devices called the interlock chain.

I had tested the output of the power supplies, all of which appeared nominal. Based on that I was convinced that the problem was in the chain. Setting up the voltmeter on a suitable component on the controller board, I powered up but the voltages from the interlock chain seemed correct for a no-fault condition.

It was time to test more comprehensively on the controller board, determining where the fault logic is set and tracing it back to determine what component has failed. Eventually I found that the spindle encoder board connector was slightly loose, breaking the interlock chain. With that repaired, the fault condition went away.

I let the blowers run for quite a while, interspersing spin-up cycles where I let the drive get to nearly full speed before flipping the run switch off. I want to dislodge any specs of dirt or other contaminants that might remain inside, before I let the heads load onto the disk.

In the final run, I flipped off the switch just as the arms began to move out over the disk surface, but before they were actually loaded. I still don't like the sound of the bearings on the spindle motor, although in some cycles it is quieter than in others.

It is possible that the grounding strap on the bottom of the spindle is what is making the noise, rather than bearings, since it was initially quiet then progressively returned to the louder sound. I will wait for a new day to let the heads actually load, hoping that I don't have any crash on either the fixed lower platter or the upper platter in the removable cartridge.

HP 1000 processor

Prior to my trip, I had been running through all the tape based diagnostics for the system when I began encountering problems. The tape wouldn't boot any more, which is either a new fault in the processor or the tape drive/controller. I set up to recreate the issue and begin debugging.

I yanked the timebase generator and the second 12996A serial board, tested and found everything good again. May be gremlins, might be one of those boards. In any case, I completed the full FPP, FFP and SIS test with no problems.

I next reinstalled the timebase generator and ran the diagnostics for it. That worked perfectly - it is a long sequence taking almost 20 minutes but just when I was ready to give up, the longest test completed and it raced through to final status.

I wanted to test DMA, memory protect, and some of the IO boards but in all those cases, they required some special test fixture to plug into certain IO cards or some manual operations such as reversing parity by grounding some pin.  It appeared that everything was solid in the processor itself and with the timebase generator, tape controller and my primary serial card for the console.

I plugged in all my boards and connected all the cables - second serial, microcircuit, HP-IB, and disk controller. With everything in place, I powered up to rerun some diagnostics but found that the basic loader was hanging before it read in the entire boot file. This was the same kind of problem I faced before today.

It was time for lunch, but later today I will yank one card at a time out of the IO board until I find the one that is causing this problem. Cycles of power down, card manipulation, power up, loading tapes and attempted boots, a few minutes apiece, so this took some time.

The boot loader is looping waiting for the next word to be flagged as ready to pick up. After yanking every card except for the tape controller and terminal card, it still failed to read the boot record. I swapped to the other diagnostic tape reel but still have the problem.

At this point I have to assume that the recurrence when I plugged in all the cards was coincidental. I either have some flaky connector somewhere or the controller card or the tape drive itself is flaking out. I wiggled all the connectors both inside the tape drive and on the HP 1000 itself, but the tape continues to hang.

The question is why it was hung before I left, why it was okay again when I started this morning and what pushed it back over into failure. It may be some component getting hot after prolonged use, then cooling. I will let everything sit for hours until it is at ambient temp, then try again.

When it was cooled and I gave it another try, the same hangup was experienced, making the temperature based failure theory less likely. I yanked the serial card entirely, leaving nothing but the tape controller plugged in. Viola, I could boot the tape again.

Since I have two cards, I put in the other terminal (serial) card and could again boot up. Using the diagnostic monitor, I selected the floating point instructions diagnostic once again and let it run. Unfortunately, it almost immediately reported an error attempting a FADD operation.

When I tried to run it again from the bootup, the diagnostic monitor halted with an error 010675 which means that the code took a dive to a random location. The first 4K of memory is loaded with this halt as a way of trapping any such failure to execute properly.

Something is sick in the processor, I conclude. Time to step through the diagnostics from the most basic onward, hoping to find the most basic fault first. It is likely that the failure of some instruction type or facility is causing the branch to a random location, thus I want to find that errant logic and repair it before running through too many more of the diagnostics. 

I stepped through the basic instruction tests:

• memory reference
• alter/skip
• shift/rotate
• EAU
• extended indexing

I didn't complete the extended word/byte tests because I need to add another IO board to be used for interrupts. The same is true for my test of floating point, scientific and fast fortran instructions (FPP/SIS/FFP). I planned out my next set of runs.

When I run the floating point instruction tests, it fails hard on FADD. When I run the FPP/SIS/FFP diagnostic, it fails on the FIXS instructions. These are the first of a set for each diagnostic. I don't know whether it is my extended microcode failing (FEM board) or the floating point processor hardware, but something is sick.

I went out to run full memory diagnostics and to add in an interrupt card to compete the extended word/byte instructions test. Both passed with flying colors. Using the interrupt card with the FPP/SIS/FPP diagnostic, it ran further, but in the midst of the SUB test I saw the S register lights go dark, along with the OFLOW and EXTEND lights. 

I waited a long time but nothing further happened. The absence of these lights is highly, highly unusual for a running program and suggests some microcode going awry. My suspicions are leaning slightly toward the FEM board at this point. 

Ethernet tool final testing, disk head repair on two Diablo drives

DIABLO DISK DRIVE HEAD REPAIR AND ALIGNMENT

Finally back from my trip, which was extended a few days due to travel disruptions. We met on Friday at Marc's home and focused mostly on the disk drives, since we had two drives with crashes to repair.

The damaged heads are removed by unplugging their cables, loosening a cable clamp and loosening the allen head clamp screws that lock the head assembly in place. One clamp screw is common to both head assemblies and is normally torqued to 50 inch-ounces of force. Each head assembly also has a discrete clamp screw holding it in place, torqued to a lower force of 26 inch-ounces.

With the heads removed we could put them under a stereo microscope, examine the oxide stuck on them and begin cleaning. The normal method of cleaning is to use isopropyl alcohol (IPA) of at least 90% purity. 

IPA is hygroscopic and absorbs atmospheric water vapor, but we want a minimum of water in contact with the iron magnet poles on the head. We use IPA rated at 99.9% pure, so that even with absorption it will be well above the 90% target. 

Cotton swabs made to have minimum risk of detached cotton strands are used, since a strand of cotton is enough to cause a disk crash in a running drive. We scrubbed the heads quite a bit with the swabs and IPA, but were left with some oxide residue in the grooves in the head surface.

The head is a ceramic shape with a polished smooth surface shaped as an airfoil allowing it to fly some few microinches above the rotating disk surface. A cruciform shaped trench is formed in the ceramic to expose the iron poles from the read/write and erase coils.

The long trench, oriented at right angles to the disk center, gives a longer pole for the read/write coil. The shorter cross trench has a pair of pole ends from the erase head straddling the read/write pole. The pole of the erase coil is a U shape with the two top points of the U exposed in the trench and the rest extending below the head surface.

The trenches are not polished, thus the rough surface can accumulate oxide from a head crash and is harder to read and clean with a relatively huge cotton swab head. The degree of heat generated during the crash also determines the type of debris on the head. 

Disk platters are coated with a slurry of iron oxide powder and a binder - something like epoxy - which is spun onto the surface and baked dry. It is then polished smooth before being assembled into disk cartridges. 

Light crashes leave lighter brown material that is easier to clean, but a longer duration of rubbing raises the temperature, scorches the binder material of the oxide and makes for a dark and dense material. 

Marc has an ultrasonic cleaner which he put to use to work on the material in the trench we couldn't remove with swabs. The worst of the four heads (two per drive) needed about an hour of gentle ultrasound cleaning before it was 'like new'.

The heads were reinserted into the disk drives, the discrete clamp screws set to 26 inch-ounce of torque but the common clamp left loose. This will allow us to force the heads to slide inward towards the center of the disk platter as we attempt to align the drive. 

The side of each head assembly has a V notch cut in the metal. This allows a setscrew to be turned in the mounting block and as it extends, it forces the head assembly outward as the screw tip rides against one edge of the V towards it center.

Alignment makes use of a special CE disk cartridge which has a special pattern recorded on specific tracks. The drive comes in standard and high density versions; the Alto uses the high density type. Thus, we are interested in track 105 as the alignment standard.

Two stripes of data are recorded, centered on track 105, but spaced slightly to either side of the centerline. As the head position is advanced from below track 105 towards the center, the scope pattern will show peaks from the stripe that is closer to track 0 to be stronger than the offset pattern from the far stripe. 

When the two stripes are equidistant, the head is centered between them, over the location of track 105, and the scope shows twin peaks of equal amplitude. Thus the head assembly is advanced until we see that symmetric pattern on the oscilloscope.

We mounted the cartridge, spun up the drive a few times, finally allowing the heads to load. It looked good but after about a minute we started hearing an odd sound so we unloaded the heads. Visual inspection of both the heads and the cartridge surface showed no problems.

When we tried to spin up again, we heard some screeching sounds as rotation began. A known good cartridge also made the same sounds, with it and the CE cart now refusing to spin at all. We have a drive problem that we have to resolve before we can perform the alignment.

ETHERNET TOOL DEBUGGING

Ken worked on his ethernet tool. This consists of a Beaglebone board plus a PCB ken built to interface the signal voltages. He recently moved from the breadboard version used in development to a PCB (production) version.

He found some ringing in his signals outbound to the Alto which he addressed with the addition of a small capacitor, then moved on to testing and debugging all the functionality. The tool includes the IFS software developed by Living Computer Museum, providing a full suite of functionality equivalent to the bridge box they loaned us.

During long operations, typically a copydisk from a physical cartidge in the Diablo drive to a virtual cartridge in the tool, the Alto and tool would get out of sync. It appears to be an issue with collisions particularly with breath of life packets occurring very close to a copydisk packet.

The rate of errors is low but not zero, thus Ken will continue to probe this until he resolves the issue completely. Otherwise, the tool is working well. It connects directly to the multipin ethernet connector on the rear of an Alto, thus we have no need for the outboard ethernet transceiver or any 3Mbit cabling.

The tool allows routing, interfacing to modern 10/100Mbit ethernet networks and all the other functionality provided in the IFS code base. We are returning the LCM bridge box to Al Kossow at this point.

MISCELLANEOUS

Marc has a number of old Macintoshes and drives, starting with the original Mac, then moving to the  512K, plus and others. He did some work to set up disk images on 400K and 800K floppies as well as with a hard disk, taking advantage of Appletalk and Ethernet networking as appropriate between the various machines.

I received the last of the incandescent lamp types needed for the HP 7970B and 7970E tape drives. I will bring one over to Marc to repair his 7970B drive, in a future session.

Tape not booting and going 'off the air' for a week

HP 1000 SYSTEM RESTORATION

continued diagnostic execution

I attempted to boot the diagnostic tape again but it appears that the tape controller or tape device is misbehaving. I will need to troubleshoot this before I get back to running diagnostics.

I am going to be busy for about a week, with no chance to work on the system or any other tech project. No posts until probably mid next week.

Worked on 7970E tape drive then successfully ran quite a few diagnostics on system

HP 1000 SYSTEM RESTORATION

7970E tape drive

I opened the drive and pulled out the light bulb to verify that was the cause of the failure to detect load point. It was indeed open (burned out filament) but was an odd looking bulb, not like the one installed in the 7970B drives.

Suspected infrared LED in between the two yellow photocells

When I looked at parts drawings for the E drives, it was still not a match to what I saw. I first guessed that somebody modified this to substitute a different 5V bulb due to the relative scarcity of the original Chicago Miniature CM8 428 part. However, the board could not have mounted the flanged bulb at all, thus this is a different sensor board entirely.

Top view of photosensor board, LED wires disconnected

It appears to be an infrared LED which does show a working one way diode junction. I have a feeling tht my problem may not be a burned out bulb as I had expected from the experience with the incandescent based 7970B mechanism. Of course, as it does not emit visible light, I can't directly observe its operation.

After reconnecting it and replacing the sensor board into the drive, I found it perfectly able to detect load point, thus I can resume using the drive to run diagnostics.

diagnostics on processor

With the tape now working, I booted the diagnostics and was able to complete the pretest section which verifies basic 1000 processor functionality. I then reran this in loop mode causing it to repeatedly do the pretest, only stopping if an error halt is discovered (o102066 primarily).

The process begins with the built in boot loader ROM for mag tape. This is selected by choosing the proper rom using an b01 in the high order bits of register S and the select code (IO cage slot number) for the mag tape controller. One then pushes the IBL button which sets up the chosen ROM as high memory contents.

Pushing run executes the boot loader, reading in the initial diagnostic control program into memory and ending with a halt o102077 if the read was successful. At this point the code is sitting in memory but not yet executing. To run it, I have to set the P register (instruction address register) to the value of the start of the pretest code, the configuration routine or the specific test selector routine.

The P register value for pretest is o000002, but it can be skipped by setting P to o000100 which runs the configuration process. One selects the P register, sets up the value 000002 or 000100 in the display register, then hits Store to load P with that value.

Before pushing Run to execute from that address, the S register is selected and a value is placed in their to control how the pretest and/or configuration process should behave. For example, bit 12 is set to loop the pretest continually. The select code of a terminal is set in the low half of the S register if you want an interactive session with the diagnostics.

I will first loop the pretest to stress my processor a bit, then start a conversational session with my 2645A terminal. The pretest hit errors with unexpected interrupts. I removed the microcircuit, HP-IB disk and second serial controller cards. The interrupts were no longer detected. 

The attempt at a conversational session worked well. I began running the diagnostic programs, selecting each from the list in a reasonable sequence. For example, the memory reference, alter/skip and shift/rotate instructions are essential for the correct operation of other code, thus they were run in that order. 

I proceeded to test all of memory, extended indexing instructions, and continued until I was running the tests of the floating point, scientific and fortran assist instructions. This aced its basic tests and was walking through its so called long tests of functions when, during the SUB test, it was taken down by an unexpected interrupt. 

All I have left in the machine that might cause this are:

• Serial card for the terminal
• Mag tape controller for the 7970E
• Time base generator
• FEM extensible microcode board
• DCPC dual DMA channel board
• floating point processor itself

I am not even sure that the FEM can cause interrupts, nor the floating point, but included them for completeness of the list. I couldn't run any diagnostics after this point, continuing to receive spurious interrupts even during the attempt to use the boot loader. I wrapped up my work for the evening.

2262 terminals and 7970E tape drive for HP 1000 system working; pressing on processor and disk debug

HP 1000 SYSTEM RESTORATION

2622 terminal

It was definitely time to hang the logic analyzer and scope on the interface between the keyboard and the monitor, to figure out why the keypresses are scrambled. My attempts to find a mapping from press to displayed character, in the anticipation that there may be a dropped or hot address bit, came to nothing. 

I noticed, for example, that pressing the F5 key on the keyboard produced an 'f4' character on the screen. but other Fx keys didn't display anything. Thus, the assumption that the A0 bit is stuck off didn't work out. Further, since I saw intermediate voltages on all the address pins, they aren't sitting at a steady voltage. 

It was easier to bring the monitor and keyboard into my house, near the logic analyzer, since I was pinched on space out in the workshop. I didn't hook up all the address lines, just A0, A1, A2, A4 and A5, but already I could see a problem in the scan coming from the monitor.

Signals on line 13 is frozen at 1

The logic analyzer shows that bit A2 is frozen at 1 (it is on wire 13 of the logic analyzer). I put the VOM on the pin and saw a steady 5V, confirming the problem is coming over the cable. I also need to probe bits A3 and A6 to verify whether they are cycling or frozen, but I do see at least one real problem to debug.

The fact that the low bit (bit A2) is frozen high would convert my F5 keypress into a F4, and after I monitored the other lines, I found that only A2 is stuck. Besides the effect it may have selecting rows improperly, it would report an identification bit not only at 7F but at 7E which may be confusing the monitor decoding keys. 

Next up, I identified the pins on the monitor logic board that correspond to the row values being emitted, checking with the scope to see at what point in the circuitry the bit becomes stuck high. The first traces did show that the line stayed high with only the slightest bit of noise present, while bit A0 cycled properly. 

I moved the scope over to the monitor, saw the same values on A0 and A2, then pulled the keyboard cable and exactly the same results pertained. Totally localized to the monitor. The row lines (A0, A1 and A2) are driven by inverters, thus not dependent on pullup resistors in the keyboard which is why the signals are valid with a disconnected cable.

First stop is to test the input and output of the inverter gate driving pin A2. That would be a hex inverter chip at U214, with this signal on pins 12 and 13. If the input is still bad, it is produced by a complex chip U412, which is an National Semiconductor 8367 CRT Controller chip. Not only unobtainium, but even the documentation seems to be unobtainium. Sure hope it isn't that chip that is failing. 

The structure of the terminal presents only the non-component side of the board to me when hooked up. This makes it hard to get probes attached anywhere but I mapped out the locations in advance and stuck markers on the bottom of the board to guide my probing. It was right at an edge near the keyboard connector. 

The outputs of the inverters were correct! The pin I thought was the connector pin for the signal was not. Turned out I had miswired my cable after all and was permuting the address bits. I cut open the cable I made and swapped around the affected wires. 

Works perfectly now! My original 2262A terminal and the keyboard work well. I brought them into the workshop, switched to the second 2262A (actually named a 250 terminal for use with a newer HP system), hooked up the keyboard and tested again.

The keys worked properly with the terminal, however once I got past the configuration status and initial test, the display blanked out and no key would awaken it. This may be a configuration setting, dip switches somewhere or something else I don't know, but for the time being, I put the 250 terminal aside as spare parts or a future project. 

I did grab the monitor base from the 250 and put the 2262A on it, so that I have a usable terminal now. All that remains to clean this up is to build a bottom case for the keyboard and to install the right kind of speaker inside for the beeps. 

HP 2262A terminal working with keyboard

7970E tape drive

I did a boot load of the diagnostic tape, which halts with 102000 in the S register, indicating a format or data error. I examined the A register, which had been rotated one bit to the right in order to test bit 0 for a 1 (which originally was bit 1 and indicates data error or timing error). The shifted value was o042003 thus it had been o104006 when read from the tape controller.

Bit 15 indicates 1600 bpi tape, which is the format of the tape we are trying to read. Bit 11 indicates that there were an odd number of bytes read, which is suspicious for a binary boot file since the HP is a 16 bit word machine and should have an even number of bytes. Bit 2 indicates that the write ring is not in the tape, which is correct. If bit 4 had been on along with bit 1, it would have meant a timing error - the absence of bit 4 means it was a pure data error. 

Both tapes get this error now, which I believe indicates some problem reading in my drive, rather than the much less likely situation that both tapes are defective. This may require some scope and logic analyzer work to figure out. 

I put in some work to enhance my hand code, in the hopes that I could get to successfully write my special 2 word record to a blank tape and then read it back in successfully. There is conflicting information about the need to set the control bit in the tape data channel once you start a write or read. 

Several places it was written that when you start a read or write, the control bit for the data channel is switched on automatically. However, I did spot a place where it was being set manually, so I added that into my code.

Eureka! My hand code to write two words, o123456 and o050505, as a record at the load point of a blank tape stopped successfully on its halt code 102000. The tape started, moved and stopped. 

Next, I entered my hand code to read two words and load them into the A and B registers before halting. Manually rewinding the tape to load point, then hitting RUN brought me to my successful halt 102000. More importantly, the registers held the values from the tape. 

I thoroughly cleaned the tape heads and tape cleaner block, after which I was able to get the diagnostic tape to boot successfully. That is signaled by a halt from the boot loader of o102077. Next up was to run the pretest which validates correct operation of the HP 1000 F and the facilities needed in order to have the diagnostics run. 

My pretest ran but ended with a halt code of 102066 - this signifies that some test failed. No terminal output or simple code to show what failed, thus I have to look through the pretest code to see where it tossed in the towel. 

Great progress. I collected the pretest code in preparation for running the diagnostics again and checking the register contents to tell me what component is not working properly. Alas, the tape drive chose this time to have its small incandescent bulb burn out, thus it won't recognize the load point reflective strip. Can't load tapes or use it until I get a replacement bulb and install it. 

7906 disk drive

I put a VOM on the line that I expected to clarify whether the chain of fault interlocks was open, expecting to see something either close to +12V or -24V, but the reading was -4V. There is a voltage divider consisting of three resistors from the high side to the low side, which add up to 36K ohms to divide up the 36V differential.

The point where I was measuring is about 1/6th of the range up from the low point, therefore it should have been about -18V rather than -4V. That suggests I have some problem but certainly not an open circuit which is the usual means that a disk interlock fault is signaled.

That suggests my low voltage is about -7 instead of -24V, which would be sufficient to cause the OR gate input to be positive and trigger the IFL condition. The voltage divider up from the -4V to the +12V high side would put about 5.6V on the gate input, but if the low voltage was at its proper level the input would be down around 0V and the gate would not emit the IFL.

I still should trace back through the chain of interlocks, starting of course with the -24V source, as it is possible that somewhere there is a significant resistance instead of a closed circuit. Nothing is easily accessible but it is the way forward.

Tried tape diagnostics for HP 1000 but tape drive not working well enough; terminal debugging

HP 1000 SYSTEM RESTORATION

2262A terminal

The three possibilities causing the issues hooking the keyboard up to the monitor with my home made cable were:

• cable is wired wrong, has broken wire or short inside
• monitor circuitry is not working properly
• extended keyboard is not compatible with this terminal

A session with a VOM proved out the cable. I am certain of the pin assignments on each side and verified that the cable positively connects each pin to its counterpart without contacting any unintended pin. 

The logic in the monitor cycles through all the row and column combinations using bits 0-2 for row and bits 3-6 for column, while watching the output pin to see if it goes to ground when the addressed keyswitch is pressed. 

I used the VOM to see if the addressing signals from the monitor were being delivered across the cable. Power and ground were delivered and each addressing pin had a value somewhere intermediate between +5 and ground, consistent with it alternating on and off as the monitor tests for each key. 

I then pressed a number of keys - some few displayed characters on the monitor, indicating that the monitor circuitry was watching for the keyvalue bit going to ground as I pressed the key. The displayed character never matched the keycap. 

The value produced was consistent, for example the keycap 'w' produced the character '9' on the screen reliably. This implies that my problem is the third of the possibilities, incompatibility of the keyboards. 

Some flaw inside the monitor circuitry could still be at fault, specifically if the correspondence between the keyboard addressing pins and the value to be generated is wrong, perhaps because one of the bits is dropped.

I need to study both sets of keyboard documents to check for disparate assignment of row/column to keycaps. I also need to study the bit patterns of the characters on the screen versus the keycap associated value to determine if there is a clear case of a dropped or hot bit. 

I switched over to the newer 2262 that I bought from a recycler, hooked up the keyboard, and had similarly disappointing results. I suppose I should add one more possible flaw to the list of potential causes. Perhaps the logic in the keyboard is misaddressing the keys somehow. 

My initial test of the keyboard while disconnected from the monitor chose only one key, 'return', and validated its proper selection and detection. Since the first terminal was waiting for a CR but never detected it, that argues against the flaw being inside the keyboard but I have to remain open to all causes until I find the culprit.

An added complication I discovered is that HP sets up the row/column matrix to have fixed diode connections at certain non-key locations, as an identifier of the type of keyboard attached. This implies it will properly detect the encoding by the keyboard type and work properly. If there is anything wrong with the row or column decoding, or the diodes for identification, then the monitor may interpret the key codes the wrong way. 

I decided to bring the keyboard inside and run through all the row and column addresses, verifying each and every key and the fixed diodes. After this check I could declare the problem to be in the appropriate side, keyboard or monitor. 

The answer is that the problem is in the monitor or an incompatibility. Since the manual refers to this keyboard as the standard attachment for the 2262A terminal, I will very tentatively rule out incompatibility since there are two different terminals from different sources that misbehave the same way. 

The problem is not in the keyboard, except for the wild chance that having the speaker not connected (the source of the beep in the keyboard) is throwing off the terminal's identification of the keyboard type. 

Tomorrow I will wire up a speaker, just for grins, but then move on to connecting logic analyzer probes to the monitor logic board just to see what it believes is happening. Nothing in the manuals or schematics shows a way to manually configure the terminal for the keyboard type being used. 

running tape based diagnostics

Marc Verdiell loaned me 9 track tapes loaded with the diagnostics for the system. I should be able to boot from the tape, selecting my 2645A terminal as the console and run various diagnostics against all my I/O gear and the processor itself. 

The two tapes had different versions of the diagnostics, but neither would load. I used my built-in loader ROM to load the program from the tape, but got different errors with the two tapes. 

The first tape started motion when I ran the loader but never stopped. I let it wind through about 10% of the tape to be sure that it was past the point where the program would have concluded. I hit the Halt key but the tape kept moving until I hit Preset to reset the tape drive. That means it was in the midst of a read operation but the data wasn't streaming in to memory.

The second tape read a very brief time then stopped with a value in the processor's S register that signaled a tape error or invalid format. It did this consistently at the same point. 

Something is probably wrong inside the 7970E tape drive such that it is not correctly detecting characters from tape and perhaps flagging false errors in the case of the second tape. I have to assume the two tapes are good, since the odds that both are bad is quite low.

This sounds like a job for logic analyzers, scopes and debugging skills. I had already cabled up my working 2645A terminal to the system in anticipation of using it as the console for the diagnostic programs. Alas, until I get the tape working I have no diagnostics to run and no use for the terminal. 

Friday session at Marc's involving several machines

DIABLO DISK DRIVER VERSION OF ALTO DISK TOOL

I hooked the tool up to the third Diablo drive we have, one loaned by Al Kossow to allow us to copy disk to disk. It was not able to make the terminal seek.

Since the tool works great on the first drive, stutters with delays  seeking on the second drive (one inside the Alto), and does no seeking on the third drive, there is some difference with electrical characteristics to explain this. I will need to test this carefully with scope and possibly logic analyzer until I find the reason. 

ARCHIVING PARC DISK CARTRIDGES

We hooked up the third drive to our Alto, setting it to unit 2. Our plan was to use the drive to read and archive the cartridges from Xerox PARC, while we retained our unit 1 drive for use with our Alto cartridges. 

We did this because the first drive has some residual disk crash contamination on the heads from one of the PARC packs being read many weeks ago. As it is likely that further crashes may occur with many dozen cartridges to archive, we wanted to protect our basic Alto ability by sequestering the PARC packs to drive unit 2.

We began archiving content, using the copydisk function to the LCM provided networking bridge from our unit 2 drive. We completed archiving a number of packs, but then one of the cartridges began encountering hard errors right away.

We removed that cartridge, read another one fine, then near the end of archiving another one we encountered another hard error. At that point we opened the drive to inspect the heads. The lower head had some oxide packed into the gaps in the head, so we cleaned both top and bottom heads.

While the lower head now looked fairly clean, when we inspected the upper head using a mirror we could see quite a bit of oxide and clear signs of a crash. We opened that last pack and found some rubbing marks consistent with a crash - not so deep that the aluminum substrate was visible, but too much to risk mounting the cartridge again.

Our plan is to remove the heads from the drive, clean them well with the aid of a stereo microscope until we are positive they are as good as new, then reinstall them and align them using the disk alignment cartridge loaned to us by Bruce Damer.

ETHERNET TOOL TESTING

Ken continued to QA test the ethernet tool, passing everything except for some problem that occurs only with copydisk but not network boots, ftp, or the many other protocols used with the Alto. He collected some data and will be examining the code and data to resolve this for our next session in a week. 

Ken also designed a PCB to make the ethernet tool much more rugged - he should receive the manufactured boards in about a week. The goal is to have the rugged version, built into a case, and in steady use before the end of the month when Al will need the LCM box for use back at CHM. 

MISCELLANEOUS REPAIRS

Marc was able to repair a external 20MB hard disk for use with his Mac 512 and SE/30 computers, a journey involved failed power supplies, microcontroller chips, disk failures and transistor suicide. 

We also worked on a few problems with an HP 7970B (800 BPI 9 track tape drive), including the begin/end of tape sensor and idler roller. 

POWER ANOMALY IN OUR ALTO

At one point while Ken was debugging the ethernet tool, he would switch back and forth by unplugging the tool from the Ethernet port of the Alto and plugging in the transceiver box that connects to the 3Mbit cable. After one such swap of cables, with power off, we turned on the Alto to find the disk drive displaying the Check error light. 

We powered down and back up again to see if it was a transient issue, but upon power-up of the Alto the disk drive was completely off. I pulled out the chassis and saw that both +15V and -15V supply lights were out.

We opened the unit, found both fuses good, and began a binary search for the problem by disconnecting both ethernet transceiver and disk drive. The two supplies came up fine. We connected the disk again. It came up fine. We added the transceiver. It came up fine. No problem and no explanation for what 'fixed' it. 

We saw a partial repeat much later in the day, when after some swap of ethernet port connections we powered up to find both unit 1 and unit 2 disks with the Check lamp lit. The power supply LEDs showed us that the -15V supply was off. A power cycle made everything happy again.

We believe we have an intermittent problem that will become more pronounced or fail permanently in the future, but have no clue yet about the transient cause. 

HP 2622A TERMINAL

I have traced and verified the connector pins on the monitor back to the ICs from the schematic. I now have verified that my keyboard and monitor side pin assignments are correct, the keyboard works properly (based on yesterday's test), and thus my problems using the keyboard with the monitor could only be:

• Monitor circuitry is faulty, not emitting row/column addresses and latching in key status
• Incompatible combination of extended keyboard and 2622A monitor
• Some flaw inside my cable between the two connectors

Debugging work on terminal, disk and tape drives

Another set of disruptions keeping me from devoting my every waking hour to computer restoration. We discovered that a petsitter who was going to housesit and care for our dog in an upcoming trip had to cancel. We scrambled to find a replacement to live here. 

Next, a friend is doing a mass mailing for a charitable organization but discovered that they required the mailing list in a very specific format. Python and some hand editing to the rescue, eventually producing 250 properly formatted addresses. 

And lastly, family came over tonight which is a priority over computers. 

HP 1000 RESTORATION

7970E tape drive

I entered my write program into the HP2100 simulator, which was set up as an HP 1000 F with the 7970E drive and loaded with a 'blank tape' file. My program looped waiting for the flag to write out a word, just as the real machine does. 

This reinforces my belief that I don't understand the IO programming well enough to test the tape drive, at least with the current code I produced. I should have a diagnostic tape to do testing this weekend, but if I have time and can figure out the defects in my approach, I may try some more hand code.

2622 terminal

Since I was seeing some action from the keyboard, but nothing rational based on the key being pressed, I disconnected from the monitor itself and decided to test the keyboard separately. I have to supply +5 V to the keyboard and then watch the various output signals to see how it is registering key-presses.

It was a bit more complicated than it seemed. The keyboard receives addresses from the monitor, cycling continually through all the keys by sending a row number and a column number while it watches the output of a single bit signal. 

Since the row and column inputs had pullup resistors, I only had to ground the pins I wanted at 0 and could set up the address for a specific key. The output bit is an open collector circuit, with no pullup resistor, so I had to supply one for the testing. 

The result was good - the keyboard is working perfectly and I understand the pin assignments perfectly. However, it still doesn't work with the monitor. There are two possibilities. First, I am using the 'extended keyboard', 02620-60061 instead of the standard one. Second, the monitor PCB may be malfunctioning.

This weekend I will put the scope or logic analyzer on the pins from the monitor to verify that the monitor is polling all the keys in a repeated sequence. If so, I can then pull the single input bit low at random times to signal characters being pressed - if the monitor doesn't respond, it is likely the board.

As a final check to determine whether it is incorrect keyboard or logic board problem, I can set up some TTL logic to pull the single input bit low only when the desired row and column numbers are output. This will either result in that chosen character marching across the screen or tell me I have some bad logic on the monitor board. 

7906 disk drive

Having spotted a resistor on the control PCB which will show me a possible cause of the Disk Fault condition, I hooked up a probe and watched the signal. This signal comes from a chain of connections through all the PCBs plus some microswitches and thermal switches. 

When all the switches and links are complete, it delivers -24 volts to a a transistor circuit that operates as an OR gate, switching it off. The other leg of the gate comes from a power supply testing circuit that verifies certain key voltages are present. The output of the OR gate is the interlock fault signal that my control board insists is on, thus generating a Disk Fault.

Good day at CHM with 1401, plus a wee bit of work on the HP 1000 peripherals

1401 RESTORATION AT CHM

We have had a lingering problem with the card punch side of the 1402 on our "Connecticut" system, where we experienced spurious punch checks as the card which has just previously been punched is now verified by passing through a block of read brushes. 

The brushes are installed in a brush block, eighty brushes one for each column of a punched card. As a card moves through the brush block, each row passes under the brushes and is detected starting with the 12 row and ending with row 9. The number of holes in each column is saved and checked against the value which is expected, due to the hole pattern that was punched. 

Each brush consists of multiple metal whiskers that drag along the top surface of the card, making contact to a conductive roller underneath whenever there is a hole punched in the card at that spot. Over time, brushes can become bent, both as a group tilting towards one of the adjacent columns, and individual whiskers can pop up and bend over to short against another brush. 

The brushes in the block were quite ratty looking, many tilting and plenty of lone whiskers askew. While it would be possible to work on each brush to get its whiskers together and bent properly, perhaps trimming the straggler whiskers, it is a very, very time consuming process. 

One of the team looked at our stock of spare parts, where we have nine brush blocks and a number of replacement brushes. He found one whose brushes looked as good as the day they rolled out of the factory. All were perpendicular, grouped together and spaced evenly from one end to the other of the block.

The block had some hardware mounted to it - a bottom rail and a side rail - that were incompatible with the punch check position, but the corresponding side rail of the ratty block could be moved over. We simply discarded the bottom rail which was superfluous. 

Then, we transferred the wiring plugs that connected 80 wires to the holders for 80 brushes, pulling them off the ratty block and pressing them in place on the replacement. That done, we were still getting punch checks because the 'timing' of the brushes was not yet set. 

Timing means that the position of the brushes in the brush block is slide frontward or readward, relative to the punched card motion, to align the brush with the point on the card where the hole should be sensed. This point is determined by a set of contacts on cams that produce 12 pulses - think of these as sampling pulses - which will record the state of the hole at that instant in time. 

The long line of brushes can slide back and forth from the two ends - at column 1 and at column 80 - thus the timing involves getting both ends at the best position possible. We set up the scope to record the sampling pulses on one trace and the brush output, having replaced the wire for a chosen column with our scope probe lead. 

We could see that our first chosen column, number 9, had the hole position too far to one side on the trace, so that the sampling pulse arrived just as the hole we detected was ending with the brush riding past it. This was true for both the 12 row and 9 row holes since we were punching the letter A in that spot, which is encoded as holes in both rows 12 and 9. 

We took the brush block out, moved the brush to read earlier in the card path, and watched again. The sampling pulse was now right at the other side of the detected hole. We had overshot the adjustment we wanted.

I took it out and split the difference, putting the brush position about halfway between the original and current spots. Now, we saw good results with the sampling pulse well within the hole sensed for both rows 12 and 9 in that column. 

To ensure that the other end of the brush block, near column 80, is also in a good position, we replaced the wire on column 9 and moved our scope probe over to watch column 76. This side was off a bit in timing, but we could swing just that end of the brush block a bit until we were happy with the pulses on this side too.

Restoring the wires to column 76 and shutting off the scope, we then ran a program to duplicate a deck of cards, taking each card as it is read and punching a copy on the punch side. This ran without a single punch error, so we declared victory and handed the systems over to the demonstration team in preparation for their scheduled 3PM demonstration to museum visitors. 

Another team member was working on the tape drives for the "German" system, continuing to adjust the relays that determine the duration of key intervals such as the interrecord gap or length of a tapemark. He used a special tape that ensures this is referenced against a standardized output that we try to match as closely as possible. 

This done, he mounted a regular tape reel but found that the drive would no longer even load the tape. This was a pure coincidence, with a contact on a small incandescent bulb becoming loose, that bulb used to detect the beginning of tape reflector during the loading process. He quickly found this and corrected it, giving us a full set of working tape drives on both 1401 systems. 

One of our restoration team members, Joe Preston, passed away yesterday morning after a many week battle with a bone infection caused by an antibiotic resistant bacterium. This is the second team member to pass away this year, following the death a few months ago of Ron Crane. We are planning a lunch next Wednesday to remember Joe. 

HP 1000 SYSTEM RESTORATION

7970E Tape Drive

I received my replacement circlips (retaining rings) that will allow me to remove and clean all the rollers that are a bit sluggish on the drive, I believe due to dust gumming up lubricants. I didn't have enough time to do anything else with the drive today. 

7906 Disk Drive

I did do a bit of research and printed out the schematics and board layout for the control PCB which recognizes the disk fault condition. With this I can set probes tomorrow and from that determine what specific error condition the drive believes it is detecting. 

2622A Terminal

I completed my triple checking of the wiring of my cable, then insulated and taped it up ready for the live test between the monitor and keyboard. When I switched on the terminal, I did get some characters when I pressed certain keys but definitely not the appropriate ones. 

There is something wrong in my cable wiring (or in the monitor or keyboard), but my first candidate is my understanding of the wiring of the cable. One one side of the cable, the lines are called Key Address 1 to Key Address 7, but on the other side they are labeled Key Data 0 through Key Data 6. 

If it is simply the case that one side uses origin 0 and the other uses origin 1, I should have been okay. Perhaps, however, the assignment is reversed, where Key Address 1 is Key Data 6, odd as that seems. I think I should independently power the keyboard and do some debugging of the values returned. 

Working on HP 1000 peripherals - disk, tape and terminal keyboard cables

HP 1000 SYSTEM RESTORATION

7970E

I discovered that I terminated the 9 track tape write incorrectly, in my earlier hand code. When sending data words from register A or B to the tape unit, when done, the programmer must reset the control bit of the data channel. Instead I was releasing the tape drive from the controller via a CLR command to the control channel.

I fixed my hand code and wrote the tape over again with my two words of o123456 and o050505, I would get some tape movement but then the program would sit in a loop waiting for the data channel flag to be set before outputting data words. Sometimes it hung waiting for the first, sometimes waiting for the second.

I am not sure what is going on. Until I can get this to happily write the two word record, there is no point attempting to read it back in. This may be a flaw in my understanding, a timing issue keeping up with the tape or it could be something wrong in the controller card or drive.

7906MR

The sound of my 7906 disk drive as it spins is probably an issue with the motor spindle - either the bearings themselves which are NOT user replaceable components, or if I am lucky, the ground brush and spring that rotates under the spindle.

To determine which it is, I had to turn the drive over and open the bottom of the spindle assembly. I found lots of fine gray dust inside, which appeared to be the source of the screeching sound. It could still be true that the spindle motor bearings themselves are shot, but I can hope that when I fix this issue my problems are solved.

The bottom of the spindle shaft tapers to a point, onto which a springy metal plate presses from the bottom spindle cover. This is an anti-static connection. The metal plate has grinding marks on it and there was the fine powder throughout the area.

To repair this I have to move the contact spring away from the area that ground down and test to verify the noise went away. If not, I have a main bearing issue which will be complex to resolve, involving quite a bit of disassembly and bearings which were not designed to be replaceable.

I tried a reassembly to listen to the sound while it spins up, but I now get a "Drive Fault" indicator lamp and it won't try to spin. Some diagnosis needed, obviously. I began with the drive fault indicators inside, a set of four colored LEDs that signal the approximate area of the fault.

I saw the green LED illuminated, which is an interlock fault. One of the causes is a failure of one of several power supply voltages: 5, +12, -12, and 25 among others.  There are other causes as well. My first step was to check the fuses for each of the voltages from the power supply. None were blown.

It was time to locate test points for all the voltages and verify they were present. Unfortunately, they all are good so the problem must be one of the other issues that raises the interlock condition.  To do this required the card cage to be opened and suitable probes clipped to various IC pins on the control board, in order to trace this to the condition triggering the problem.

2262 terminals

The second 2622 terminal arrived today - without a keyboard - but it seems to have an even better screen image, plus a bottom and stand. I will probably use this one, with the keyboard, keeping the original as a ready spare unless I find another keyboard somewhere.

I received the DA15 cable and the battery today. The battery will retain configuration settings in RAM on the monitor PCB, although I have to hook up the keyboard before I can change them from the default. I began wiring up the cable between keyboard and monitor.

I have pinout diagrams for both sides, but it is essential to orient correctly, so that I don't create a mirror image left to right of the proper wiring. I did some studying of both diagrams and the actual PCBs to assure myself of the correct orientation.

I soldered together the wires on one of the header sockets, then put did the same for the other socket. After a break, I went back and double checked the connections the cable made between the monitor and the keyboard. Tomorrow I will try the terminal using my new cable.

HP 1000 9 track tape drive tested, work on two terminals to make them fully usable

HP 1000 SYSTEM RESTORATION

One of the idler pulleys on the 9 track tape drive turned with quite a bit of resistance. I suspected thsi was due to embedded dust, so I removed it. After I cleaned it well, I reassembled the pulley onto the 7970E drive and it worked better. 

I then wrote some machine language to write a two word record onto a new tape, and another set of code to read the record back and verify correct operation of the 9 track drive. My first attempt failed until I noticed I had left the 'write ring' out of the tape. With this missing, a tape drive will refuse any write operations, as did mine.

With the ring in place, I saw the tape move forward away from the load point as I did the write operation. I will need to read it back in and compare the data words to be certain that I did it correctly and that all the control and data channel operations worked properly.

The tape drive controller consists of two cards, a control channel and a data channel. All I/O on the HP minis is accomplished with a simple interface. A control bit can be set or cleared, a flag bit can be checked or cleared, and a word can be transferred to or from register A or B and the IO device. 

The control channel is sent a word that is a command, such as forward space or write record, then the control bit is set to ask it to execute the command. Transferring a word back from the channel to a register gives a status word that reflects various conditions. The flag bit is set when the command is complete. 

I sent a command word to select the tape unit 0, followed by a command word to write a record and set the control bit. The drive begins moving and the other card, the data channel, takes over. Normally the direct memory access controller takes over and handles the movement, but I used the standard method that works for all device types.

The data channel sets the status flag bit when it is ready for a data word to write out to the tape. Thus, one loops waiting for the flag to be set, then outputs a word from a register to the data channel. I did this twice, to transfer my two words of o123456 and o050505 to write on the tape.

To terminate the record being written, I sent a command to the control channel and set the control bit. The tape motion stopped and an interrecord gap was produced on the media. In a more realistic setting, there would be further records written to the tape by repeating the sequence of commands to control and data channels, followed by sending a command to write a tape mark which is an end of file indicator. I only needed one record to accomplish my initial test of the drive.

I manually rewound the tape to load point, in preparation for doing a read and comparing the words I received. My code didn't work properly on the first attempt, but I soon cleared up the error and tried again. The tape begin moving but my program stayed in a loop waiting for the second word to arrive, while the tape continued merrily along. 

Worse, when I halted the program, the first word I tried to read was in the register as o000000 not the value o123456 that I thought I wrote. Not a successful test session for the tape drive, but it does tell me quite a bit is working properly:

• Read and Write commands work
• The transport moves tape
• Write enable/disable works
• The control channel provides status words
• The data channel sets flags for data transfer requirements

My 2622 terminal has a keyboard, missing its bottom plastic cover and missing the cable that connects it to the terminal monitor, itself missing a bottom cover. I therefore have a few tasks to accomplish before I can use this terminal - build bottom covers for the monitor and keyboard, plus make a cable. 

To build keyboard cable for terminal I had to determine the type of connectors and the wiring between the two ends. Fortunately I found schematics and could examine both terminal and keyboard. 

The connector type on the terminal for the cable from the keyboard is a normal DA-15 type (misnamed DB-15 by most people), with two rows of 8 and 7 pins. The keyboard has .100 inch header pins in two rows, each of six pins. I ordered a cable from Amazon, to cut up and wire to twin headers for the keyboard end. 

My 2645A terminal contains two mini tape cartridge drives, which used a single track system developed by 3M. It is a narrower tape than DC-2000 or QIC drives, but similar physically. The capstan rubber has decayed. 

I removed both tape drives to begin the refurbishment. It appears that the capstan diameter should be very close to or slightly larger than 9/32". I measured the decayed rubber on a drive then worked through the specs and design of the drive to figure out the capstan size as a cross check.

The drive will move tape in both slow (read/write) and high speeds. High is 60 inch per second movement of the tape. The design of the cartridge has a drive ratio of 0.78, thus the tape moves .78 inches for every 1 inch of drive capstan movement. That required the capstan to rotate to move about 77 inches per second.

The motor has a nominal speed of 5000 rpm wide open with 6V DC drive. The circumference of a 9/32" capstan is about .8836 inches, thus at 5000 RPM ( RPS) it would move about 74 inches. This is why I suspect the capstan needs to be slightly larger than 9/32" but less than 5/16", to achieve the 77 inches of movement per second for high speed motion. 

The internal structure of the cartridge has an elastic belt in a short loop that is driven by the capstan. The elastic belt is wrapped around the two tape reels and moves the mylar tape material. The elastic belts are all decaying, just like the capstan rubber, so that even brand new cartridges found in the box are no longer usable.

This poses a bigger issue for restorers. There are a few ways this can be addressed:

• Find a new elastic material and rebuild the cartridges
• Switch to a remanufactured cartridge from Athana
• Alter the drive to use DC-2000 cartridges which are not similarly afflicted
• Move to a solid state tape replacement, e.g. SD-card instead of tape

The Athana cartridges fit an unaltered drive mechanism, once the rubber on the capstan is replaced, but the new tape oxide formulation they use requires a slight modification of the read/write electronics to change tape bias. This mod is a single resistor swapout. The downside is a price of roughly $50 per tape cartridge for blank media. I will try this approach.

Using DC-2000 tapes has a much lower media price, but it requires some cutting of the bezel of the terminal and change to the mechanism itself, thus less optimal. Rebuilding cartridges myself is a possibility but seems to involve the fiddly and tedious work I dislike. The solid state version is a significant amount of design and build work. Thus, Athana cartridges is my preferred solution.