Still working to have two terminals active under RTE IV B

HP 1000 SYSTEM RESTORATION

Working with RTE IV B

Editing files in the simulated RTE environment is quite a pain, due to the interspersed prompts of both system and file manager level that occur with a single terminal online. One of my latest attempts to produce a dual terminal system and activate both came to a bad end when I inadvertently set up the directory on the system disk cartridge so that it clipped part of the system code.

HP refers to partitions or sections of a disk cartridge as a cartridge, confusingly. My virtual 7920H disk cartridge, containing 411 cylinders each with 5 surfaces (tracks or heads), is divided into six portions. These are the system, GF, GN, HP, RT and SC (spare) cartridges.

Each cartridge has a directory and contains files. The system cartridge also stores the system itself, thus the directory for the system cartridge must begin above the end of the generated system. I mistakenly formatted the directory in a way that overlaid the tail end of the system. Back to step one!

At this point, I think I have built a usable disk image which supports my terminals and IO configuration. The image as used with the simh based simulator on a PC has its byte order swapped compared to the HP 1000, thus I need to run the dd utility against it to swap bytes back to their correct order for use with HPdrive.

I moved the image over to HPdrive and attempted to boot the image, but received a halt 102011 which means that the disk IO encountered an error. I switched back to the prior image I had been running and that too stopped with an error.

The one hardware change I made was to insert the second 12966A serial card in slot 23 in order to have both terminals active simultaneously. I had feared I had an error with the second card back a month or so ago, but it wasn't definitive. Time to pull various cards to test which causes the problems.

With just my original card in slot 22, the new system boots up fine. With just the suspect card in slot 22, the I/O error occurs during boot. The card is bad, perhaps driving an interrupt request or causing some other interference on the bus that blocks the higher priority disk controller card from succeeding in its I/O.

I still can't get the simulator to talk to more than one telnet session even with twin BACI cards generated and attached. I will see if I can switch one of the simulated cards from BACI (12966A) to an 8 port multiplexor, modify the WELCOM file to try to bring up a terminal on the mux and see if that works. This may be a defect in the simulator file, which might not support more than one BACI active at the same time.

I did download the QCTERM software from the HP Museum down in Australia. With it, I am no longer plagued by the dual prompts of system and file manager. The same happens on my physical terminals if I have auto-LF set but behaves fine with it off. Thus I can't use the built-in telnet client in Windows since it insists on CR-LF when hitting the Return key.

QCTERM won't run more than one copy on a system, thus I would have to go through some contortions to have two of these running talking to the HP simulator. I generated a system with a MUX card for the second terminal and continued to try to get the second terminal active under the simulator.

The telnet session did refer to connection to the MUX device, but that was as far as it went. My last test was to switch the telnet and QCTERM devices - using the telnet as the system console and attempting to use QCTERM as a second terminal. The results were the same - no signs of life from the secondary terminal.

Slightly frustrating - I just don't know whether there is something I am missing which is stopping the simulator image from running. I do know that I have a bad BACI card in real life so I can't try out dual terminals on the HP 1000 system. 

Now have the 2621A terminal working with my HP 1000 F system

HP 1000 SYSTEM RESTORATION

2261A terminal debugging

The code loop is watching for when the status word indicates the buffer empty status, but I don't see the prompt on the terminal. For some reason, that isn't occurring. What I believe has happened from the code side is that the prompt message was output to the 12966A card, it entered the buffer, but it is not clocking out.

That suggests that the UART clock is not working. Since it works with my 2645A terminal, it may be that the card is watching the blue wire, external clock, rather than generating some rate between 9600 and 110 baud internally.

That should be determined by a jumper in the cable connector that holds the P/Ext pin high to indicate internal clock. The wire is there, running from a source of +5V (pin 8) to the P/Ext pin (N). I am beginning to suspect that the sense of P/Ext is reversed from what I believed. That is, it should be set to ground to use internal clocking.

Somehow, the 2645A generates and emits the clocking signal that is used by the 12966A card to drive its output back to the terminal, and the 2621A was able to emit a clock on pin 50 as indicated by the cable jumpering. However, the 2622A terminal, which is the device I actually have, dropped this capability as I can tell from both the schematic and the lack of traces to the pin on the logic board.

Time to rewire the cable connector jumper so that pin N is no longer wired to pin 8, but instead ties to pin 1 or pin A (signal grounds). With that set, it is my belief that I can get the board to try to write out the buffer contents. Then, all I need to do is massage the communications settings in the terminal to match what the code is sending. 

My first test after modifying the P/Ext state made no difference in the CPU side - still looping waiting for the buffer to empty, and nothing appeared on the terminal itself. Next, I hooked up the scope to see if the signal coming from the serial card is behaving properly or not. It should be at -12V except when wiggling up to +12V forming the sent characters.

No movement. Just in case the terminal was pulling the incoming bit line down to 0 (-12V), I removed the wire from the terminal and monitored it separately. Still no characters transmitted. It seems like the serial card is waiting for something, but there are only five signal wires between the devices:

1. Red TD for data bits from the board, hooked into RD on the terminal
2. Brown RD for data bits coming from the terminal, hooked to that device's TD
3. Yellow Ring Indicator on the terminal fed by the device's Terminal Ready signal
4. Orange Secondary Channel SBA/SCA fed to the terminal's OCR1 optional input
5. Blue External Clock feed to the board with no source on the terminal

If it is a missing signal, it may be an SBA/SCA value that is expected by the serial board. No documentation to explain what that might be, and the terminal schematic and manuals shows that to be an optional channel line that is by default low (-12V) but can be changed to a steady high (+12V). I can change that value by terminal configuration, so that was the next test. 

No joy - the signal didn't start even with that changes. The final inbound signal is External Clock, which should be ignored given the jumper wire I changed in the cable connector. I did try some other permutations of the wiring in the cable connector, forcing the connection to a fixed 9600 baud regardless of program choice, which should match the configuration I set in the terminal.

