Saturday, November 25, 2017

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. 

2 comments:

  1. That's gonzo! it is true, in inspection in the line drawing and big char sets, pixels 0 and 1 of every row are identical. That is not true of the math set, there are clearly cases where pixel 0 is white and 1 is black. Good work, anonymous HP engineer!

    ReplyDelete
  2. Alphanumeric sets like Math are weird in their own way. Each character position on a screen is a 9 pixel wide by 15 pixel deep cell.

    For Math and other A/N sets, the 8 bit ROM delivers 7 bits of character pixels plus a half-shift control bit. The 7 bits are centered in the 9 pixel positions and then shifted half a pixel left or right.

    Yes, offset by half the timing of a pixel through some analog magic (time delay) so that the 7 pixel wide character can be slightly leftward or rightward to make spaces between characters seem more consistent (kerning).

    Still, A/N uses an ordinary 8 bit ROM, while the Line Drawing set drove all 9 x 15 pixels and originally needed a 9 bit ROM

    ReplyDelete