Friday, February 16, 2018

VCF and LCM in Seattle, plus work on a battery and terminal emulation


Ken, Marc and I flew up to Seattle for the first Pacific Northwest VCF show, taking place on the weekend of Feb 10-11. It was hosted by the Living Computer Museums and Labs (LCM) at their facility.

I recognized a number of exhibitors from VCF West last year. This is the first time attempting a VCF show in the pacific northwest, thus smaller than VCF east or west which were established events. Some new exhibits and interesting presentations rounded out the experience.


The MAME (Multiple Arcade Machine Emulator) software has just included emulation of the HP 2645A terminal in its latest releases. As long as I supply the ROM images captured from a terminal, it will behave exactly as the HP terminal.

This will be useful for the owner of the linux ncurses library code to test out improvements to make ncurses fully compatible with the 2645A. It has had support from termcap for decades, but it fails to work correctly.

It is also a nice way to test out the old games code that exists for the terminal, without doing all the wiring and setup to download the code to a physical terminal until everything is working properly.


I did a test spot weld with the nickel plated steel material and an old battery. It went well, but I realized that I have a bit more fabricating to do before I weld my new packs. The cells have bare metal sides, thus they will short out one I daisy chain them together. I need to cover them in a cardboard or similar tube to avoid side to side touching. 

Wednesday, February 7, 2018

Looking at conversion of HP 2622D (250 system console) to 2621A


Converting HP 2622D terminal to 2621A for use as third terminal

I bought a terminal on eBay that is a console terminal for later HP minicomputers, but is very close to the 2621A terminal I already own. It is the same ET shape (named for its resemblance to the hero of the Spielberg film) but appears to use a different character encoding.

I hoped that I could convert my 2622D to a 2621A if I could copy the ROMs from my working 2621A and place them in the other unit. I began studying the schematics and manuals that I could locate to see if the two models are close enough that this might work.

Alas, the changes are too extensive. I suspect that if I can find the differences between the keyboards for the 2622A and the special operator console version for the 2622D, I might be able to trick the unit into working sufficiently to use as a normal user terminal.
HP 2262A keyboard (one that I own)
HP 2262D keyboard (one my terminal expects)
The keyboards are not identical and I suspect that the keycaps are wired to respond to different select codes on each. That means if I push the key R on my 2262A keyboard, that is detected by a row and column activation which on the 2262D terminal might be a left arrow, or unassigned character.

In theory, HP has wired certain row/column combinations for keyboard identification - one type of keyboard might have a diode producing a steady 1 bit at a location while the others produce 0 always. A different row/column location might be a steady 1 to signify an alternate keyboard type.

The firmware in the terminal should recognize the keyboard type from these encoded bits and translate properly, but that does NOT happen with my 2262D terminal. Whether I hook up the extended 2262A (and 2261A) keyboard or the regular 2261A/2262A keyboard, it insists on interpreting keystrokes as coming from the 2262D keyboard.

Since I don't have copies of the firmware or a listing, it seems unreasonably hard to reverse engineer the terminal ROM to make it work properly. If I had a schematic of the 2262D terminal showing its keycap to row/column assignments, I could introduce a translator box between the terminal and keyboard. However, I have been unable to find the schematic anywhere. 

Saturday, February 3, 2018

Finished archiving all known Xerox PARC disk cartridges


After attending to a few other tasks and discussions, we began archiving packs in late morning. Each had to be opened, cleaned, inspected and closed. It was then spun in the drive while the FPGA based tool extracted the disk image to its on-board memory. A utility transferred the on-board memory up to a PC over USB, where a Python program transformed the data into the Simh format for disk images.

We had 27 remaining cartridges on hand when we began; all the others have been processed already except for a small number that were previously damaged and unreadable. By the late afternoon we had 25 good images extracted and tested.

One of the packs had a divot dug into the disk surface which we expected would cause a crash; it was spun up last and did indeed crash the disk heads as they ran over the damaged area. The other pack that wasn't archived, an unmarked cartridge that had been sitting on display in the lobby of PARC, did not contain an Alto formatted data stream. It might have been used on a different computer system such as a DG Nova, but more likely it was just a virgin blank pack.