That did it! The terminal happily chatted away with the tape diagnostic configuration program, thus giving me two working terminals for use with RTE. 

Working with RTE IV B

Now that I have a second working terminal, it is time to complete my RTE IV B system generation giving me a disk image to boot which supports the twin terminals and my hardware configuration. I will continue doing this under the HP 2100 (simh based) simulator, then convert the disk image to use with HPdrive and my real machine. 

Still working to get 2621A terminal working with HP 1000

HP 1000 SYSTEM RESTORATION

2261A terminal debugging

I moved the Yellow lead over to the jumper installed between Terminal Ready and Clear to Send. The terminal itself sees the ready condition, but this still isn't working with the program trying to write to the screen.

It was time to whip out the scope and watch for signals in both directions. Annoying darned serial communications. Outbound characters when typed on the keyboard were captured leaving the terminal, and once the board received a character my inbound data line jumped up from low to high and stayed there. Something definitely off about the board being ready to send data.

Looking at the loop in the program while it is waiting to send out the prompt to the terminal, I see it is loading the 12966A board status word into the A register, rotating it and doing a test. The status word was 014032 which decodes as:

• CF on - received line signal detector
• CE on - ring indicator RI
• CC on - data set ready DSR
• CB on - clear to send CTS
• Ovr/Par off - overrun or parity error
• Break off - break
• Buf Emp off - buffer empty
• Buf full off - buffer full
• Buf half off - buffer half full
• Test on - test or receive lookahead
• Spare on - spare line on connector
• Spec off - special character
• Devint off - device interrupt

This status word shows that the card should think the other end is ready, but it is hung up looking at the Test bit waiting for it to turn on. Looking at my scope at the terminal, the data line is always low unless sending characters, so that the test bit should be low, but won't go high unless a character is entered. 

Thinking I may have a cable problem or wiring issue, I did some testing. The brown wire runs from the terminal output pin 12 RD up to the connector pin S and that is what is monitored as test. I see it at -12V steady unless keys are pressed, which should show up as a 0 in the test bit. Good so far. 

Once again I checked the wiring, as well as verifying continuity through the cable to the connector on the 12966A board. All is good as far as wiring and cables. The terminal produces output keystrokes just fine. This remains a vexing mystery but I will keep at it.

264x terminal additional character set ROMs

More digging and examining of the two types of Display Enhancement Boards, versions B and C, led me to understand the jumpers and dip switches fully. As a consequence I realized that we will have to set the boards differently than normal when installing the alphanumeric character sets we burn.

The PROMs we will use to burn the character set images, while pin compatible, are the type that AND together all four enable pins. The switch setting A on the Display Enhancement Board version C states that it should be closed for alphanumeric characters but what it does is ground CE3. For AND type enable logic that will block the chip from activating. Instead, we need to leave switch A open for all our burned ROMS.

On the older version B of the Display Enhancement Board, two jumper positions are provided for each character set rather than the five DIP switches on the version C board. The second of the two jumpers implements the same function as switch A - ground CE3 of the ROM when closed - and thus should be left open for any PROM we burn.

I also devised the rewiring necessary to stack a prom chip atop a socket, bend the pins sideways and solder wire jumpers to rearrange the signals such that it will behave like a 9 bit rom while mounting an 8 bit prom we programmed.

Resolved copy and burn of 264x terminal character ROMs, fixing Diablo Alignment cartridges

RESTORATION WORK WITH MARC AND LUCA

HP Terminal Character PROMs

The first task of the day was to capture the contents of the three ROMs on my Display Enhancement Board from my 2645A terminal.These provide the Math Character Set, the Large Character Set and the Line Drawing Character Set for use with the 264x series of terminals.

Marc and most current owners of 264x terminals have either a single alphanumeric character set that comes with the base configurations, or an enhancement board that adds only the Line Drawing Character Set. 

No online copies of these PROMs exist but the partially or completely unpopulated Display Enhancement Boards (DE) are in decent supply. We intended to capture the images and make them available to provide all the alternate character sets to install in Marc's (and other restorers') terminals.

There are some complications to this that undoubtedly explain why nobody has dumped and shared these before. The terminals place each displayed character in an array that is 9 pixels wide and 15 lines long. Ordinary alphanumeric character sets are 8 bit values stored in ROM that make use of a half-shift the terminal executes, so that the 8 pixels are centered in the 9 pixel wide space. 

Math character set with halfshift alignment

Character sets can contain just 64 characters, covering the low part of the ASCII space, or can be 128 characters in size. Thus the DE board can fit one or two ROMS per character set. However, other character sets can be graphical in nature. If they need to form contiguous images across the screen, then they need to produce all 9 pixels, disabling the timing delay that accomplishes the half shift.

These character sets that are graphical in nature are called microvector. The original version of the DE board employed ROMS that output 9 data bits at a time, filling the character position with a 1 to 1 alignment of data bits to pixels. The 9 bit ROMs were either a very rare part or something custom built by HP.

To allow the use of either half-shifted alphanumeric character sets using 8 bit ROMS or 9 bit microvector sets, HP's 9 bit ROM is almost fully pin compatible with the standard 8 bit ROMs available from most suppliers.

This compatibility takes advantage of the three chip enable pins on a standard 8 bit ROM, all of which must be brought low to select an output byte. These are called an and enable scheme. The special 9 bit ROM uses one of the three enable input pins as a ninth output bit, plus it converts the other two enable pins so that the chip will work if either is brought low, called an or enable scheme. 

The second, newer version of the DE board makes mention of using either 8 or 9 bit PROMS for microvector character sets. Sometimes the configuration switches are described as 8 vs 9, other times they are described as and vs or enable logic. Tantalizing but confusing. For 8 bit microvector ROMS, they stated that bit 0 is duplicated to form the full 9 bit output pattern.

newer type C Display Enhancement Board

