Tuesday, December 12, 2017

Detailed diagnostic work on failing 1401 memory, not yet repaired


I went into the museum today to try to diagnose the memory problem afflicting the Connecticut 1401 system. The first 4000 words (the base core stack) is not working properly. No matter what pattern you attempt to write into that portion of memory, you get back all zeroes which triggers a parity error (Check error in IBM speak).

The memory stack consists of multiple planes of cores. Each plane has 4,000 locations each with a tiny circular core supported by wires through its center. Straight wires running in the X and Y directions are the primary support and are used to address an individual core by sending a current through one X and one Y wire simultaneously.

In addition to the straight X and Y wires, long wires are snaked through every core in the plane. A sense wire will detect if any core in the plane flips from one magnetic orientation to another, as that change of the magnetic field around the core induces a small pulse of current in the sense wire.

Each location in a 1401 consists of a character - binary coded decimal - constructed of the 1, 2, 4, 8, A and B bits. Another bit called the wordmark is used to delineate the end of variable length fields in the machine. Finally, the C or check bit is used to enforce odd parity for the word as a way of detecting errors in memory.

When a current runs down one of the X or Y wires, it is insufficient by itself to change the magnetization of the cores it runs through. However, the combination of the current from both an X and a Y wire is enough to flip the magnetic orientation. Thus, the current running down one X and one Y wire will not affect any core on either wire except for the one that is supported by both.

When the current through the X and Y wires runs in one direction, the core it addresses is flipped so that the magnetic orientation is considered a binary 1 value. If the current through X and Y flows the other way, the core will flip to the opposite orientation which is considered binary 0.

There is no way to detect which way a core is magnetized in this scheme except to deliberately flip it to a known state. The sense wire will see a pulse if the core was previously in the opposite orientation, otherwise not. Therefore core memory uses a destructive readout method. The core is flipped to binary 0 and the sense wire detects if its prior state was 0 or 1.

We don't want a memory that can only be read a given addressed core one time, so the destructive read is followed immediately by a write cycle to restore the state of the core. Sending current through X and Y to set the core to 1 will restore its value, but if the core is supposed to hold a 0, then we don't want to flip it on with our current.

Enter the inhibit wire snaking through all the cores in a plane. If a current is applied to the inhibit wire in the reverse direction of the current flowing through the X and Y wires, then the sum of the currents is reduced below the threshold that will flip the bit to 1. We inhibit any core that we want to be a 0 after the write cycle, otherwise the write cycle flips them to 1.

The heart of the machine is a cycle determined by magnetic core speed. In the 1401, it is a 10.5 microsecond interval, where the cores are all flipped to 0 at the beginning of the cycle, the sense wires are used to set a register with the prior state of the core, then the second half of the interval is used to write the cores to 1 with the register controlling the inhibit wire.

To get the symptoms we are experiencing, all 4000 core locations of all 8 planes must either be written to 0 because the inhibit wire is active or get sensed as 0. This would need to be a single point failure to cause the problem - for example it can't be the X and Y driver cards as there are one per plane, routed through a switch that determines which X or Y wire the current passes through.

Similarly it can't be a sense amplifier failure or bad inhibit drivers as there are one per plane for these also. What is common to all planes that could cause the entire stack to fail? We had to search for the cause.

We checked that all power supply levels were correct. We checked activation signals that cause the drive current to flow for a particular stack, 2000 character half of a stack, X and Y address. We tested the output of sense amplifiers; they were indeed 0. We did determine that the inhibit drivers were off for the bit that should be written to 1.

We tested one side of the driving current - the switched 8 x 10 array to select one of 80 parallel lines in each plane. We did see the current flowing in general but didn't look at the individual wire to see that it was different from the other 79.

We still need to check the other side - a switched 5 x 10 array that selects one of 50 parallel lines in each plane, these at right angles to the original 80 lines. Together these select the individual core in each plane which is the coincidence of one of the 80 lines and one of the 50 lines. We also need to verify that the direction is correct for X and Y lines.

The testing ran for many hours Monday, including a side by side comparison of the same signals on the correctly working German and the failing Connecticut 1401s. No differences were found so far and no anomalies. We will continue this on Wednesday.

Sunday, December 10, 2017

Put the new disk image through its paces on the HP 1000 - real machine quite slow


Working with RTE IV B

The disk images run under the simulator have the bytes of their words swapped compared to the ordering in disk images on real HP hardware. The PC uses little-endian words while HP is big-endian. I ran the DD utility to swap the bytes back, creating a new disk image to run on my physical hardware.

All is not well. My image booted up but the system prompt showed up on the 2622A terminal, not the 2645A that it should. Perhaps I have the cables backwards - I will investigate. Even so, the system came up and I issued some commands to check out its functioning.

Time to compile and run my Algol test program. I have a procedure to handle the Algol compiler, which is an older bit of software that does not work properly when handed names of files. Instead, it needs to have the source set up as a logical unit and the output produced on a temporary disk area which can then be saved as a file.

It all ran well. I put the system through some paces, running various compilers and programs. The one thing that wasn't working right was the second console, the 2622A, but I think I pulled wires off the connector as I moved the cables to put the 2645A as the system console and the 2622A as the secondary.

Diagnosing bad 12966A BACI card

Preparing to use the logic analyzer to spot the problems with the serial card is complicated by space and power cabling concerns. Where I have the HP machine in my garage, the rear of the rack enclosure where I will access the IO cards is near the main garage door, leaving little room for access.

