Monday, November 20, 2017

Building up some chops in RTE IVB, slowly and steadily


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.

Sunday, November 19, 2017

Climbing up the RTE learning curve tailoring my system


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.

Friday, November 17, 2017

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


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.


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. 

Thursday, November 16, 2017

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


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

Wednesday, November 15, 2017

Slowly debugging the HPdrive emulation and bootup


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

Tuesday, November 14, 2017

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


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. 

Monday, November 13, 2017

HP minicartridge tape drive successes


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 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.