We started with a character set display program built by Ken, then modified by Marc to try to make sense of the way 8 bit microvector ROMS could produce 9 pixel patterns that could form contiguous shapes on screen. 

9 bit ROM containing Line Drawing Character set

We dumped on 9 bit ROM image, by first dumping the ROM as a standard 8 bit part, then bending up a couple of pins so that we could jumper the repurposed enable pin over to replace the eighth data bit. This gave us two captured images which could be merged to form the 9 bit data pattern. 

The Line Drawing Character Set for the earlier DE board is on a 9 bit ROM, but the newer DE board makes use of an alternate part number that seemed to be an 8 bit ROM of the same character set. On screen it looked identical and formed the same contiguous shapes.

8 bit ROM with identical Line Drawing Character Set output

Using the Python program and trying different things, we discovered that the 8 bit microvector ROM takes the eight data bits and delivers them as bits 2 through 9 of the output, plus duplicates the first bit as bit 1 of the output. 

Some genius at HP noticed that the 9 bit character set could be exactly replicated using this shift and duplicate scheme. Thus, the new part number for the Line Drawing Character set that allowed it to be burned on regular 8 bit ROMS. 

We can now burn the four captured images on new PROMs, using only industry standard 8 bit PROM chips. Three of them, the 8 bit Math, Line Drawing and Large Character sets, are a straight copy. The older Line Drawing version, however, needs a clever mechanism to have an 8 bit ROM behave like a 9 bit part. 

Large Character Set from 8 bit microvector ROM

We will bend the chip pins out sideways, then place the chip atop a kind of chip socket, forming a sandwich that lets us run wires to duplicate the first bit and shift the remaining ones to their appropriate position. Also, it will have to convert the OR enable logic of the socket to the AND enable logic of the chip atop our sandwich. This will create a component that operates like a 9 bit ROM but is implemented using a widely available 8 bit PROM part. 

Diablo disk drive

We were loaned two alignment cartridges for the Diablo drives, to allow us to align heads after they are reinstalled in the drive. The first of them was discovered to rub badly and refuse to spin, due to a complete separation of the metal ring on the bottom of the cartridge from the rest of the platter. 

Alignment cartridge 2

We found that ring stuck to the permanent magnet ring on the drive's spindle, which confused us for a while since no cartridge would mount properly from that point forward. This was covered in an earlier post, but we discovered and removed the ring, allowing the drive to work with other cartridges.

After cleaning and replacing heads, we attempted to do an alignment last week, only to find that the second alignment pack's platter rim would wobble vertically and rub a bit. This would definitely cause a head crash. This week, we discovered why that happened. 

The same metal ring that had detached completely on alignment cartridge 1 was seemingly intact on cartridge 2, but I discovered that it was slightly detached on one side and could be flexed to form a wider gap. Thus, when the drive spun one side of the platter would be higher and a wobble ensued.

Look closely at gap of ring plate at top from metal it sits atop

The other side of circular ring which shows no gap

Marc decided that we could drill and tap the plates to use screws to hold it back on the rest of the platter. Most data cartridges we have use this method - we see four countersunk screws at the base of each. The two alignment cartridges seemed to have settled for a press-fit plate which fails over time.

Since alignment cartridge 1 had some rubbing damage on the data platter, it was the ideal part upon which to practice. Marc used his mill to drill four holes, hand tapped them, chamfered to countersink screws, then screwed down that formerly detached plate. Since the surface was a bit scarred we used this to test wobble on drive. Excellent results - the repaired platter spun with no vertical wobble and no significant vibration. 

Marc carefully completed fix on the newer cartridge, resulting in zero wobble and vibration free spinning for this platter with undamaged surfaces. Unfortunately, the oil used while tapping the screw threads was seeping across the platter surface by centrifugal force. We cleaned it off but will take a while to be sure no more oil is migrating out during spinning. Alignment will wait until we have the repaired cartridge fully clean and free of migrating oil.

Drilling holes

HP 1000 Restoration

2621A terminal restoration

I converted the wiring on the Centronics 50 connector for my cable between HP 1000 serial board and 2621A terminal, using the signals and pins I identified through my study of schematics and materials.

It was better in one way - the asterisk at the bottom center of the screen lit up, indicating that the terminal knew it was connected and ready. However, it still looped in the mag tape diagnostic setup code trying to communicate, so that there is still something not quite right. My suspicion is that the terminal is now happy but the 12966A terminal board is not. 

There is a tight loop being executed consisting of:

• 107722
• 102522
• 001727
• 002021

These instructions are:

• Clear Control Flag of device 22 (my terminal)
• Load Into A from device 22
• Rotate A left four bits
• Skip if A is negative (leftmost bit set)
• Jump to top instruction

This tells me it is reading status from the 12966A board and will loop until bit 5 is on. It shifted the A reg left four to get bit 5 up in bit position 0 where the skip instruction would test it, using a skip if bit  0 is off, but reversed with the RSS bit in the instruction so it skips if bit is on. 

The bit it is testing is the Receive Data line from the terminal to the card, before it has been processed. It is watching to see a non-zero bit (the start bit of an incoming character I suspect), but never receives it. I think this may be some kind of loopback of the sent bit to tell the board that the terminal received it. 

Perhaps my terminal is never sending that bit because the state of the Clear to Send line is wrong. I hooked that to the Orange wire from my cable which is Secondary Channel SBA/SCA according to the diagrams in the serial board manual. 

Instead, I probably should hook this to a signal that is always on, such as terminal ready, just to see if that is what is holding up the board. It may need to be a loopback but I don't see any way the terminal can accomplish that, so I will first try to rewire to force on the Orange line. 

This is why I find serial communications so frustrating - there are a myriad of ways that the signal are watched or set, with various schema for looping some control signals to others. RTS hooked to CTS. DSR hooked to DTR. Each specific implementation has to be understood just to get the two damned ends to watch the RD and TD lines with the actual data being transmitted. 

RTE 6/VM firmware ROMs