I have no space for a table to sit the logic analyzer, and the PC hosting the HP Drive emulator is sitting on top of the rack taking up what little space there was. Further, I don't have a power strip nearby with enough open sockets to handle the logic analyzer, PC and its monitor.

Once I sort out these logistics, which are the pesky issues remaining, I will still have to program the logic analyzer and locate a source for the system clock I will need to run the analyzer in clocked mode. 

Saturday, December 9, 2017

More RTE IVB exploration and refinement, PASCAL made operational


Working with RTE IV B

I set up the BASIC interpreter on my system and configured it to be readied at startup. I feel that I have finally mastered the concepts behind programs and how they are stored and accessed in RTE, thanks in part to excellent explanations from Dave Bryan. 

When the BASIC system is generated, the LOADR program links together the relocatable code and any routines from libraries, producing the programs BASIC, BASC1, BASC2, BASC3, BASC4, BASC5, BASC6, BASC7, and BASC8. 

The numbered programs are overlays that are fetched as a means of dealing with a limited memory size. The program is segmented so that after one logical set of code is complete, the next segment is loaded and executed.

The LOADR has placed the code for those 9 programs in temporary space on a disk cartridge and built an ID segment in memory that defines the program and points to the disk based code. These ID segments are by default temporary, meaning they and the reserved disk space go away when the system is rebooted.

If a RUN command is issued for BASIC after loading, it finds the name BASIC in the temporary ID segments and executes it. Any call for an overlay will find that name in the temporary segments and cause it to be run. After a reboot, with no temporary ID segments, the attempt to run BASIC will result in a No File Found type of error.

A command :SP will store the code from a temporary ID segment into a permanent named disk file of type 6. If this is done for all nine program names, then BASIC and its segments are kept permanently over reboots.

However, a type 6 file is not kept in the ID segments, thus after a reboot the RUN command won't find the name BASIC. It has been written so that if it searches the ID segments and a name is not there, it then looks for a type 6 file of the same name. The type 6 file is read to create a temporary ID segment which does point at the code in the type 6 file. 

Thus, RU,BASIC after a reboot will appear to run BASIC the same way it does after the initial generation with LOADR. However, it is only the name BASIC which is copied into a temporary ID segment. When the program tries to load and run one of its eight overlays, the name is NOT found in the temporary ID segments and a failure occurs. This in spite of the fact that the names are in type 6 files. 

Thus, for programs with overlays, such as BASIC, FTN4 and ASMB, the type 6 files for their overlays are not enough and a temporary ID segment must be created. A command :RP will find a type 6 file and create a temporary ID segment, the perfect solution. 

If you do an :RP for every overlay segment after a reboot, the temporary ID segments are set up. When the main program is executed with RU,BASIC, the main code is also put in the temporary ID table and every overlay is waiting in the table for when it is needed.

The convention for handling this is to make a file of the :RP commands, name it the same as the main program but with a forward slash (/) prefix. The /BASIC file is executed as part of the startup WELCOM file, recreates all the temporary entries for the BASIC system, and now it will run properly if called with RU,BASIC.

In addition to the temporary ID segments, during system generation of RTE IVB, the administrator can load programs into the ID segments as permanent files. Those use some space on the disk cartridge which is not associated with any file name, but is pointed to by the ID segment. 

In addition to these disk based permanent programs, whose name is not visible in any directory list but which will execute with a RUN command, the administrator can load some programs permanently in memory. The code takes no space on disk at all (other than as part of the system to be loaded at bootup), does not show up in any directory listing, but will be executed by RUN

Just to round out the situation, I should mention that when creating a program with the LOADR, an option can be entered to make it permanent. This sticks the produced code in one or more tracks on the disk cartridge, without a name in the directory, then makes a permanent ID segment which persists across boots.

This was confusing at first, when I could issue RUN commands for program names which did not show up in any directory. Further, you can see some programs stored as type 6 files, but if the overlay segments were not set up by :RP then the program would fail to run properly. 

