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. 

Tuesday, October 10, 2017

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



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.


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.

Monday, October 9, 2017

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


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. 

Friday, October 6, 2017

HP 1000 terminal (2645A) working, Alto work accomplished


2645A terminal

I brought the 2645A terminal and keyboard to Marc's house, along with the box of spare boards, with the aim of putting together a logically consistent system then diagnosing any problems until it worked. Fortunately, Marc has eight 264x terminals of various flavors and some spare parts.
The 2645A, boards shown on left side of the ad
Using the documentation, cross checking it against the combinations found in Marc's terminals, I came up with the set of boards that should give me a useful working terminal. First, I installed the Keyboard Interface card and the Extended Serial Communications card which hooks this to the HP 1000 controller and the keyboard. 

Next, I set up the display group - the display control, display memory adapter, display timing, and display enhancement boards - were installed side by side with a top side connector tying the four together. The enhancement board had the multiple character sets available for the terminal, such as greek/math and graphic shapes. 

Adjacent to the display group, I installed a processor group - the 8080A processor board and a 32K Control ROM board, with a top side connector tying the two together. To the right of the processor I stuck in a universal RAM board with 16KB configured. 

Since the terminal had dual cartridge tape drives installed, I had to put in the tape controller board and the tape read/write board. The rubber capstan has turned to goo, so that must be replaced before I can think about putting cartridges into them. 

Marc has quite a bit of experience with these and recommends a mod to the write logic to allow use of a much more reliable alternate tape cartridge from Athana. The only downside is that the blank cartridges are pretty expensive - $50 each - but they appear to work very reliably. With the tape cartridges I can boot the HP 1000 from the reader in the terminal. 

When I powered up the terminal, I got garbage on the screen and/or strident error beeping.  I did diagnostic work as well as swapping boards known to work from other terminals, until I had identified the Universal Ram Board (60171) as the culprit. I had two of them, one 16K and one 32K, but neither worked properly.

Marc had a 16K 60171 which worked well, plus it was a good template for setting the 16 dip switches (called "strapping" by HP) to make it work properly in the system. 

While I could have begun testing the individual 16K RAM chips on the boards, Marc had a pile of spare RAM chips of the right type on hand. We just populated my board with eight 16K chips (making it a 16KB board), plugged it in, and everything worked perfectly.

The terminal is now back in my workshop ready to connect to the HP 1000. Once we figure out the replacement method for the capstan rubber, I can apply that to my two drives and make the slight mod to the R/W board to work with the Athana tape cartridges. 

2262D terminal

I had tested the monitor unit of the terminal previously and it appears to be working fine. It sails through its power on test, but a more comprehensive self-test must wait for a keyboard to be attached. My keyboard is missing the plastic bottom and the cable that connects it to the monitor. The monitor itself is missing its pedestal and base. 

I will build a wood stand for the monitor and a bottom for the keyboard, but first I need to build a cable. I did find schematics on bitsavers and know the pin-out for the connection on the keyboard side. Since I also know the pinout for the monitor side, the cable will be easy to fabricate. 


Diablo drive filter foam replacement

The air supply in the Diablo comes from a blower and goes through a HEPA filter, then is routed into the disk cartridge by a foam seal that fits around the metal flap door on the cartridge. The foam, however, has deteriorated to a partially friable, partially gooey mess. 

I removed the old foam and cleaned the area, before cutting and gluing on some soft rubber weatherstrip material. It fits well and won't introduce and particles in the clean air stream. 
That drive is now ready to begin archiving the remaining cartridges from the Xerox PARC archives. 

Ethernet connection box

Ken was chasing a troubling bug in the file transfer process in his ethernet connection box. This unit hooks directly to the Alto unit connector, thus not requiring the Ethernet Adapter Unit or 3 Mbit ethernet cabline. It makes use of the IFS code developed by Living Computers Museum + Lab
but is implemented on a BeagleBone.

The network box loaned by the LCM has to go back to CHM where it is needed for their Alto work, thus we have a deadline to complete the connection box. Marc will build a nice enclosure once the functionality is completely tested and solid.

Ken used today to track down the flaw, which he discovered by the afternoon and soon had a fix that allowed the box to completely support the FTP activity. He has some more testing and improvements to accomplish but is well on the way to our end of the month target. 

Thursday, October 5, 2017

HP 1000 updated to 7970E drive, work on new terminals