Marc had spare ROMs for the two firmware sets needed to support the newer RTE 6/VM operating system. The two features are RTE 6 OS and RTE 6 EMA/VMA, each comprised of three ROM chips. The RTE 6 EMA/VMA chips sit in the same microcode address range as the RTE IV B EMA feature chips, to that they can't both actively coexist in one system. 

ROM sets for RTE 6 support on HP 1000

Installing these is a matter of placing them in open sockets on the Firmware Expansion Module board in my system, then setting configuration switches to place them at their assigned microcode address ranges. There are configuration switches that disable chips as well, allowing me to install both RTE IV B EMA and RTE 6 EMA/VMA, both at the same address range, but activating only one at a time depending on the OS being run. 

Worked out wiring for 2621A terminal

HP 1000 SYSTEM RESTORATION

2261A terminal debugging

Relatively useless set of pins since it is on the connector on the logic board, not on back of terminal

In the wiring of my cable between the serial board and the terminal, the output Data Terminal Ready is looped back as inputs on Clear to Send and Data Set Ready. The other two inputs are Read Data, of course, and Ring Indicator.

The outputs are the aforementioned Data Terminal Ready, as well Send Data, Ready to Send and an ignored signal to select the alternate speed on dual speed modems. What is missing is proof that these eight signals are wired to the Centronics 50 connector pins I expect, located on the rear of the terminal.

One possible cable connection to the 2622 terminal, similar to 2621

The 2622 is very similar to the 2621A that I have as my primary terminal and identical to the alternate terminal. I try to use the cable diagrams like the one above, but these don't match exactly the signals used by the 12966A.

Cable defined between 2621 terminal and 12966A serial card

The above diagram is the one in the manual for the 12966A serial card that claims to be the wiring to the 2621A terminal. I do indeed have those wires connected as listed to the Centronics pins. For example, pin 12 on Centronics is the Brown wire which carries Receive Data from the terminal to the board.

Note that a jumper is defined at the bottom between Centronics pins 36 and 46. It turns out that 36 carries +5V and it forces the Secondary Channel signal to on. The other wires line up reasonably well except that the middle diagram above shows pins 16 thru 23 of the Centronics connector are shorted together.

In the theory of operations discussion for the terminal, it mentions that a signal DM indicates that a connection was detected, causing an asterisk to appear in the middle of the bottom line of the display. This is the loopback from the Data Terminal Ready output, through the cable. 

I went out to scope the connections between logic board J6 and the Centronics 50 connector, as well as studying the state of pins 16 to 23. I discovered that J6 on the logic board is a 2x17 connector strip seemingly wired in a pseudo-1-to-1 manner to the Centronics 50,

That is, only 34 of the 50 pins on the Centronics are wired. Pins 1 to 17 on J6 are wired to pins 34 through 50 respectively of the Centronics, while pins 18 to 34 of J6 go to the other side of the Centronics, pins 9 to 25.

The result is that the Centronics pin numbers don't make sense compared to the wiring chart from the 12966A diagram. What I know for sure is that the J6 connectors are correct based on the processor schematics. Using the logical function of the lines and the purpose of the wires in the cable to the 12966A board, I figured out how the Centronics connector must be wired.

How I figured out the proper wiring for the terminal

Still diagnosing why my 2621A terminal is not communicating with HP 1000 system

HP 1000 SYSTEM RESTORATION

Working with RTE IV B

I did a number of system generations and initialized each, just to further build up my understanding of the RTE IV B world. I continue to be plagued by the simulator. What I want is to have two 12966A (BACI or serial cards) installed, with twin telnet sessions connected to them, allowing me to have a system console plus a regular user terminal.

Any attempt to boot up even in reconfiguration mode with BACI0 and BACI1 configured just hangs. I notice that when I set up telnet sessions, the connection occurs on BACI1 rather than BACI0, the reverse of the order I would expect.

With things swapped backwards - the first set BACI command actually sets up BACI1 while the second such command establishes BACI0 - I can get the system to boot up and talk to me on the system console. I still can't get the second terminal active.

I put that problem aside and worked on my system generation experiments - learning various utilities and trying things. The ultimate end is to have the best version of RTE IV B set up that I can, using the simulator, before hauling it over to the HPdrive virtual disk drive and running on the real system.

Once that is proven to work well, I want a version that can support the physical 7906 disk drive in addition to my virtual 7920H drive, allowing me to end up with a system placed on a fresh cartridge on the real drive. Of course, I would need to finish the restoration and alignment of the drive before I was ready to install RTE on the cartridge.

2621A terminal debugging

My first test involved swapping the 2622D terminal body and seeing whether the first messages from the tape diagnostic program show up on the screen. If so, it points at my 2621A terminal as faulty or misconfigured.

The good news is that something about the default configuration and cable is the fault, not the terminal hardware itself. The swapped terminal displayed nothing, just as the 2621A failed to show anything.

Before I set up for scoping or logic analyzers, I did some verifications. First, I checked that each signal line from the Centronics 50 connector is tied to the proper edge connector pin that will fit on the 12966A serial card in the processor. Then, I dug out the schematics and verified the signals on the terminal were the Centronics pins I expected.

I found some anomalies. The manual for the 12966A serial board has a cabling chart for the 2621A terminal that lists only a few pins on the Centronics connector, but the 2622 service manual shows a number of pins that are shown as shorted together. I have to take my time and reconcile these to understand what my wiring needs to be. Plus, I will cross check them to the schematics in the 13220 processor module manual for the 2621/2622 terminal

IBM 1401 Restoration work at CHM

We had one 026 keypunch that began making a squealing sound as it idled. After some disassembly, Frank found a pulley bearing that was making the noise. A touch of machine oil on the bearings and everything quieted up just fine.

Another team, Mike Albaugh and Marc Verdiell, continued working with the tape emulator on the quest to get the 1401 Fortran Compiler operational. Once they sort out those issues, we think we can get a FARGO and a COBOL system up, although the typical COBOL process is thought to be 30-60 minutes long, first producing Autocoder as an intermediate text before yielding the final executable. 

