Tuesday, October 17, 2017

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


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


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.

Sunday, October 15, 2017

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


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.

Saturday, October 14, 2017

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


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, October 13, 2017

Friday session at Marc's involving several machines


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. 


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.


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. 


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. 


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. 


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

Thursday, October 12, 2017

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. 


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.

Wednesday, October 11, 2017

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


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. 


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.