These images, as with the ones recovered in past weeks, were transferred to the software historians at Computer History Museum. We will be returning the physical cartridges to PARC, who we believe will transfer them in toto to CHM as artifacts for the museum collection.


A retiring employee from IBM Research, Jim Wyllie, found some tape reels in his office, simply marked '360'. Marc mounted them on his 9 track tape drives and extracted the data on these. Among other files, the complete source code to a mainframe based game called Space Conquest was recovered. 

Thursday, February 1, 2018

Complication in rebuilding Roomba battery pack, digging into the 1402 design and operation


I quickly discovered that I want to spot weld nickel alloy strips across the cells, not solder them, to prevent heat damage to the battery cells. For $100 or so I can buy a spot welder, but that is hardly justified to produce this single battery pack.

Instead, I poked around the internet looking at various DIY types and came to a plan for a very inexpensive, quick and dirty welder. Motorcycle battery charges capacitor bank through a light bulb, car starter solenoid releases the energy to the weld when a button is pushed. Parts are on their way here.

The nickel plated steel strips are on their way to me, while I pull together the parts for the welder itself. I will do a bit of practice welding on the old dead cells I removed before risking my new ones.


Ken Shirriff has sunk his teeth into the challenge of understanding the rat's nest of connections, relays, cam based switches and processor logic that comprise the 1402 card reader/punch. The 16 pages of diagrams have evolved over years as IBM added feature after feature to the machine, so that every page has dozens of off-page connections and some on-page connections that were not drawn as connected lines.

Trying to trace a signal involves paths through a myriad of relay contacts and cam based microswitches, introducing a time based aspect to the schematic that is hard to understand. That is, some paths are connected at specific ranges of degrees while the main motor mechanism rotates, but not others. Other paths are connected at specific ranges of degrees as the clutched part of the machine moves cards along.

With more than 16 relays, having four to six pairs of contacts each, plus about two dozen of the cam based switches, and several contact switches for card positions within the path, this is a dense mesh of signals. Trying to follow them off page, when the signal can be moving in either direction, boggles the mind. Some few places have diodes to introduce directionality, but most spots have multiple wires hooked together with unhelpful, obscure labels.

Our recently fixed problem on the 'German' 1401 system, where sequences of card read and print operations would trigger false reader errors and stop the mechanism, pulled us into this mysterious world in order to resolve the issue. However, while we could see what was failing and the conditions that triggered it, we didn't understand how the conditions arose.

Ken has reached the point where he knows why our test program - read, print, read, print, read, print, read, halt - would fail on the last read pretty steadily. The 1403 line printer operates at 10 lines per second while the card reader runs at roughly 13 cards per second. The printer itself is busy for 84 milliseconds printing a line, the remainder of the time is spacing down one line but a subsequent print operation could be accepted to overlap the spacing.

When you look at the 84ms cycle of the printer and the shorter cycle of the card reader, they lead to a delay in accepting the third print operation. That pushes off the time when the program issues the read operation, which pushes it out to a range of degrees of card reader motor rotation where the clutch does not have enough time to engage.

The clutch has an outer ring of inward facing teeth that rotates with the motor, while the inside shaft has a pawl that will be pulled out to engage a tooth whenever the clutch magnet is energized. The inside shaft is therefore connected to the motor and rotates one revolution, at which point the pawl is forced out of the teeth and ends inner shaft movement.

The cam based microswitches in the reader are set to control when the clutch magnet can energize within a motor rotation. These are the times when it is possible for the pawl to reliably engage a tooth. The signal is blocked when the window of opportunity closes, until the next tooth is in appropriate range.

We had misadjusted cam based microswitches, which allowed the read request from the processor to energize the clutch magnet too late, resulting in a missed tooth. With proper adjustment, the reader would have held off until the next tooth was in position, then clutched in. One third of a motor rotation brings each new tooth in position, so the delay would be about 25 ms before firing off the reader.

The reason for a 1/3 delay is a feature added to the card reader to speed up operations. In the original design, if the mechanism missed the window to energize the clutch, the motor would spin almost one rotation to bring the single tooth back in position. The early read feature introduced three teeth at 120 degree positions, three lobed cams for the cam based microswitches, and therefore a read request would have to wait no more than about 25 ms instead of a maximum of almost 75 ms.