Building up some chops in RTE IVB, slowly and steadily

HP 1000 SYSTEM RESTORATION

Working with RTE IV B

I spent most of the day bumbling away at RTE - taking the new image I generated and trying to clean it up. There are initialization steps that involve loading and setting up various utility commands which are a bit tedious but it was essential that I figured it all out if I hoped to get a real bootable image placed on the real 7906 cartridge and have it accomplish what I wished.

Gradually I became more comfortable with my understanding, although still far from an expert. I did compile and run some simple Fortran, Basic and Assembler code just to experience a typical interaction.

One frustration is that I haven't figured out how to set up dual terminal sessions yet - where I can use one as the system console and a second to do my filemanager and other work. When you have only a single terminal, the prompts are intermixed which results in confusion and spurious error messages when a key entry is routed inappropriately. The is a HP 1000 simh simulator issue.

Climbing up the RTE learning curve tailoring my system

HP 1000 SYSTEM RESTORATION

Working with RTE IV B

I fired up the machine to get more experience with the operating system. One of the investigations I undertook was listing the logical units (LUs) to understand how these worked in RTE.

First page of LU list

Second page of LU list

Once I believed I had a reasonable handle on things, I made some changes to my disk image (under simh, preserving the disk image I use on the real system). This involved doing an online system generation, which I eventually got to completion.

The last step was to run the SWTCH program which loads the new system image onto a chosen disk image. In my case I planned to just update in place, to better match the hardware I expect to use. While it appeared to work and comes up, I discovered that I couldn't run the FTN4 program (Fortran compiler front end).

I have also been fighting with the simh based HP2100 emulator, learning how to force it to do what I want. Discovered, for example, that when I was running the SWTCH command, it insisted that the disk FORMAT switch be on, apparently something that allows for a format operation. That needed a new simulator setting and rerun.

Built boot loader for HPdrive disks, installed it; starting RTE is much easier now

RESTORATION TEAM DAY AT MARC'S HOUSE

Creation of 12992H Boot Loader ROM for my HP-IB emulator

I brought the ROM binary image and a new PROM chip over to have it burned. When I install it in my machine, I can begin booting with the push of a few buttons instead of toggling in 64 words with an average of 9 button presses per word - that is roughly 585 actions I can avoid, both from the data entry and the related keypresses. Makes bootup quite a bit less painful. 

We completed the burning of the image on a MB7114H 1K PROM chip I bought on ebay, verified the content and packed it way to install in my machine when I get home. Eureka. We took the opportunity to burn another copy for Marc and then to download and burn other versions

Creation of character set PROMS for HP 264x terminals

The HP Display Enhancement Board allows for the addition of several additional character sets to a basic terminal. Line drawing is one, where you can create any drawing using characters that are composed of lines and arcs. Math symbols is another. 

The complication is that HP has two types of PROMs - alphanumeric and microvector - where the microvector ones can form contiguous ranges of pixels (e.g. lines abutting) while alphanumeric have blank pixels on the left and right for spacing. 

The microvector character sets require a 9 bit ROM - since each screen character position is a 9 by 15 matrix of pixels. HP reads out 16 9 bit elements while it is painting the character, ignoring the last of the 16 elements since it only needs 15 rows. As some of you may be saying to yourself, "I never heard of a 9 bit ROM device". 

We took one example of a microvector ROM and dumped it. The difference between the 8 bit and 9 bit ROM chips that HP used was only expressed in one pin. On the normal (8 bit) devices, there are three enable pins. The 9 bit chip repurposed one of the enable pins to deliver the 9th bit.

Marc did some pin bending and jumpering to take a pass through the ROM chip, substituting the 9th bit (enable) to the 8th bit socket with the real 8th bit pin bent up. Combining that with the dump of the chip taking its first 8 bits with no weird pin bends/jumpers, we recreated the contents.

We can't find any part numbers for 9 bit ROMs. Without a part to look for, we certainly won't find one. However, we have some ideas for workarounds. A complex solution involves a PC board in the shape of a DIP chip, with a small surface mount larger capacity chip, say 16 bit out, to deliver just the 9 bits. The simple solution is a stack of two ROM chips, with the second chip delivering just one bit to the socket position for the repurposed enable bit, but both following the same address and enables. 

Next week I will bring my Display Enhancement board that contains all the character set PROMS, allowing us to download them and burn new copies. 

Attempted alignment of repaired Diablo disk drive

Today I set everything up to do an alignment of the heads on the Diablo drive, after the heads had been carefully cleaned and replaced. This involved a setscrew to move the head position, cabling changes and scope probes on test points inside the drive. 

With that ready, it was time to spin up the alignment cartridge, let the drive warm up and stabilize, then move out to Cylinder 105 and adjust the heads for the right pattern. This is done twice, once for each of the heads. 

First, I let the heads land on a known good cartridge just to verify that we had no problems that would cause another crash. That went fine so I spun down so we could switch to the official alignment cartridge that has prerecorded patterns used to precisely locate the heads. 

However, as I tried to spin it up, the alignment cartridge platter was wobbling up and down between the heads, with a bit of a screeching sound, so I never let the heads load. I tried that previously read and known good cartridge, which had worked before, but it exhibited lesser but still noticeable wobble. Something happened to the drive and I don't feel safe loading heads until we understand it.

HP 1000 SYSTEM RESTORATION

HPdrive emulation facility

I installed the boot loader PROM we created at Marc's today - 12922H - for booting the HP-IB integrated controller disc drives hooked via HP-IB cable to the 12821A controller card. I pushed just a few buttons and immediately booted up into RTE IV B. 

RTE environment

I am now able to run the RTE IV B environment, taking advantage of the firmware assists for this that are mounted on my Firmware Enhancement Module (FEM). With the increased memory I installed, I could also try to run the newer RTE 6/VM software. 