As expected, I had a burned out light bulb in the Reset button, as well as one in the begin/end of tape (BOT/EOT) sensor. Replacements ordered but temporarily swapped a bulb from the working Unit 3 button to the Reset position. I also hooked in a 5V mini bulb I had from the IBM 1130 project, temporarily, to restore the BOT/EOT sensor to operation.

I still have the fault where the Load button engages the relay but does not attempt to tension the tapes. There are a number of components involved in this, beginning with a chain of four microswitches that detect the limit of travel of the two tension arms. 

Unexpectedly, however, Al Kossow gave me a 7970E drive (the 1600 BPI type that matches my controller cards) and I spent a good hour wrestling the very heavy B drive out of the rack and replacing it with the equally heavy E drive. Each drive weights 130 pounds and is a cumbersome 24x19x16 in size.
System with 7970E tape drive in place
The transport portion of the new drive is working well, although the rollers over which tape will pass are sticky with hardened lubricants and therefore barely rolling. This makes the tape motion sluggish but once I deal with that, I can test the remaining portions of the control circuitry for read and write. Using the fwd and rev CE switches on the back proved out most of the motion control logic.

Al also gave me plenty of parts to complete a 2645A and a 2622A terminal, with keyboards. These will fit the two serial IO cards installed in the processor cage and give me the last of the items I would need to have a running RTE on the system.

HP 2645A terminal

Terminal keyboard

Box full of terminal parts
The tape rollers were first up on the repair list, then having received more kimwipes and 99% isopropyl alcohol, I could clean up the 7906 disk drive heads and platters. I had quite a bit of trouble getting the circlip back on the first roller that I freed up, enough that I decided to wait until I was fresh to try again.

I cleaned the disk platters, which looked great, but I had difficulty trying to clean the edge of the heads with Kimwipes alone. I will have to come up with a safe support for the wipe allowing me to gently rub the head to clean it. The flextip foam swabs that should work for this purpose will arrive Sunday.

I assembled the motherboard onto the 2622A terminal and powered it up. It has a great crisp display, only a small amount of burn-in along the bottom, and seemed to pass its self test okay. I will have to make up a cable between the keyboard, which was missing the bottom casing and cable, and the rear of the terminal. The keyboard itself looks okay, it is just a matter of building a cable.

I am currently inventorying and studying the 2645A terminal to understand what other boards must be installed and any configuration settings I must make on the cards. It does appear I have a sufficient set of boards to complete the terminal, but there are so many permutations and configuration settings that this is far from clear. 

Wednesday, October 4, 2017

HP 1000 system restoration - memory now working, moving on to tape drive


Today was Wednesday, when I spend much of the day at CHM working with the 1401 restoration team. We have a tape problem on one drive on the "German" system, where certain sequences of tape operations result in the drive spewing data throughout memory, overwriting any programs.

Last week it manifested by the tape running away continuously after the system Stop button was pushed. We set up the scope to watch the signal that should tell the tape adapter unit to disconnect and halt tape operation, but that prior runaway problem had ceased and the overwriting behavior manifested. We didn't get to the bottom of it this week. The other ("Connecticut") machine ran fine.

Once home I wired and inserted the rack power switch back into the HP 1000 cabinet and it worked just fine. The bulb inside that should illuminate is burned out, but I have a replacement on the way.

I then began pulling out the four memory boards, each implementing 64K words of high speed parity protected memory. First up I validated that the DIP switches on the boards had configured them for their proper address range. I then inserted just the lowest 64K board and tested the system to see if the alternating all-one-bit and all-zero-bit words would appear.

The system worked properly. I inserted the second board and tested again. All was good. Third board, same thing. Although the logical conclusion is that the fourth memory board is bad, I inserted it anyway and ran the tests. The problem went away! I have to assume that I had erratic contact of a board with the memory backplane and/or the front ribbon cable that bridges them to the memory controller.

In any case, with memory working right, I looked at the initial boot load sequence to verify that operation as far as possible without an actual working peripheral on the end with code to read. I set up the sequence to boot from my 7906 disk drive, using the controller card in socket o13.

In fact, I identified and verified all four ROM loader contents - doing an IBL with the slot number in bits 15 and 14 of the S register and the octal slot number of the controller card in the IO cage. I then stepped through locations o077700 to o077777.