The triple lobes introduce complexity in understanding the behavior of the reader, but we can simplify the logic if we imagine the machine with only a single firing point. The essential issue was still that the cam switch allowed the clutch to be energized when the shaft was too close to the tooth to reliably snag it.

Our failure was detected by the reader by a comparison between the contacts of a Clutch Check relay and other relay that will be activated only the movement of the inner mechanism which moves cards forward. If a request comes to feed a card, the Clutch Check relay activates immediately and then the clutch magnet energizes.

In a good feed, the inner shaft rotates, the cam based switches on that shaft will turn on other relays, and we will see agreement in the relay statues. If the pawl does not engage, then the inner shaft based relays don't engage, causing the mismatch with the activated Clutch Check relay. This latches the Reader Stop relay, stops further reading and triggers an error back to the processor.

For the simple case, cards have already been moving through the reader and new cards are sitting in the hopper, then each time the clutch engages, we move cards, write the presence or absence of 80 column holes for each of 12 rows the come past, and let the processor convert that into 80 characters in memory locations 1 to 80.

Cam based switches on the inner shaft (RL CBs in the diagram) determine when each of the twelve rows of the card, (12, 11, 0, 1, . . . 9) have passed under the brushes and updated core in special core planes dedicated to the card reader. The processor logic will quickly scan through the 80 locations and process the holes, updating its detected character. When the last of the twelve are processed, the card is simply finishing its movement to stop at the next location.

It is more complex when the reader has no cards in it, or the hopper emptied but one card is still inside. Two card detecting microswitches, card levers 1 and 2, activate relays CL1 and CL2 which determine whether we have the simple case or one of the exceptions just discussed.

These also participate in detecting jams, since there is a small window between cards when the CL will turn off. If it doesn't, we had a jam. Other switches are placed in the path to detect jams, but have no other role in reader operation.

If an empty reader has a new deck put in the hopper and the Start button is pushed, it must feed twice to read that first card. The first feed moves the card under the Read Check brushes but there is no card moving through the next station (Read brushes) so the actual update of core has to be blocked. On the second feed, everything is normal. The CL relays are part of the logic that determines which state the reader is in.

If either CL is activated, then there are cards in the machine, either between Read Check and Read or in the hopper. If the machine is powered up in this state, it requires you to get to the known good condition of empty card path. You do this by lifting the cards out of the hopper (CL1 now off) and doing a NPRO (non-process run out) to move any internal cards to the stacker and shut off CL2.

If CL1 isn't active but CL2 is, at the end of reading a stream of cards, this means that the hopper has gone empty. If the Start button is pushed with CL1 off, it will feed once to read the final card and the reader is empty at the end. This sets a status bit that can be interrogated to detect that the last card of some deck has been read. If Start was not pushed, then the machine waits for more cards (CL1 will activate when hopper filled) then it resumes reading with Start.

The punch side of the 1402 has almost as much complication on its own, with separate motors, clutches, card levers and cam based switches. We are ignoring that until the read side is understood. More in future posts as Ken completes his analysis.

Monday, January 29, 2018

Producing replacement battery pack for original model Roomba vacuum


The battery pack for the original model Roomba vacuum is not holding a charge as well as it did when new. The pack is a specially shaped module holding 12 NiMH cells, each producing 1.2V with a capacity of roughly 3000 mAH.

They are chained together to yield 14.2V for the pack, but with no circuitry to distribute load or even out charging, which is why they degrade over time as do most simple-minded serial chains of battery cells. All but one of the serial connections are tack welded metal bridges, the remaining one is a carefully created fusible link tack welded across one pair. This provides overcurrent protection for the pack.

One final aspect of the pack is the inclusion of a varistor, a resistor whose value varies with temperature. This thermistor is wedged in the gap between four adjacent cells. It is used by the charging circuitry to lower the incoming voltage or cut it off if the cells are getting too hot. The pack as a +, a - and a thermistor contact.

Opened battery pack, white fusible link on left, thermistor next to it
My plan was to replace the 12 cells with similar or higher capacity NiMH cells, soldering the metal bridges and one fusible link between cells to place them in series. These new cells had to fit within the original plastic package, in order for the repaired battery pack to fit back in the Roomba.

I found some high capacity battery packs intended for use in remote control cars and other toys. These packs produce 7.2V at 3500 mAH capacity by bridging six cells together. These RC packs are plastic wrapped, with the series connection made inside, and two wires coming out at one end.