Now, however I grasp how it works. I can look at the ID segments through a special LOADR option - thanks to Dave Bryan for the tip about this. Below is the output of that on my system;

  PRMPT  1     1 26000 26532     4    11                          NC      
  D.RTR  1     1 26532 46655    11   257                          NC      
  R$PN$  2     1 24000 24760     2    14   2                  PE  NC     0
  LGTAT  2    10 24000 26272     2    55   3                  PE  NC     0
  T5IDM  2    10 24000 35450     2   220   6                  PE  NC     0
  WHZAT  2     2 24000 30605     2   150   4                  PE  NC     0
  ,,,,,  3    99 24000 30136     2   226   4                  PE  NC     0
  FMGR   3    99 24000 32367     2   112  14                  PE  NC     0
  HELP   3    99 24000 32576     2   103   5                  PE  NC     0
  LUPRN  3    99 24000 51500     2   422  12                  PE  NC     0
  LOADR  4    99 10000 41062     2  1274  28                  PE  NC     0
  EDIT   4    51 10000 30722     2   604  28                  PE  NC     0
  RT4GN  4    90 10000 32351     2   473  28                  TE  NC     0
  FMG01  3    99 24000 32367     2   112  14                  TE  NC     0
  ALGOL  3    99 24000 37530     2   466  15                  PE  NC     0
  FMG10  3    99 24000 32367     2   112  14                  TE  NC     0
  TG00S  5       24401 26543   265   335                      TE          
  TG01S  5       24401 26201   265   333                      TE          
  TG02S  5       24401 26124   265   322                      TE          
  FMGR0  5       32367 44036   112   377                      PE          
  FMGR1  5       32367 45035   112   513                      PE          
  FMGR2  5       32367 45504   112   630                      PE          
  FMGR3  5       32367 43553   112   322                      PE          
  FMGR4  5       32367 42744   112   426                      PE          
  FMGR5  5       32367 36217   112   255                      PE          
  FMGR6  5       32367 44600   112   510                      PE          
  FMGR7  5       32367 43611   112   277                      PE          
  FMGR8  5       32367 43477   112   365                      PE          
  FMGR9  5       32367 43477   112   274                      PE          
  FMGRA  5       32367 44604   112   404                      PE          
  FMGRB  5       32367 45046   112   424                      PE          
  EDIT0  5       31324 52607   604  1234                      PE          
  EDIT1  5       30722 50141   604  1115                      PE          
  EDIT2  5       33111 44043   604  1046                      PE          
  EDIT3  5       30722 36572   604   760                      PE          
  EDIT4  5       30722 40617   604  1113                      PE          
  ALGL1  5       37530 40174   466   471                      PE          
  F4.0   5       27356 33326   574   754                      TE          
  F4.1   5       27356 34150   574   755                      TE          
  F4.2   5       27356 30355   574   632                      TE          
  F4.3   5       27356 31645   574   715                      TE          
  F4.4   5       27356 34270   574   766                      TE          
  F4.5   5       27356 33254   574   734                      TE          
  ASMB0  5       24425 32310   437   571                      TE          
  ASMB1  5       24425 26663   437   571                      TE          
  ASMB2  5       24425 26555   437   537                      TE          
  ASMB3  5       24425 25352   437   454                      TE          
  ASMB4  5       24425 25755   437   454                      TE          
  RT4G1  5       33200 34547   473   570                      TE          
  RT4G2  5       33200 36700   473   733                      TE          
  RT4G3  5       33200 37143   473  1052                      TE          
  RT4G4  5       33200 36301   473   751                      TE          
  RT4G5  5       33200 36576   473   753                      TE          
  RT4G6  5       33200 36326   473   734                      TE          
  RT4G7  5       33200 36334   473   612                      TE          
  RT4G8  5       33200 34045   473   541                      TE          
  SWSG1  5       41542 42647   547   612                      TE          
  SWSG2  5       41542 47313   547   675                      TE          
  BASC1  5       15634 21524   211   462                      TE          
  BASC2  5       15625 26003   211   433                      TE          
  BASC3  5       15635 22215   211   503                      TE          
  BASC4  5       15626 30427   211  1007                      TE          
  BASC5  5       15644 26347   211   567                      TE          
  BASC6  5       15644 23515   211   503                      TE          
  BASC7  5       15646 23105   211   455                      TE          
  BASC8  5       15625 21352   211   424                      TE          
      17 FREE LONG IDS,      0 FREE SHORT IDS,    10 FREE ID EXTS 

The in memory entries are at the top, then the disk based ones are listed with either PE for permanent or TE for temporary. The TE entries were made by the /xxxxx files that issued :RP commands or by RUN,xxxx that copied from the type 6 files, while the PE entries were either loaded with the PE option or created during system generation.

The LGTAT utility program will identify disk space used both for permanent and temporary code that exists without a file name in the directory. Only the system (and optional auxiliary) cartridge can hold the system and the non-file disk based programs. Below is the output of that program on my system.

TRACK     0      1      2      3      4      5      6      7      8      9    
  70    ALGOL&   --     --     --     --     --     --     --     --     --   
  80      --     --     --     --     --     --     --     --     --     --   
  90      --     --     --     --     --     --     --     --     --   T5IDM^ 
 100     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 110     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 120     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 130     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 140     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 150     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 160     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 170     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 180     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 190     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 200     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 210     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 220     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 230     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 240     FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP    FMP   
 250     FMP    FMP    FMP    FMP   D.RTR       

We can see from the listing above that I have a few permanent programs on the disk:

  • EDIT and its segments (different from EDITR which is a type 6 file)
  • D.RTR
  • T5IDM
  • FMGR and its segments
  • R$PN$
  • HELP

These persist from boot to boot. Some memory resident programs exist but won't be seen on the disk, for example PRMPT which issues the prompt to any online terminal and schedules the disk resident program R$PN$ to process the commands. There are no temporary programs on disk in this view, 
but after I loaded the KEYS program with the LOADR, this is the relevant snippet of the LGTAT listing.

  70    ALGOL& KEYS & KEYS &   --     --     --     --     --     --     --   
  80      --     --     --     --     --     --     --     --     --     --   
  90      --     --     --     --     --     --     --     --     --   T5IDM^ 

We can see that KEYS is loaded here and also has a temporary ID segment allocated to it. If I were to issue a RUN,KEYS it would be executed, but a DL,KEYS won't show any file named KEYS in the directories of any online cartridge. 



The command :OFF,KEYS releases the temporary ID segment and also freed up the disk tracks holding the program. Having previously issued a :SP,KEYS command, I first had copied the code to a type 6 file named KEYS. Now, issuing RU,KEYS will first check the ID segments, then find the type 6 file and create the ID segment before running the program again.

I then turned to installing the PASCAL compiler and runtime system. It would be the last of the languages and utilities I needed on my system. Unfortunately for me, I ran into a snag. One of the three parts of PASCAL to be generated (the PCLF loader file) takes up so many entries as it builds the temporary code that I run out of segment ID entries in the system.

I may have a temporary solution, however. I would need to blow away some of the temporary programs in the non directory area, then do the LOADR of PCLF, then get back those programs. I create many ID entries by running the /progname files from WELCOM, to convert type 6 files into temporary entries.