However, I know there are firmware modules for RTE 6 that are mutually exclusive with the RTE IV B chips, since they both use the same microcode address ranges. If I can locate, download and burn these RTE 6 assists, I can install them in spare sockets on the FEM and then use the enable/disable slide switches to alternate which assist chips are active on the board, based on the OS I wish to run. 

This is a project for later. Right now I will dig into RTE IV a bit and learn how to work with it better. When I have it somewhat mastered, I can look at RTE 6 and attempt to learn that as well. 

Able to boot up RTE IVB on HP 1000 using emulated disk drive

HP 1000 SYSTEM RESTORATION

HPdrive emulation debugging

Jack Rubin and Mike Loewen offered help based on yesterday's post, highlighting a typo in the boot loader listing in the 1986 manual, the very one I was using to toggle in the loader. It causes the boot loader to loop and not read properly.

I found the ROM image on bitsavers, downloaded it and listed out the octal contents using a quick and dirty Python program. What I found was that one word of the program was missing in the listing. It was a Skip if Flag Set on the DMA (DCPC) channel and indeed lacking it would cause the errant behavior.

I toggled in the correct bootloader, fired up HPdrive and tried to do a reconfiguration boot.  It still didn't come up. My suspicion now was that I was using the wrong S register string - things like which head (surface) to boot from.

I had been using the description in the (bad) source code listing from the 1986 boot loader manual, but I found an alternative chart that was in conflict. Fortunately, I have the HP 2100 simulator. Normally you boot using a simplified simulator command boot DA0 to boot from the disk attached to DA0. However, the real hardware does not have that command. 

I modified my Python program to output the contents of the boot loader ROM as simulator commands, e.g. deposit 077700 102501 so that I could test out the exact code and settings I would use on the real machine. 

After a number of failed attempts on the simulator, I found the magic incantation to boot up RTE IVB from the disk image I have using the boot loader code. I had to set the S register to 051400 (or 051440 if I wanted to run the reconfiguration). Knowing that, I went out to the real machine.

I once again toggled in the 64 words of the boot loader, set up the correct S register value, set the P register to the start of the routine at 077700 and fired up the HPdrive emulator. When I hit run, it came right up! 

RTE is running using the HPdrive PC based drive emulator

Slowly debugging the HPdrive emulation and bootup

HP 1000 SYSTEM RESTORATON

HPdrive emulation

I figured out how to bring up the RTE IV-B image under the simh simulator, run the IO reconfiguration process and now have a disk which should boot with my existing hardware configuration.

One complexity is that simh requires the little-endian byte ordering in the file but the HP system is big-endian. Therefore, I had to swap byte order to run under the simulator and then swap back to produce the disk file that will be hosted by HPdriver. I used the DD command from the GNU Coreutils.

I ran the HPdrive software with its -d diagnostic flag which would show me seeks, but never saw anything. That doesn't mean that the HP 1000 didn't access cylinder 0 to try to load the boot code. Next time I will try an even chattier setting hoping to find out whether there is any communication over the HP-IB bus. 

There are a few possible causes for the failure to boot up:

1. The hardware for HPdrive is not working properly
2. The boot loader I am laboriously toggling in is incorrect, perhaps due to a typo
3. A different problem due to profound ignorance on my part

Further, for possibility 1, hardware problems, the issue could be in:

• PCI HP-IB card not working properly
• HP-IB cable is bad
• 12821A card not working properly
• PCI HP-IB card not in system mode

During my testing, I did discover that number 2 was partially true. That is, I blindly typed in the bootloader code from the listing, but ignored the fact that the IBL button that copies from ROM to RAM will modify all the IO instructions to use the real select code from the S register.

Problem 1 - My S register had 14 as the select code, since that is the slot where my 12821A board sits, but the bootloader as listed has a default value of 10 which is my Timebase Generator card. I modified the bootloader code to set up 14 for the IO instructions and toggled that in.

Problem 2 - My 12821A card is set up with HPIB unit number 0, same as the disk drive I am emulating on the PC side. I needed to reconfigure the DIP switches to give it a new address. I chose 30.

This run saw some activity from the PC, recognizing some traffic coming from the HP 1000 side. It didn't finishing reading in the one bootloader sector, however. I found the code looping waiting to receive the last word of the sector - i.e. it hadn't. The diagnostic trace on the PC screen didn't sound as if it was delivering the sector data, either.

Trace of HPdrive software

I can't interpret the trace well enough yet to recognize what is happening, other than it appears from the "AMIGO cold load read: unit=0" that my bootloader code did attempt to read from the emulated 7920H disk drive.

Whether I read the boot sector or a different sector (since I have to select which of the platter surfaces to boot from), it should still deliver the full sector of data, with the failure for nonboot code being manifest down in the low memory area where the data was loaded. Instead, I see the bootloader looping waiting to get the full sector.

I have to dig into HPdrive and the AMIGO command protocols to interpret this better, but at least I am making some progress. The startup messages might contain clues too, but I don't know enough to spot any right now.

Earlier startup messages from HPdrive session

Got HPDrive up but not working, other HP1000 tinkering as well

HP 1000 SYSTEM RESTORATION

HPdrive disk emulation facility

I received my HP-IB disk controller card (12821A) and cable last night, which means that I can set up the PC running HPdrive and attempt to boot from a disk image. I didn't think I have the right boot rom to access HP-IB drives, but I gave it a shot anyway, hand entering the code from the boot loader manual.

First up, I ran the tape diagnostics and ran the diagnostic for the 12821A card. Everything passed with flying colors. I then cabled up and began setting up the PC that runs HPdrive. 

Booting from a disk image presumes that the configuration of my system matches the RTE that is generated on the image. Since I have things in different orders, for example the TBG card is in 11 rather than 10, and undoubtedly many more, I didn't expect it to boot all the way up to a prompt. 

