Creating character set Proms for 264x terminals
I brought some blank PROMs (Harris 7681) to burn with character sets, for installation in the older version B of the Display Enhancement Board. That version uses one of two types of ROM chip - a 9 bit that produces the 9 pixels by 15 lines for each character position, and an 8 bit chip that hosts 7 bits x 15 lines of an alphanumeric character plus a control bit to shift the 7 bits to the left or right within the 9 pixel screen space.
The pin layout and other characteristics of the 8 bit ROM match up very well with the Harris part number, with one exception. The Harris part has four chip enable pins, all four of which must be active to enable the chip; this is called AND logic by HP. The HP part, however, will activate when either the first two are active, or the last two are active; they call this OR logic.
Since the fourth pin is always active on the board, if the third pin were also active the chip would always be on. To prevent this, HP has a jumper that is installed for these ROM types, driving the third pin to its off state. The chip is therefore activated purely by the signals on the first two enable pins.
We burned the Math Character Set onto one of the PROM chips, but couldn't allow the third enable pin to fit into the socket, since that socket position is driven to a 0 value by the jumper. The jumper also controls the half-shift and other functions of an alphanumeric set, so it must be kept in place.
The solution is to bend that one pin (chip enable 3) up out of the socket. We hooked it to an external 1K resistor and tied the other end to the +5V supply. This activated pin 3, pin 4 is always activated, so that the ROM is controlled just by the first two enable pins - same as the HP part, but in our case the Harris chip must have all four pins activated to work.
It worked perfectly! Next up was the most challenging situation, making up a component that will act like the 9 bit ROM used by HP. Fortunately for us, some engineer at HP had figured out a way to use an 8 bit ROM and recreate the full 9 pixel by 15 line pattern of their character sets. It involves duplicating bit 0 so that it feeds out as bit 0 and bit 1, then shifting the remaining 7 bits to feed out as bits 2 through 8.
We did this by taking an 8 bit PROM, then bending pins to shift the 7 data bits over one position, driving chip enable pins 3 and 4 from the signal on the enable 3 hole in the socket, plus taking the bit 0 pin and wiring it to both bit 0 and 1 holes in the socket.
This might not be hard to do in the abstract, but the Display Enhancement Board has to sit immediately adjacent to another circuit board inside the terminal. Various rules for placement mean that we can't have an open slot to give room for our sandwich of an 8 bit PROM on top of a socket with all the rewiring.
Marc found a socket that is normally used to solder resistors or other components on top and plug into a DIP socket under it. He bent terminals, snapped a few off, but ultimately he got the PROM on top to connect to the pins that match a 9 bit HP part. Lots of delicate soldering and microscope work, but the resulting package was only slightly taller than the height of a ROM directly plugged into its socket. A PROM wired to a socket plugged into another socket - but very compactly.
This too worked perfectly. Now, Marc could add the version B Display Enhancement Board to a 2645A terminal to give it the Math, Line Drawing and Large Character sets as alternatives to the base character set. We played with the Large Character Set font, building some letters that take a 3 x 3 space on the screen (27 pixels by 45 pixels).
Final testing of Alto ethernet tool
Ken brought three of his Ethernet tools, wanting to have them all tested before loaning one to a fellow Alto restorer on the east coast and keeping one hooked to our restored Alto. The tool is based on a Beaglebone board, with a daughterboard ('cape' in Beaglebone parlance) that does level shifting between the Alto TTL levels and the 3.3V signals of the board.
The Beaglebone runs Unix, plus code built by Ken and code developed by Seattle's Living Computers: Museum and Labs. It provides file serving, boot serving and routing for the Alto, as well as routing over modern 10/100MB ethernet and to the Internet. Ken installed many applications for the Alto on their, which can be booted over the network.
However, the three Beaglebones that Ken bought didn't have the same version of Unix installed - different enough that the LCM and his code wouldn't work right on some of them. He had to load all of them with a consistent set of software and test that out.
The original code from LCM runs on a Windows based PC, which led to a subtle issue when it was moved to Unix. Windows ignores case in names, but with Unix, Pinball and pinball are two different names. This required some adjustment of naming in control files to make all the software visible.
One of the three capes built by Ken had a slightly different level shifter chip, which was enough to fail to work with the Alto. The successful capes use a 74HCT125 chip, but the failing board had a 74HC125. The lack of the 'T' for TTL compatible was enough to cause the Alto to ignore it, even though the specs of the chip versions appear fairly close.
Cleaning repaired Diablo alignment cartridges
Last week we did some drilling, tapping and milling to repair the two Diablo disk alignment cartridges we were loaned from Digibarn. Most disk cartridges for these drives are constructed with four countersunk screws holding the bottom plate on the remainder of the platter hub, but the alignment cartridges appeared to just press-fit the ring onto the hub.
Over time and with absorbed atmospheric moister, the rings became loose. One sheared right off when spun in the drive. The other was loose only one one arc of the ring, causing the platter to wobble up and down dangerously between the heads.
The only mistake we made was not controlling the oil that was needed to tap the threads into the platter hub. When the cartridge was spun up to 1500 RPM in the drive, oil migrated out of the hub in streaks on the platter surface.
We spent this session cleaning the platters, closing them up, spinning them for 30 minutes, then opening up for a next inspection. After a few cycles of this, we had no visible oil coming out of the hub. The final test will be next week when we will spin our chosen cartridge for a couple of hours and inspect carefully. If we had zero oil reaching the platter, we will be ready to try an alignment.
In order to spin the platter without risking the heads from any migrating oil, we did two things. The heads were removed, and the solenoid that forces the heads onto the platter surface was disconnected. The drive electronics got the platter up to speed and then commanded the solenoid. It assumed that the heads were now flying microinches above the platter, but it has no way of checking. It sat with the "Ready" light turned on, happy as can be.
We have two Diablo drives, each with a pair of heads we removed and carefully cleaned to like new condition. These will be remounted in the drives, but their exact position linearly from the edge of the platter to the rim must be adjusted to match the same position as every other drive.
This occurs by rotating a setscrew into the arm where it pushes against a diagonal groove in the head assembly. This pushes the head out a bit with each rotation. A standardized recorded signal is written on alignment cartridges at the factory, so that the correct position will produce a recognizable pattern on an oscilloscope.
With our repaired alignment cartridges, we have the standardized signal to allow us to get those heads pushed out to precisely the right position along the radius of the platter. It should only take an hour to carefully move each of the two head assemblies to the proper position and lock them down. First, the drive has to come up to stable temperature by spinning for half an hour, so overall this is a couple of hour task, I estimate.
HP 1000 SYSTEM RESTORATION
Diagnosing bad 12966A BACI card
I didn't make any progress today on debugging the card, but I did get a loaner card from Marc which I can use to test out my dual terminal configuration. Once I repair my card, the loaner will go back.
Since I/O is disrupted from tapes or other devices any time my defective BACI board is installed, we know that it is sending signals on the bus when it should not. One of the output drive chips could be stuck on, emitting a 1 bit at all times. Otherwise, the logic on the board should only operate when the board is addressed by its select code.
Two signals must be on to select the board, and without those signals nothing should be emitted on any output pin. If the card is responding when not addressed, it is probably a failure of the selection logic. Either this, or a stuck-on output chip, are the most likely failure mechanism that matches my symptoms.
However, there is a possibility that the selection logic itself is producing an off signal, correctly, but one of the gates that is conditioned by this signal is firing in spite of the 0 input. These internal logic gates, somewhere between failed selection inputs and stuck on output chips, could be the root of the problem.