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.
No comments:
Post a Comment