The boot loader ran, transferred something and branched to it, but that was where the software sat looping. Pretty likely it is trying to find the disc drive where it expects it. I think that I have to take one of two strategies to complete a bootup of RTE IVB:

1. shuffle my cards around to match the order in a known disk image I will use
2. use the simh simulator to run a system generation, building RTE to match my config

This will take some investigation time, both in researching the images I can find online and in figuring out how to generate an RTE IVB system from a system with different slot assignments.

I have an image from a 7920H disc drive which I can use to boot. Its configuration is:

  I/O slot 10 = 12791A Firmware Expansion Module
  I/O slot 11 = 12539C Time Base Generator
  I/O slot 12 = 12821A HP-IB Disc Interface
  I/O slot 13 = 13181A/13183A 7970 Magnetic Tape Data Interface
  I/O slot 14 = 13181A/13183A 7970 Magnetic Tape Control Interface
  I/O slot 15 = 12966A Buffered Asynchronous Communications Interface
  I/O slot 16 = 12880A CRT or 12531A/B/C/D TTY Interface (system console)

Therefore, I would have to swap the FEM and TBG back to their normal positions and shuffle everything else around in the card cage. Instead, I will do the reconfiguration bootup, shuffling IO assignments to match my machine which is . 

  I/O slot 10 = 12539C Time Base Generator
  I/O slot 11 = 12791A Firmware Expansion Module
  I/O slot 12 = priority jumper card
  I/O slot 13 = priority jumper card

  I/O slot 14 = 12821A HP-IB Disc Interface

  I/O slot 15 = priority jumper card
  I/O slot 16 = 13181A/13183A 7970 Magnetic Tape Data Interface
  I/O slot 17 = 13181A/13183A 7970 Magnetic Tape Control Interface
  I/O slot 20 = priority jumper card
  I/O slot 21 = priority jumper card
  I/O slot 22 = 12966A Buffered Asynchronous Communications Interface

I thought it best to get some experience first using simh (HP 2100) to boot up and learn how the reconfiguration works. Unfortunately, I get an unimplemented instruction aimed at the serial card which is acting as the client. Not sure what is happening, but will persist a bit with this.

In parallel, I set up the HPdrive PC to host the RTE image I have and attempted the initial reconfiguration boot process. There are several possible boot locations, corresponding to heads 0, 1, 2, 3 or 4 on the virtual 7920H but none seemed to proceed.

Next test session, I will set the PC HPdrive software into a mode that reports activity. I want to see that the software actually sees the requests from the boot loader code and provides data back to it.

HP 1000 processor memory

As part of buttoning up to prepare for my HPdrive testing, I reinstalled the cover plate that fits over the memory cards. The machine then failed its powerup diagnostics, due to the crappy ribbon cables that link all the memory cards to the processor, similar to the cables causing trouble for my firmware enhancement board. 

I removed the plate and all is well. Will leave it off for now. 

7906 disk drive

I received my disk alignment cartridge, new sealed in bag, which I can use once I have the heads cleaned and reinstalled. I still don't have the PCBs needed to use the disk service unit (DSU) tool, so the actual process of alignment remains unclear. 

HP minicartridge tape drive successes

HP 1000 SYSTEM RESTORATION

2645A terminal and tape drives

I printed the instructions for working with the two minicartridge tape drives built into my terminal, went out to the lab and attempted to follow them. I was quickly aware that the keyboard on my terminal is labeled differently than the manual. This is most apparent in the function and device control keys. 

The key labels on my terminal

The key labels that should be there

The good news is that the physical position is what matters, not the labeling. That is, if I push the button marked READ on the keyboard shown in the manual, it does indeed command the tape drive to read its file contents and display it on the screen. Thus I can use my terminal even with the mislabeled keyboard.

Based on that, I did some testing with tapes inserted into the left and right drives. I wrote some text on the screen, then did a RECORD of that onto the left tape drive. Issuing REWIND brought it back to load point and then a READ did recreate the screen contents. 

READ from the right tape, containing nothing, produced no output on the display. I then did a REWIND for both drives followed by a COPY FILE from left to right. REWIND then READ of the right drive now produced the contents I had recorded on the screen, just as it did with the left drive I originally recorded on. The drives and tapes work just fine.

I did rearrange keycaps to put the eight function keys in their correct location. Now, with a bit of careful labeling, the keyboard will be fully usable.

2622A terminal testing

I pulled the cable off the interface card and opened the hood to check that the wiring was correct, matching the documentation for the cable that should be used with the terminal. Everything was perfect and all wires had connectivity between the HP 1000 end and the Centronics connector end.

I tried some variations in data communications configurations on the terminal, but nothing seemed to get characters to display when I started the tape diagnostic asking it to use the terminal for conversational mode.

The program was looping outputting characters to the 12966A interface card, but nothing completed. My next set of tests will make use of the oscilloscope and/or logic analyzer to watch the lines between interface card and terminal.

First likely problem is a configuration mismatch, but it is possible I have bad components in the terminal. I will check that hypothesis by temporarily connecting to my 2622D terminal, but this will wait until tomorrow. I have other obligations today.  

MARC'S WORK ON RESTORING DC100 CARTRIDGES

Marc Verdiell has a large collection of different HP minicartridge drives scattered across a number of HP terminals, computers and devices. The transports for these drives are varied, both mechanically and in how the tapes are used. For example, some devices use two channels while the 2645A uses only a single wider recorded channel on the tape. 

The HP85 has a different capstan size, uses dual channels and has room to be modified to support the somewhat more reliable and modern DC2000 minitape cartridges. That modification involves increasing the height of the capstan, or in some cases milling a groove and using an O-ring to move the tape. 

There are several ways to deal with all these drives:

• continue using original DC100 cartridges
• switch to Athana remanufactured DC100 cartridges ($$$)
• switch to using DC2000 cartridges

 One can restore the capstan and make use of DC100 cartridges, as long as you can find media whose drive bands have not degraded. This is hard to accomplish. One can modify the drives to use the wider tape of the DC2000 cartridges, but the coercivity of the media is different and needs a change to write current to work well. One can use remanufactured DC100 tapes from Athana, but these also need a write current increase to work.