Since I only need to run the LOADR and FMGR to accomplish the generation of the PCLF program entries, I can strip out all the other temporary files manually. FTN4 or other programs that depend on this will no longer run until I reboot or rerun the :RP commands, but I won't need them until I reboot.

All that done, I reran the LOADR to generate from the PCLF file. Now, with enough ID segment space, I ran out of disk space. That is, the 28 tracks available on the system cartridge aren't large enough for all the code that will be stored temporarily during the LOADR session. 

The solution is to blow away my system cartridge 002 and rebuild it with the directory located at a higher track number, leaving more temporary space. At first I thought I would have to recreate pretty much every program if I did that, a task not worth contemplating as it would be a many many hours of work.

Instead, I discovered that the :IN command could reinitialize the director in a new space, leaving all the contents below the directory untouched. What I did to accomplish this was:

  1. Copy all files on 00002 to the SC cartridge using :CO command
  2. Remove all the temporary ID entries pointing to the disk using :OFF commands
  3. Reinitialize with :IN,mpw,-2,00002,SYSTEM,150,2 where mpw was my master PW
  4. Copy all files from the SC cartridge to the new empty 00002 cart using :CO
I then reran the PASCAL step PCLF to generate the many segments of PASCAL, now that I had plenty of scratch space and lots of unused ID segments. Once it was complete, I converted all the entries it had created as temp ID segments into type 6 files, wrote a /PASCAL file to issue :RP for all overlays, and killed off the superfluous temp segments with :OFF commands.

I tested PASCAL, which worked fine, then modified my WELCOM file to run /PASCAL and rebooted as a final check. The compiler works fine. I entered a test program and ran it successfully as well. The last test was to update the WELCOM file and reboot. 

ARRGH. So close. I forgot to save one of the 20 segments of PCL as a type 6 file, therefore after the reboot I no longer had a working PASCAL environment. I shall have to go through the entire regeneration of the PCLF portion again, save just that one file, and then I will be back in business.

Another thing I learned is that PASCAL can't be loaded (via a startup file with :RP statements) because the 20 segments on top of everything else in the system will exhaust the pool of ID segments. Instead, I have to run a file to unload BASIC segments and load PASCAL in order to use it, then reverse out the PASCAL after I am done. 

The longer term solution would be to generate many more ID segments into the RTE system. I will put that on hold for a later system generation effort. 

Friday, December 8, 2017

Disk prep for alignment, plus progress on RTE, terminals, and ethernet devices


Ken's Alto Ethernet device

Ken discovered that his Ethernet device does not work properly when he uses long ethernet cables. He checked the signals on the scope and saw a couple of problems with the signals he produced when the arrived on chip inside the Alto. 

First, the low level voltage was lifted above ground a noticeable amount. Second the transitions had some obvious distortions that had the characteristics of a improperly terminated transmission line. After some experimentation, a resistor was added on the device side that cleaned up the signals.

With that change any length of ethernet cable could be used with the device. Next up is testing over the coming week of the ability to link up Altos over the Internet, joining machines at LCM in Seattle and one in Connecticut. 

HP 264x terminal character sets

In prior sessions we worked on the optional character sets such as Math symbols or Line Drawing, which for most of the terminals require ROMs on an added board, the Display Enhancement PCA. However, a few terminals come with all of these standard. 

We accomplished two things. First, we located the ROMs on the main boards which support the Roman character set which is the basic standard set on all terminals. Second, we located the ROM on the newer terminals which have all the sets included. 

The basic characters are implemented on two 1K x 8 ROMs, providing a full 128 characters, upper and lower case. The newer inclusive ROM is a single 8K x 8 device hosting the basic, Math, Large Character and Line Drawing sets, plus several diagnostic image sets. We identified a compatible ROM for the large one, the Harris 76641, and the other ROMs are Harris 7681 or equivalents.

Diablo disk drive head alignment

We spun up the repaired alignment cartridges, with the heads installed in the drive and the head loading solenoid reattached. The heads and solenoid were out while we spun the repaired packs, making sure that any residual tapping oil was gone. 

Right after the repair, the oil would streak out from the hub under centrifugal force and migrate out towards the edges of the platter. That would cause head crashes, so we cycled the packs through long intervals of rotation and thorough cleaning. Finally they were ready.

The heads loaded properly and safely onto the surface and the oscilloscope probes were monitoring the signals from the heads, in preparation for alignment. I released the rotary actuator and moved the heads out to cylinder 105, where the special pattern is recorded. 

The head loading solenoid toggled in and out a couple of times, so we immediately switched off the drive. No damage but we had to inspect and repair whatever was causing the behavior. We found that one of the contacts from the loading solenoid was loose and repaired it with epoxy. 

We were out of time but are now ready to do the actual alignment next week, tightening a setscrew that minutely pushes the head outwards toward the platter hub. The initial location of the heads is about five cylinders too close to the platter rim, but when we get close will see a well defined pattern on the scope. Once we are at the correct location, that pattern will be symmetric on the scope. 


Working with RTE IV B

I put in a couple of hours improving my RTE system, using the simulator for convenience. I updated the startup script (a file called WELCOM) to handle some recommended tasks:

  • Compacting the system cartridge (002)
  • Registering overlays for large programs such as FTN4 and RT4GN
  • Implementing an improved timesetting function supporting the current year
Each such task teaches me a bit more about RTE and the HP environment. Fortunately it is of manageable total size, although big enough to require months to master not just days. 

Thursday, December 7, 2017

ALGOL working, battling my way through RTE, setting up logic analyzer with defective 12966A card