Now, the error light (Overflow) didn't light up, meaning it set up the boot ROM in the upper words of accessible memory, checked that the controller card was live, and prepared to actually boot once the drive was ready.

Of course, the drive isn't ready, but I hit RUN anyway and saw the loader attempt to read from the drive. Later I will look at a listing of the ROM chip in socket 11 which is how I attempted the IBL, verifying that the contents are correct by stepping through the memory addresses.

I turned to my 7970B tape drive to restore it to operating condition. Yesterday, it initially did load and rewind but failed to spot the reflective beginning of tape (BOT) foil as it passed. Later yesterday, I heard a very faint sound and now the drive won't load, rewind or respond to the four top buttons at all.

I checked the fuses in the drive and found all of them good. Next up I should verify that all the power supply voltages are present, since that is the most likely cause of the failure to respond. If I can fix that then I can return to debug the failing BOT sensor.

The power levels were just fine, +5, +12, -12, +20, -20, +57 and -57, thus I have to look at the logic itself to see what is going wrong. I printed out the appropriate schematics and board layouts to begin probing.

One failure candidate signal I found right away is called "Control delay" which is a timer that should hold the control logic in reset for a brief period while power comes up. If that fails, I would have the symptoms I am seeing.

Alas, it isn't delaying anything, it has dropped to ground. I also hear the relay K1 click on and off when the Load button is pressed. This should trigger the reel motors to tension the tape then roll forward until the BOT spot is sensed.

Still, the lamp in the Reset button should light. I suspect that bulb is out, as is the bulb in the BOT/EOT sensor area. I ordered bulbs and will make sure I have all good bulbs in the unit. 

Tuesday, October 3, 2017

Continuing working on HP 1000 system restoration, starting on disk and tape


I opened and looked over my 7906M disk drive. This drive has a single platter removable cartridge plus a fixed platter underneath. The multiple heads share one access arm. The drive itself looks very clean except for the crumbling foam of the pre-filter. 

Front of 7906 drive, cartridge inserted and control panel visible below

Underside of 7906, nice condition
After I remove and replace the pre-filter, I have to verify the cleanliness of the air seals for connections that are between the HEPA filter and the plenum and cartridge. On similar drives, there is a foam filter as a seal which is known to deteriorate. 

The heads look fine, albeit with a small amount of oxide smudging that is typical for a drive after some hours of use. The heads need some cleaning. I will carefully inspect and clean the platter in the removable cartridge and the fixed platter if I can reach it. This will take a few days.

The HP drive does not use a seal at the cartridge air flap so this problem is not an issue for the 7906. Once I finish the inspection and cleaning of platters and heads, I am ready to fire this up and test out its loading behavior.

Air door on bottom of disk cartridge

Mechanism that pushes up the air door but does not use a foam seal
I looked into the main rack power switch that was sticking in the off position. It appears that a grease was used which hardened a bit with age. I cleaned it out and applied some alcohol to help with the main barrel sliding in and out of the switch. It now works great, just waiting to be reinstalled tomorrow.
Disassembled switch before cleaning up solidified grease
Toggling in instructions helps me learn the machine architecture and prove out the functioning of the system at the same time. I have spotted an anomaly where something is overwriting memory with an alternating pattern of all-one words and all-zero words - this doesn't happen constantly but often enough to wipe out my hand entered code. 

The direct memory access functionality provided by the DCPC card, which allows selected peripherals to read and write to memory autonomously, might be the agent doing this writing. I decided to pull the disk and tape controller cards and see if that resolved the issue. No change.

Definitely flaky  behavior of some kind. I will be checking the memory and other card configuration settings, then yanking cards or disabling functions until the bad behavior goes away. The one definite problem with the system.

I worked a bit on the 7970B tape drive, which is a 9 track 800 BPI 45 inch per second unit. My controller cards are for the 1600 BPI model I don't own, so I can't do reads or writes until I sort that out, but I can get the mechanism and offline behavior working correctly.

Mag tape has a metallized reflective spot glued on that identifies the 'load point'. The drive will forward through the tape slowly until it sees the reflective spot. However, my drive didn't see it at all. I hit rewind to see the tape move the tape back to the supply reel at higher speed. That too will only stop if the reflective spot is detected.

Tape threaded on 7970B tape drive

Mechanism of the drive
Time to do some basic troubleshooting on the drive, first repairing the reflective spot detection and then moving on to its other behaviors. Tomorrow I will dig into this.