RC pack with six 1.2V cells inside
I had hoped to place two of these packs in the original battery package, tie one pack to the other with the fusible link, wedge in the thermistor and close it up so that it now chained 12 cells to produce 14.4V. I found that the RC packs were just a bit too large, particularly the end caps which were wider than the two columns of cells.

RC pack almost fits inside
End cap which is too wide to fit RC packs side by side inside the Roomba package
I considered various means of grinding down the inside of the Roomba package and the end caps of the battery packs, to force them inside together. Even the unwrapped cells themselves are too wide to fit side by side lengthwise. While grinding may work, the most certain method is to fully disassemble the RC packs and find myself with 12 NiMH cells of exactly the right type.

RC pack without endcaps still wider than half the package width
I can solder wires and the fusible link across the terminals to chain them in series. More work but it will fit better and more closely match the original battery construction. I began to work on the end caps of one pack to determine whether that partial method is at all feasible, since it avoids much of the soldering necessary with the full disassembly route.

RC pack with plastic removed, cell to cell connection exposed on right
I found that the cells are tack welded with strips of metal, just as with the original Roomba construction, but the strips of metal are not long enough to fold the cells in alternating directions as is required to have them sit vertically in the Roomba package.

Existing metal plates bridging cells in the RC pack
I had to break off all the metal links from the positive pole of the cells, to separate them and to test their fit inside the Roomba package. I found that they will indeed fit exactly as they should inside when the cells are each stacked vertically. Of course, they must alternate up and down pointing cells and the connections run down one column, cross over at the end and run back on the other column to end up with the correct series polarity.

Test fit of the cells sitting vertically, but not in the alternating direction ultimately needed

I then removed the other end of the metal plates from the negative can of the cells and removed the red and white wires, leaving me 12 unattached cells to begin soldering together. I will have to find and cut some flat metal strips, as the proper diameter wires would take up too much vertical space around the cells. I to source the strips and cut them to length before I can continue with this project.

Sunday, January 28, 2018

HP 2621A terminal successfully connected to Altair 8800 replica (AltairArduino)


I switched over to my Bluetooth to serial module, since I was having no luck communicating with the USB to serial module from last week. This module, by Parallax, claims that I can talk to it over the serial link, typing $$$ during its first few seconds to switch it to configuration mode, where I will get a CMD prompt.

With the connection set up from my RS232 12V/TTL shifter module to the Bluetooth module, I can type $$$ and see it echoed back but never get the CMD prompt. Incomplete and vague manuals again. This is the trade-off for inexpensive modules where no budget is available for tech writers or usability engineering studies.

I kept bashing away at it, studying the materials from the maker of the board as I attempted to get it to configure. Even when I can talk to it for configuration through the serial end, I have the much more difficult problem of causing the bluetooth in this unit to communicate correctly with the bluetooth module inside the Altair 8800 replica.

At this point, I would be ready to rip out the bluetooth inside the Altair replica and wire RS232 directly from it to my level shifter board. I was not sure if there is any dialog required between the bluetooth module and the Arduino inside the replica, but I my investigation showed that my serial level shifter card could be easily connected in place of the bluetooth module inside the replica.

I tried one more thing before taking the radical step of removing the radio. I removed a jumper on my new bluetooth module, and got it to answer back properly to my $$$ prompt. It was forced to 9600 but I connected, per the instruction guide, at 115200. It echoed my characters but didn't recognize them internally.

Now I had the task of configuring it properly to connect to the other bluetooth module inside the Altair replica. I took a bit of time to do some serious research and plan out the configuration.

I looked up the bluetooth ID of the internal radio in the replica and set up the new external module to attempt to contact it by that address and with the passcode it wants. I was not sure whether it would pair properly, it was possible I needed to be connected to both sides simultaneously.

The new module, in its auto-master mode, immediately connects to the bluetooth module inside the Altair replica. I was able to switch the replica console over to the serial port (i.e. through the pair of bluetooth modules and then into the PC serial port) using the AltairDuino configuration menu. At this point, all I need to accomplish is the wiring of the serial port itself to the Centronics 50 connector for attachment to the HP terminal.