Working with RTE IV B

I finally got the ALGOL compiler working properly, again with aid from Dave Bryan. The compiler is an older product that worked with DOS and earlier RTE operating systems. In those days, compilers read and wrote directly to logical units, to peripheral devices, and not to files on disc.

Apparently they way that compilers worked in the past versions required different commands which are not documented in the mainstream parts of any of my manuals. Dave pointed me at Appendix D of one book which is the only place these are mentioned.

The :LS command creates a temporary area on a disk cartridge (partition of a disk) for logical source files. The :MS command is one way to copy the contents of a file into this termporary area. The :LG command creates a temporary area for the binary output to reside. The :SA command is one way to copy the contents of the temporary binary area to a disk file.

With a modern compiler like Fortran, I can convert a source file &PROG to a relocatable binary file %PROG with this command: RU,FTN4,&PROG,1,%PROG where FTN4 is the compiler name, as a convention files starting with & are source and files starting with % are relocatable binary. The 1 is the logical unit number of the terminal where I was typing. The command specifies input file, listing device and output file.

With ALGOL, I had to start by moving my source code to the logical source temporary area on disk with :MS,&TEST,ALGOL and identify that the temp area is associated with the program ALGOL (the compiler). I also issue a :LG,5 to create a five track temporary binary area.

Then, the actual compile uses logical unit 2 to point to disk (that is the boot disk drive logical unit), LU 1 to deliver the listing to my terminal, and 99 to indicate the logical binary file on disk. The command is :RU,ALGOL,2,1,99 and after it runs, my relocatable program is in the LG area.

I then do a :SA,LG,%TEST to save the output binary as a file %TEST. Now I can deal with it the same as the output of any modern compiler. That is, I have to use the LOADR program to convert the relocatable into an absolute binary file that can be executed.

The output of the LOADR is a executable file, named TEST because my source program used that name, which is pointed to by a temporary ID in the OS. Confusingly, it doesn't show up as a file in any disk cartridge, but a :RU,TEST will execute it.

I could have used the :SP,TEST command to copy the temporary TEST file to a disk file of type 6 (abs binary) named TEST, which would allow it to show up in disk cartridge listings and persist across a boot of the OS. Alternately, one could give the LOADR and option PE to make a file permanent, although it still doesn't show up in any disk directory listing.

I have much to learn about RTE, clearly, but each adventure moves me a tad further along that journey. I do plan to look for other compilers and interpreters - activating the PASCAL and BASIC software I already have on the disk, as well as finding languages like C or SNOBOL.

I did find a tape that contains the C/1000 language. It is in a tape format that can only be read by utilities supported under RTE 6/VM, a newer version that the RTE IVB I am using currently. I have to conclude that I can't support C on the current OS.

My current system already has PASCAL/1000 and BASIC/1000. The search for SNOBOL failed - I thought I had come across that in some listing of software but it isn't in the bitsavers master file list. I spent the morning getting PASCAL working. It was quite a fight, as the LOADR kept running out of disk space and I wasn't quite sure how to control that.

I was attempting to build a version of RTE IVB that supported the multiplexer to use the simulator MPX device and have two terminals open, but it pushed some areas over the memory limit and produced almost a thousand errors during generation. I would have to look through it carefully and figure out how I can change the input file to resolve the issues.

However, the essential fact is that I only wanted to solve the dual terminal issue under the simulator for convenience, to see the same operation as with the real machine. The burden of doing so is too high for right now, thus I will simply generate my system with twin BACI cards and accept the limit under the simulator that only one can be active.

Diagnosing bad 12966A BACI card

It was time to bring out the big guns - the logic analyzer and scope - to figure out how this card is stepping on other I/O activities. I pulled up the schematics and identified 32 points I could monitor that are specific to this board. In many cases, if I could isolate the driving signal just before the line driver 8T13 chip, then I wouldn't be seeing the line pulled down by any other card since the bus is shared.

The 8T13 chip has each driver set up as a pair of dual input AND gates combined with an OR gate before the actual driver. Since these connections are all internal to the chip, the best one can do is watch the four input lines to see when AB+C●D is true.

For the first pass, I hooked up the 12 most likely signals, using micrograbbers on the IC pins, to use with the first 16 signal probe set on my logic analyzer. I have ground and the signals wired, but need to fine another location where I can pull off the system clock of the HP 1000. The logic analyzer works best when clocked by the system, less so with what it thinks are async signals. 

Wednesday, December 6, 2017

1401 system down with failing bottom 4K of core


Today one of the two 1401 systems began malfunctioning, with the first 4000 positions of memory failing to respond at all. We spent most of the day checking signals but hadn't yet determined what is going wrong. 

Because all 8 bits (BA8421, parity C and wordmark) of all 4,000 characters are malfunctioning, it can't be an individual sense amplifier or driver. It has to be something that will affect all of the memory in the 4K section of memory.

In the 1401, the core stack for the first 4000 characters is inside the processor frame, while the remaining 12000 characters is housed in the external 1406 box (as three additional core stacks). Oddly, some of the addressing logic for the base 4000 character positions is housed in the 1406 then runs back to the 1401 to drive the core stack inside the main frame. 

Card reading, punching and line printing all make use of additional core planes in the first 4K core stack, thus it is not identical to the other three stacks out in the 1406. Other than these differences, the four 4K stacks are pretty much the same. Logically, each 4K stack is treated as two 2,000 character stacks, but that makes no essential difference.