The DC2000 route seems obvious except when you find that some of the drive mechanisms don't allow the bigger cartridge to fit without some draconian changes to the enclosures they come in. This is true with the 2645A terminal, whose bezel would need ugly hacking. HP 85, 9825 and some other units easily allow the DC2000 to be used. There are some HP instruments that use the tapes as well and some of them don't have the room for the DC2000 clearances.

Most DC100 tapes available, even new-old-stock sealed in plastic, have their drive bands so degraded that the snap and even worse, stick to and remove oxide where they have sat in contact over the years. 3M brand tapes have the best record, but only relatively. I have a batch of them that seem to be working find in my 2645A but even these break in the 9825 whose transport is more aggressive moving tape. 

Marc discovered a way to recondition DC100 tapes to work well even with the rough treatment of the 9825 transports. First, he opens the cartridge and discards the existing drive band. Next, he reams out the rollers for the drive band slightly and cleans then oils the pins they turn on. Finally, he uses 4 1/4" Plastibands as the replacement drive belt.

With all those changes, the DC100 cartridge will work reliably and with its original media coercivity, doesn't need a change to the write bias on the transport. This allows him to continue using DC100 in the 2645A and other drives where DC2000 modification is infeasible.

This also provides a way to rescue existing tapes with data written on them, as long as the degraded original drive band didn't pull off any tape oxide. Hopefully he can gain access to prerecorded material and programs that sit on DC100 cartridges. 

Updated HP 1000 memory to 512KW, have new cartridge for 7906 drive

HP 1000 SYSTEM RESTORATION

Added memory for processor

To improve performance of the RTE system and broaden the range of software I can run, I purchased an additional memory board which arrived today. It provides 256K words of additional memory for the system, which will begin above the 256K words of memory currently installed.

I configured the board for its proper address range, installed it into the machine and ran diagnostics to verify the proper function of all the memory on the system. It reported good condition for all 512K words (1 MB) of memory.

Later I fired up the tape diagnostics and ran the more comprehensive test for semiconductor memory. It ran for quite a while, writing and reading different patterns, to be sure the new memory (and my existing memory) worked flawlessly. All is good.

7906 disc drive

Since my one disk cartridge was destroyed by an upper head crash, I needed a new one to use with my system. I found someone with new-old-stock, a blank cartridge that had remained sealed in plastic for all these years. I received it yesterday and will make use of it once I have finished aligning my repaired drive.

2262A terminal

The cable I build should be correct for hooking this terminal to the HP 1000 and it should work for conversational mode running the diagnostic monitor. My earlier tests weren't successful, which drove me to checking various documents before testing again. It is still not responding at all, with the only difference being the new cable and the 2622 terminal instead of the other cable and 2645.

Repaired minicartridge tape drives in 2645A terminal, Marc repaired an HP85 tape drive

HP 1000 RESTORATION

tape drives in 2645A terminal

The capstans on the minicartridge tape drives in the terminal had their rubber liquefy years ago, but no spare parts exist by which to get new capstans. After some research I determined I would try to build up a rubber on the capstan using a product called Plasti-Dip. 

It is a rubbery material that coats and object then dries in place. It was originally used to coat the handles of tools but some one discovered that it makes a good material as a substitute capstan for these HP drives.

I disassembled the two tape transports, taking off the motor with its attached capstan at the top. The original goo was scraped off the metal of the capstan and I began dipping it in the solution. Each layer dries in about five minutes, after which another layer can be added on top. 

To make it even and circular, we applied power to the motor and rotated it at a slow speed, enough to counter any sagging and circularize the shape. After about 6 or 8 layers, it was thick enough and looked ready to be used.

I put them back together and brought them home where I will let them finish setting, a process that should take four hours according to the instructions on the Plasti-dip can. In the afternoon I reinstalled them into the terminal, so that I could do some testing of the drives and my supply of tape media.

I ran the self test in the terminal that checks out the function of the tape drives. With tapes inserted in both drives, the test will rewind, write a 'worst case' pattern of data, rewind again, and read what it had written. It does this for each drive in turn, reporting any errors. None were found.

I wanted to boot up the tape diagnostic system and run a more detailed diagnostic program on the terminal, but discovered that no such test exists. If the terminal's self-test routines aren't sufficient, HP required a special tool to be installed in the terminal, a Cartridge Tape Unit (CTU) which would control the drives and report status via LEDs. 

HP 85 TAPE DRIVE REPAIR

I had bought a rubber 'tire' designed to slip over the capstan of an HP 85 computer, which also used the mini cartridge format and also suffers from rubber decay. They were too big for my terminal's tape drives, but I figured Marc could use them.

He popped the tire on his HP85, completed other adjustments and cleaning to the system and then conducted tests. Besides the new capstan rubber, Marc increased the erase/write current by modifying a resistor on the PCB, allowing him to use DC2000 cartridges instead of the native DC100 media. 

A bit of filing to fit the larger DC2000 cartridge, and he tested by writing, reading back and listing files. The HP85 works great now. Unfortunately for owners of the tape drives in the 2645A terminal, some mechanisms that HP built were too cramped to allow modification to take DC2000 media, unlike the HP 85. 

XEROX ALTO EVENT AT COMPUTER HISTORY MUSEUM

I attended a wonderful event at the CHM, dedicated to the Xerox Alto and its creators. Twin Altos sat on the stage as various programs were demonstrated and discussed by their inventors, along with often humorous memories of the happenings back at the Palo Alto Research Center. Among the people talking and attending a reception earlier were Bob Sproull, Charles Simonyi, Larry Tesler, Avi Tevanian, Tom Malloy, Doug Brotz, Dan Ingalls, Chuck Geschke, John Warnock, and David Boggs. It was a privilege to meet and hear from them.