This was built into a small hobby box - bluetooth module, RS232 level shifter and a connection to a leftover wall wart power supply for the 5V to the modules. The cable was completed, including the essential wire between Centronics pins 14 and 45 that brings +5V to tell the terminal that it has a live link.
Building magic box to link Bluetooth to HP 2621A terminal
I brought everything out to the workshop to do a first test, after a final peek at the HP manuals to be assured they were true RS232 signal levels and not TTL limited. I turned on the terminal, powered up the Altair replica and my magic box.

Altair 8800 replica with power supply
Magic box with Centronics 50 connector on left, power supply on right
It worked right away. I used the laptop over the internal USB link to the replica to start configuration, switch the serial port over to the bluetooth module inside, which was live linked through my magic box to the HP 2621A terminal. I saved the config change and tried a few cycles of plugging in and powering up everything.

It all worked well, so I fired up Zork 1 to test out the terminal running this classic game. Worked great and satisfies my objectives. I can now work with a 1970s terminal to speak to the 1970s era Altair 8800 (replica). I swapped virtual floppy drives to restore a saved game and played for a few minutes.

Altair replica running CPM with Zork 1

HP terminal with the CPM session and Zork 1 running

Saturday, January 27, 2018

Processed more PARC cartridges, validated latest ethernet tool, and worked on Altair replica to HP terminal link


Before I can hook my USB to CDC mode TTL serial to the TTL to RS232 level serial converter and ultimately to the 2621A terminal, I have to talk to the USB device and update its communications settings. That conversation only happens over the wire TTL serial side, with the USB cable disconnected.

I have a DB9 serial connector on one of my computers, which I will use to configure the USB to serial module. I found an old DB9 based serial cable, cut it apart and wired it up to the module, crossing TX and RX. I hooked CTS and RTS together to keep the PC side happy. 

With 5V power applied to the module, I fired up a simple terminal program on the PC and did the configuration. I had to set the BAUD rate to 9600 and the transfer to byte by byte mode, without local echo.  However, when I hooked it up to the PC serial port and tried to communicate, I got nothing. That was true whether RX/TX were swapped or straight. 

I haven't used the PC port before, so there is a possibility that the hardware doesn't work right. I needed to figure out where the problem lies. It is possible it is that I don't have the magic combination set right, among all the darned DCD, DSR, CTS, and RTS signals, thus the port is blocked. 

The quick test was to hook the RX and TX lines from the PC cable together. Immediately, I saw my typed characters echoing back on the terminal program. This proves that the serial port is working, thus I have to focus in on the USB to serial module as the fault or something in my setup. 

Once I have a working link to the Altair replica, either this USB module or a Bluetooth to serial module,  I can wire it to the TTL/12V level shifter board. I looped CTS and RTS to the 12V side of the level shifter, which will in turn be wired to the Centronics 50 connector that will plug into the HP terminal. 

We were in Fry's today to pick up more 99.9% pure Isopropyl Alcohol before cleaning disk cartridges. I took the opportunity to grab a Bluetooth to Serial module as a backup means of linking my Altair to the HP terminal. 


Friday morning I aligned the drives with the recently cleaned heads, brought all forty cartridges down to the lab area and began archiving. We had run out of isopropyl alcohol to clean the surface of each disk and the heads, requiring a run to buy more supplies before continuing after lunch.

By the end of the day, we had processed fifteen cartridges, extracting each image and testing it under Contralto. We only had to wipe some fine oxide residue from the heads two times. The result was 13 good disk images.

The reason it wasn't fifteen was twofold. First, we found that one of the 15 cartridges had been previously archived by us, but our little stick on label (A) had fallen off at PARC. Second, we found another of the cartridges had two dings on the surface of the platter - small impact holes that exposed the aluminum underneath the oxide coating.

Those holes would likely cause a head crash, thus the disk was appropriate marked and skipped. These 13 recovered images were delivered to the software preservation archivists at Computer History Museum.


Ken put his latest rev of the board through a test program, proving out its full and correct operation. This board included all the pullup resistor and ringing suppression components he had added externally to prior boards.

One snag hit, however. The microSD card with the code for the device had fallen out back at his home, requiring Ken to rebuild the development environment on his laptop and then recompile the code for transfer to a new card. That took the remainder of the morning, before he could conduct the tests above.