There are quite a few pages of logic diagrams covering the circuitry to select a particular 4K segment, drive reads and writes, and route the data from sense amps into the processor busses. We also swapped cards with like card types in other slots in the area most likely to cause our problem, the selection logic. As I said, we have more work to do before we can find the problem and repair it. 

Tuesday, December 5, 2017

More checking of 12966A card, understanding dual terminal needs under simulator and installing Algol


Working with RTE IV B

I downloaded the Algol compiler with the aim of adding it to my system. It would be great to have as many languages as I can find. I have assembler, Fortran and BASIC, with some chance that I also have Pascal. Adding Algol and any others that were available are just icing on the cake.

I do need to work out a transfer means between a PC file and the simulator. I think I should generate a paper tape reader into the system just to allow me to mount the file as a tape and transfer it in. Ah, yet another system generation, although I can dump the file to virtual tape on the special system and then pull it back into my good system image.

After bashing around for quite a while, I had a paper tape reader, with the relocatable code file attached, but was unable to figure out any way to transfer it into my system. I know how to boot absolute binary code from the device, but what I wanted was to read in the PTR file into a disk file.

Next I guess I will figure out how to convert the file into a simh mag tape format, mount it on the 7970 tape drive in the simulator and try to read it in that way. It will be a project for another day.

I received some help from Dave Bryan, who confirmed that the simulator will not work with two BACI boards configured. He does believe that I should be able to get the version with one BACI and one MPX board operational, although we are still exchanging emails about what incantations and sequences are required. Still, good to know my suspicion was correct and the simulator cannot host more than one instance of any device type.

I have a detailed cookbook to get the MPX virtual device working under the simulator - while it is more complicated and different from my real hardware installation, I can build a common system that will boot on either the HP 1000 or the simulator. 

The MPX (12792C 8 channel multiplexer card) needs several drivers and additional equipment table and logical unit entries, before I can use the :CN and :CT configuration commands to get it active. I planned out my system generation for later execution. 

Diagnosing bad 12966A BACI card

I need to set up a more useful testbench to work on this card. Right now I am using alligator clips, an extender board, and a few power supplies. What I will need to be doing to further test this is to inject various signal combinations  on the inputs while watching the state of all the logic gates affected by them.

Fortunately, the -2V bias voltage for inputs makes all of them a valid 0 value when open, thus I only need to inject a logic 1 by applying a positive voltage level to a pin. I can use my micrograbbers hooked to scope probes for watching outputs of gates.

The failure mode is certain to be a case of an output being switched to 1 when it should not - the board is not selected. Where that occurs is the big question.

My first blush shows that the board is not selected when all the three selection inputs (SCL, SCM and IOG) are low. However, it may be that it will select when only some of those are high, whereas it should act like an AND function.  That would be an easy problem to find and correct, with the improved testbench.

However, the testing proved that the selection logic is working properly, only activating if all three inputs are high. I therefore have to work back to check every gate for proper operation. This will be tedious but ultimately if I can push all gates through all their combinations I should be able to find the bad part(s).

The next test was to check that all the gates which should block incoming signals while the board is not selected are working properly. I had to use quite a few micrograbber clips and alligator clips to manage all the inputs, outputs and power to be covered plus I bought an 86 pin .156" connector to wire up power and key signals. 

My test showed that all inputs which are gated by the selection logic (SCH⚫SCL⚫IOG) will be blocked unless the selection is active, at which point they work properly. The tested input signals:

  • IOO
  • IOI
  • SFS
  • SFC
  • CLC
  • STC
  • STF
  • CLF
There are a number of inputs which are not gated by selection logic:
  • PRH
  • IEN
  • ENF
  • SIR
  • IAK
  • T3
  • CRS
  • IOB15
Testing the above set of inputs is more complicated, constituting much of the interior logic of the board. The sequences that should trigger various latches to set or reset inside the machine are complex, thus I can't cover all of that until I have exhausted all the easier testing.

The next set of signals to test are easy - the three signals that individually can command a reset of the board. If POPIO, CRS or IOB15 are 1, the board will reset. POPIO is a power on or preset key rest, the high bit of the IO word is a software means to request a reset, and CRS is driven by a CLC instruction requesting a reset. 

There are four chips involved in generating the reset signals, which I will test out in this round of checks. Once I know the reset is properly generated, I will trace it to the various flipflops that are controlled by the reset signals and verify as much as possible that they reset. It may be complicated to first force the FF to switch on, but I will work through that after proving that reset itself is generated.

Stage one was good - when either POPIO or CRS is activated, the reset timer generates a 5 microsecond pulse. I couldn't test IOB bit 15 because it is gated by some status of a flip flop, probably one that means IO is in process. Since I was not using the card when it jammed up IO activity for other cards, we are not dependent on that function and can neglect it for now.

Stage two will be to look at where the reset signal is sent and evaluate the health of each gate it controls. At a minimum those gates should sit in the right state after power-on of the testbench and following a reset signal. Any that are in the wrong state after reset are a problem, but that doesn't fully test out this functionality. Unless I can set each FF to its opposite state before issuing the reset, I can't confirm that reset functions as it should.

The FFs I checked and their state after reset are:
  • Lockout - switched on
  • SRQ - off
  • IRQ - off
  • Flag buffer - off
  • Control - off

I then looked at the Flag FF, driven by the one I checked, and it is correct. I checked the priority encoding logic (if PRH from a higher priority card is active (0 logic level) or the BACI card wants to interrupt, then the output PRL is active (logic 0) otherwise it is high. That is properly logic 1 when PRH is 1 and drops to 0 when PRH is down at 0. 

As I expected, this is tedious and there is still a lot unchecked on the board. I might have to jump to plan B - logic analyzer covering key FFs and internal states to see if the card, while plugged into the system, ever activates any signal that could affect other I/O in progress. That will take quite a bit of setup. This task is set aside for now. 

Downloading software for use with the system

I mined the archives at Bitsavers and downloaded the paper tape master files plus a few key other files, which will give me access to pretty much any software I want that ran on the HP 1000 system. First priority is to figure out how to get Algol onto the system.

I did a byte swap (between the little-endian format used by Windows and the big-endian format for RTE) mounted the file as to the PTR and successfully transferred it into the system, I think. I have a binary file I named %ALGOL but the challenge is to further transform it into a command I can run.

I attempted to use the LOADR and asked for the %ALGOL as a REL file, but the program aborted with an illegal record error. The file is not formatted as a relocatable image. If it is a binary file, I must have read it in with the wrong parameters. 

Dave Bryan straightened me out about the problem I had with Algol. The file I had was an absolute binary, the wrong kind to use with RTE. Bryan pointed me to the correct files and the sequence of steps I will need to install the compiler. With it installed, my test programs are not compiling - receiving error right at invocation of the compiler as it reads the first line. 

Saturday, December 2, 2017

Dual terminals active on real HP 1000; continued diagnosis of defective serial card


Working with RTE IV B

I am still unable to get RTE under the HP1000 simulator to talk over more than one terminal at a time. I am poring over every word in all the HP manuals - system generation, online generation, user reference, and so forth - hoping to find some clue to why I am not seeing a prompt on the second terminal.

Since I have the loaner 12966A BACI card, I stuck it into my system to verify a few things. First, it illustrated that this card does not jam up I/O like my defective one. Second, it showed that I could bring up RTE with both cards installed. Third, it let me try to use my second terminal.

Oh frabjous day!

The card worked fine, my RTE came up and I could simultaneously run sessions on both of my terminals! I still don't know why I can't get the HP2100 simulator to work properly, but now that I know the systems I generate will work properly on real hardware, I am more than satisfied.

Diagnosing bad 12966A BACI card

To properly load down each output pin, I will need a 1.5K resistor tied to -2V. That also means I need an added voltage source of -2V and extra clips to place it into circuit. However, I could do some initial testing and found several output pins high.

However, I believe this is because the card thinks it is selected. When the signals SCL, SCH and IOG are all high, it enables all sorts of outputs to report status, request interrupts etc. The input pins are open, thus the state of the selection logic is indeterminate.

To resolve this, I grounded the three input signals at their pins, then examined the condition of the NAND and inverter gates which create the selection signal for everything else. Armed with chip locations and pin numbers, I set out to check the operation of those two selection gates.

They worked properly. With the inputs unconnected, the resistor networks that normally pull these down with a -2V bias instead allow the inputs to float high, driving the NAND gate to a logical 0 and that is inverted properly by the inverter to logical 1. Grounding any of the input pins will drive the NAND gate to 1 and that gets inverted to 0.

Next I tried applying the -2V bias voltage to the board and checking the resulting open pin voltages for the selection signals as well as the output of the NAND gate. This should make every input a 0 whereas right now they all appear as 1.

All the inputs were indeed logical 0 and all the outputs were correctly logical 0 as well, so any problem I have is not on the edges (inputs and outputs). Instead it is something in the interior logic, for example some gate that disregards the selected signal and emits output at the wrong time. This will take a bit more time to debug.

Friday, December 1, 2017

Successfully created alternative character sets for 264x terminal, finished ethernet tool and cleaned alignment cartridges


Creating character set Proms for 264x terminals

I brought some blank PROMs (Harris 7681) to burn with character sets, for installation in the older version B of the Display Enhancement Board. That version uses one of two types of ROM chip - a 9 bit that produces the 9 pixels by 15 lines for each character position, and an 8 bit chip that hosts 7 bits x 15 lines of an alphanumeric character plus a control bit to shift the 7 bits to the left or right within the 9 pixel screen space.

The pin layout and other characteristics of the 8 bit ROM match up very well with the Harris part number, with one exception. The Harris part has four chip enable pins, all four of which must be active to enable the chip; this is called AND logic by HP. The HP part, however, will activate when either the first two are active, or the last two are active; they call this OR logic.

Since the fourth pin is always active on the board, if the third pin were also active the chip would always be on. To prevent this, HP has a jumper that is installed for these ROM types, driving the third pin to its off state. The chip is therefore activated purely by the signals on the first two enable pins. 

We burned the Math Character Set onto one of the PROM chips, but couldn't allow the third enable pin to fit into the socket, since that socket position is driven to a 0 value by the jumper. The jumper also controls the half-shift and other functions of an alphanumeric set, so it must be kept in place.

The solution is to bend that one pin (chip enable 3) up out of the socket. We hooked it to an external 1K resistor and tied the other end to the +5V supply. This activated pin 3, pin 4 is always activated, so that the ROM is controlled just by the first two enable pins - same as the HP part, but in our case the Harris chip must have all four pins activated to work. 

It worked perfectly! Next up was the most challenging situation, making up a component that will act like the 9 bit ROM used by HP. Fortunately for us, some engineer at HP had figured out a way to use an 8 bit ROM and recreate the full 9 pixel by 15 line pattern of their character sets. It involves duplicating bit 0 so that it feeds out as bit 0 and bit 1, then shifting the remaining 7 bits to feed out as bits 2 through 8. 

We did this by taking an 8 bit PROM, then bending pins to shift the 7 data bits over one position, driving chip enable pins 3 and 4 from the signal on the enable 3 hole in the socket, plus taking the bit 0 pin and wiring it to both bit 0 and 1 holes in the socket. 

This might not be hard to do in the abstract, but the Display Enhancement Board has to sit immediately adjacent to another circuit board inside the terminal. Various rules for placement mean that we can't have an open slot to give room for our sandwich of an 8 bit PROM on top of a socket with all the rewiring.

Marc found a socket that is normally used to solder resistors or other components on top and plug into a DIP socket under it. He bent terminals, snapped a few off, but ultimately he got the PROM on top to connect to the pins that match a 9 bit HP part. Lots of delicate soldering and microscope work, but the resulting package was only slightly taller than the height of a ROM directly plugged into its socket. A PROM wired to a socket plugged into another socket - but very compactly. 

This too worked perfectly. Now, Marc could add the version B Display Enhancement Board to a 2645A terminal to give it the Math, Line Drawing and Large Character sets as alternatives to the base character set. We played with the Large Character Set font, building some letters that take a 3 x 3 space on the screen (27 pixels by 45 pixels). 

Final testing of Alto ethernet tool

Ken brought three of his Ethernet tools, wanting to have them all tested before loaning one to a fellow Alto restorer on the east coast and keeping one hooked to our restored Alto. The tool is based on a Beaglebone board, with a daughterboard ('cape' in Beaglebone parlance) that does level shifting between the Alto TTL levels and the 3.3V signals of the board. 

The Beaglebone runs Unix, plus code built by Ken and code developed by Seattle's Living Computers: Museum and Labs. It provides file serving, boot serving and routing for the Alto, as well as routing over modern 10/100MB ethernet and to the Internet. Ken installed many applications for the Alto on their, which can be booted over the network. 

However, the three Beaglebones that Ken bought didn't have the same version of Unix installed - different enough that the LCM and his code wouldn't work right on some of them. He had to load all of them with a consistent set of software and test that out. 

The original code from LCM runs on a Windows based PC, which led to a subtle issue when it was moved to Unix. Windows ignores case in names, but with Unix, Pinball and pinball are two different names. This required some adjustment of naming in control files to make all the software visible. 

One of the three capes built by Ken had a slightly different level shifter chip, which was enough to fail to work with the Alto. The successful capes use a 74HCT125 chip, but the failing board had a 74HC125. The lack of the 'T' for TTL compatible was enough to cause the Alto to ignore it, even though the specs of the chip versions appear fairly close. 

Cleaning repaired Diablo alignment cartridges

Last week we did some drilling, tapping and milling to repair the two Diablo disk alignment cartridges we were loaned from Digibarn. Most disk cartridges for these drives are constructed with four countersunk screws holding the bottom plate on the remainder of the platter hub, but the alignment cartridges appeared to just press-fit the ring onto the hub.

Over time and with absorbed atmospheric moister, the rings became loose. One sheared right off when spun in the drive. The other was loose only one one arc of the ring, causing the platter to wobble up and down dangerously between the heads. 

The only mistake we made was not controlling the oil that was needed to tap the threads into the platter hub. When the cartridge was spun up to 1500 RPM in the drive, oil migrated out of the hub in streaks on the platter surface. 

We spent this session cleaning the platters, closing them up, spinning them for 30 minutes, then opening up for a next inspection. After a few cycles of this, we had no visible oil coming out of the hub. The final test will be next week when we will spin our chosen cartridge for a couple of hours and inspect carefully. If we had zero oil reaching the platter, we will be ready to try an alignment.

In order to spin the platter without risking the heads from any migrating oil, we did two things. The heads were removed, and the solenoid that forces the heads onto the platter surface was disconnected. The drive electronics got the platter up to speed and then commanded the solenoid. It assumed that the heads were now flying microinches above the platter, but it has no way of checking. It sat with the "Ready" light turned on, happy as can be. 

We have two Diablo drives, each with a pair of heads we removed and carefully cleaned to like new condition. These will be remounted in the drives, but their exact position linearly from the edge of the platter to the rim must be adjusted to match the same position as every other drive. 

This occurs by rotating a setscrew into the arm where it pushes against a diagonal groove in the head assembly. This pushes the head out a bit with each rotation. A standardized recorded signal is written on alignment cartridges at the factory, so that the correct position will produce a recognizable pattern on an oscilloscope. 

With our repaired alignment cartridges, we have the standardized signal to allow us to get those heads pushed out to precisely the right position along the radius of the platter. It should only take an hour to carefully move each of the two head assemblies to the proper position and lock them down. First, the drive has to come up to stable temperature by spinning for half an hour, so overall this is a couple of hour task, I estimate. 


Diagnosing bad 12966A BACI card

I didn't make any progress today on debugging the card, but I did get a loaner card from Marc which I can use to test out my dual terminal configuration. Once I repair my card, the loaner will go back.

Since I/O is disrupted from tapes or other devices any time my defective BACI board is installed, we know that it is sending signals on the bus when it should not. One of the output drive chips could be stuck on, emitting a 1 bit at all times. Otherwise, the logic on the board should only operate when the board is addressed by its select code.

Two signals must be on to select the board, and without those signals nothing should be emitted on any output pin. If the card is responding when not addressed, it is probably a failure of the selection logic. Either this, or a stuck-on output chip, are the most likely failure mechanism that matches my symptoms.

However, there is a possibility that the selection logic itself is producing an off signal, correctly, but one of the gates that is conditioned by this signal is firing in spite of the 0 input. These internal logic gates, somewhere between failed selection inputs and stuck on output chips, could be the root of the problem.