Producing replacement battery pack for original model Roomba vacuum

BUILDING REPLACEMENT ROOMBA BATTERY

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.

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

BUILDING LINK BETWEEN ALTAIR 8800 REPLICA AND HP 2621A TERMINAL

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

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

CONNECTING ALTAIR 8800 REPLICA TO HP 2621A TERMINAL

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. 

ARCHIVING MORE XEROX PARC CARTRIDGES

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.

VERIFYING THE VERSION 3 BOARD FOR KEN'S ETHERNET TOOL

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.

IBM 1401 reader-print problem fixed; last batch of disc cartridges from Xerox PARC picked up for archiving

WORK ON READ-PRINT ISSUE OF IBM 1401 AT CHM

Today we met at Computer History Museum to work further on the sporadic failure of the 'German' IBM 1401 system, where its 1402 reader will suffer Reader Stop errors while processing certain sequences of read card-print line commands.

The failures occur while the command to read a card is slightly delayed by the 1403 printer logic copying the print line out of core memory. That 2ms delay of the request is enough to cause the reader to accept the feed request, but the clutch itself does not engage. Error checking circuitry detects this fault and halts the reader.

We suspected that timing of some switches activated by cams was the cause of the problem. Last week we adjusted the primary cam that determines when the feed request from the CPU will attempt to latch the clutch and rotate the card feed mechanism. This is RC6 - continuously running cams are named RC and hooked to the motor so they rotate any time the motor spins.

The cams have tight tolerances - the times listed for the switch to make and break must be achieved withing +0 to -2 degrees, ergo the cam makes at 270-272 and breaks at 340-342 degrees. I had that set to 270 and 340 last week, but we found that another cam in series with RC6 was blocking the operation.

Cam RL10 should make at 270 and break at 340, with the same margins, but this was off by at least 5 degrees. RL named cams turn only with the card feed mechanism - once to move cards one station forward.

The path is hopper to read check to read station to stacker, one feed cycle per move. Usually, a different card is at each stage of the path - card 1 is moved to the stacker while 2 is moved to the read station, 3 is moved to the read check station and 4 is next sitting in the hopper.

To get to the RL cams, quite a bit of the top and side cover of the 1402 must be removed, but once we had access, I tested the cam. We found two problems - the duration and the start point.

The number of degrees from make to break should be 70. If the switch is too far from the cam, the duration is shorter than 70, while a switch that is too close to the cam will produce a longer duration. A setscrew, held in place by a jam-nut, determines how far away from the cam that the switch can move. We loosened screws, changed the setscrew and ended up with precisely 70 degrees of contact but the start point was more than 5 degrees to late.

The start point is controlled by the rotational position of the cam around the shaft that spins all the RL cams. Two setscrews hold the cam in place, or when loosened allow it to be spun forward or backward. We moved the cam until we had it making exactly at 270 and, thanks to the duration we adjusted earlier, it broke at exactly 340.

With the setting corrected, we closed up the reader and ran our test programs again. We had a trusty hand program which executed read-print-read-print-read-print-read-halt and then branched back to the beginning. The last read in the sequence would suffer a Reader Stop most times, because the clutch failed to engage during that cycle. 

This program ran a dozen times with error. We replaced the halt instruction with a branch to produce a continuously running loop reading and printing. No failure in many hundreds of cards. We then ran an "80-80" listing program which looped, reading a card and printing its contents on the 1403, again running as many times as we tried it with no errors.

We can declare this problem fixed. At some point, it would be nice to adjust all the other RC and RL cams, making everything conform to the specs, but right now we have no symptoms and could turn the system over to the demonstration team for regular use.

SWAPPING TO LAST BATCH OF XEROX PARC DISC CARTRIDGES

We brought the group of 25 cartridges we recently archived over to PARC and were given all the packs they could locate. We had 36 numbered cartridges, tied to their inventory of disks, plus 3 packs that were labeled but not numbered nor listed on their inventory. Finally, on our way out with the boxes, we were handed a cartridge that was on display behind the Alto in their lobby.

Starting Friday we will work our way through the discs until we have them all processed. The inventory of PARC disks lists 11 more cartridges that they can't locate now, mostly belonging to Alan Kay. If they do find them, then we would have one more batch to process in the future. 

Building connection from Altair replica to HP 2621A terminal, rebuilding original Roomba battery pack

ROOMBA REPAIR

The Original Roomba vacuum cleaner that I repaired recently is working well at my daughter's apartment, but the battery pack inside is a bit old and doesn't give a full 2.5 hours of operation on a charge. 

I bought a used battery on eBay, took it apart, and prepared to replace the bad cells with new ones. Roomba uses 12 1.2V NiMH cells inside the yellow plastic battery enclosure, chained end to end. Once a single cell goes bad the entire pack is bad and they have no charge leveling circuitry inside.

12 cells chained together inside Roomba battery case

There are two additional features inside the pack - a fusible link and a thermistor - that provide protection from short circuits and overheating cells. I will install these on the replacement cells.

Rather than buying 12 sub-C sized cells and soldering all the straps to chain them in series, I bought two 7.2V battery packs designed for remote control cars. These have 6 1.2V NiMH calls in them, provide 3800 mAH compared to the original 3500 spec, and two of these will fit inside the yellow Roomba battery case. 

RC battery packs to replace the original cells

Once they come, I will use the fusible link to connect the two packs together, install the thermistor against one of the cells and close up the pack. 

USB SERIAL TO REAL RS232 CONNECTION TO TIE REPLICA ALTAIR 8800 TO HP 2621A

My parts arrived and now I can begin wiring together everything I need to hook my Altair 8080 replica to a true serial based CRT terminal. The chain connects the Native USB port of the Arduino Due inside the replica to a level shifting board that produces 12V RS232 levels, then hooks this onto the HP terminal using a Centronics 50 connector. 

I removed the DB9 connector on the level shifter board and direct wired it to the Centronics connector. The level shifter has to be wired to loopback CTS and RTS on the RS232 level side, since the USB to TTL device produces only RX and TX, it does not handle RTS and CTS.

My cabling will force DTR active, telling the terminal it is connected and cause the terminal to issue CTS to the far side. This may take a bit of fiddling with the control signals on the terminal to get it talking but eventually it will work.

There are commands I can issue to the USB converter board to set its speed, parity and other parameters, which it will store and retain in its onboard EEPROM. I should probably set the converter to the same speed as the terminal will operate, since there are no pacing signals such as CTS to avoid overruns.

Both of my boards need a source of 5V DC for power, which I can either draw off the replica or furnish with a separate supply. The decision is not yet made. I do want to put all this in a convenient box for neatness and to protect the small boards. 

Finished batch of PARC disks, got stand for my HP 2621A terminal

HP 1000 SYSTEM RESTORATION

Stand for 2621A (ET) Terminal

A friend found a base for my ET terminal and gave it to me, along with some cables, a keyboard and boards for the HP 1000 system. All I needed was the terminal and keyboard, the rest went to Marc to support his big HP collection.

FINISHED BATCH OF 25 CARTRIDGES FROM PARC

We finished up the remaining cartridges from the group of disk cartridges we borrowed from Xerox PARC, producing archive images of most of them. A few were already scratched, with two having serious bends to the edge of the platter, but most were read okay.

These old disks have surfaces that are deteriorating - specifically the binder that holds the iron oxide to the aluminum platter is allowing some release of surface powder. These build up on our disk heads and either cause a crash immediately, if sizable, or require us to remove, clean, remount and realign the heads. 

These will be returned to PARC and a new group of 25 cartridges will come over to the lab for archiving in the coming weeks. Eventually everything will be saved from these packs and they can be delivered to the Computer History Museum physical archives. 

More work on 1401 system read-print issue at Computer History Museum

REPAIRING READ-PRINT ISSUE WITH IBM 1401 DE SYSTEM AT CHM

The focus on Wednesday was on the timing of various cam based switches that form the logic inside the 1402 card reader/punch. We looked in particular at everything involved in clutching the mechanism to turn the rollers and other gear that moves a card forward one station.

Several cam based switches, called circuit breakers (CBs) by IBM, are involved in this process, particularly RC5, RC6, RC7 and RL10. RC numbered CBs are those that run continuously with the main motor, even when the mechanism is not moving a card through the machine. RL numbered CBs will operate only with the mechanism that performs the card feed.

These CBs in turn control several relays, such as the clutch check relay 10, and lead to the activation of the reader stop relay 4. The wiring diagram is somewhere between obscure and impenetrable, as I have mentioned before, but we gradually mastered the portions involved in this problem we are debugging.

The 1402 originally operated by feeding cards in one rotation of the mechanism, always taking 360 degrees of rotation or about 18ms at the rated speed of the reader mechanism. This meant that when a processor request came in to read another card, one could wait between 0 and 18ms before it commenced, depending on where the spinning mechanisms were in their 360 degree rotation.

To increase effective speed, IBM created an early feed feature, dividing each rotation into three equal 120 degree segments. Now, when a CPU request arrives, the wait to honor it varies from 0 to 6ms, only until the next 120 degree segment comes around.

Now, most of the CBs have three lobes, to provide the same logic for each of the three 120 degree segments. The first one we adjusted, RC6, is the primary CB that determines when a CPU request will activate the clutch. One of its three lobes is designed to close the switch (make) at 272 degrees and open (break) at 342 degrees, with a tight tolerance that requires it occur between -2 and 0 degrees of the target value.

The CBs are adjusted two ways. First, the cam itself can be rotated around the axle that turns it, to changes its timing earlier or later in a rotation. Second, the contacts can be raised or lowered from the center of rotation, causing the duration of the activated switch to lengthen or shorten. Adjustment requires that both be controlled to get the make and break timings correct.

Advancing or retarding the cam around its axle is done by loosening two setscrews that hold it to the axle. These require Bristol wrenches, similar to Allen wrenches but having four lobes rather than the hexagonal shape of Allen. We loosened the setscrews but the cam would not move relative to its peers at RC5 and RC7.

We hooked an ohmmeter across the contacts to do the timing, hand rotating the overall mechanism with the timing wheel which is marked with 360 degree lines. First, however, the cam had to revolve on the axle to move its start and stop timing.

It appears that the cam was partly adhered to its peers by corrosion, so that some mechanical force was needed to free it up. The access to the cams is quite restricted, otherwise we could have simply used pliers of some sort to turn it. Finally, I could apply sharp impacts sufficient to break the corrosion but not the mechanisms.

The second adjustment, duration of the switch, is controlled by a screw, a setscrew and a jam hexnut. The jam nut holds the setscrew in its position, while the setscrews is a stop for how high the switch contacts can move. Finally, the screw itself locked the contacts down or allowed them to slide up and down.

I finally got the height of the contacts correct for exactly 70 degrees of make time, then rotated the cam to cause the make to happen right at 270 degrees. It ended precisely on time at 340 degrees, so we were done with this adjustment. The ohmmeter showed the make and break as we slowly rotated the timing wheel.

However, when we turned on the dynamic timer with the reader operating under power, it showed that circuit energizing at 275 degrees but ending on time at 340,. Looking at the schematic and then scoping the circuit, we found that CB RL10 is misadjusted. It is in series with RC6 and since it doesn't make until 275, that delays the activation.

The RL CBs are mounted in a much more inconvenient location in the machine, requiring the removal of part of the top cover near the card hopper before we could reach and adjust them. We didn't have enough time left in the day to do this before the public demonstration started, thus we left it to the next session.

The reason that RC6 and RL10 are in series is that permission to fire the clutch depends on two things. The position of the motor assembly must be in the right 70 degree portion of its 120 degree segment, but also the feed mechanism must not already be in motion from a prior clutching.

Thus, RL10 sits activated when the feed mechanism is idle, allowing RC6 to determine when to start a card read. However, once the feed mechanism is moving, RL10 blocks clutching until the feed is advanced enough. That is, reading a card takes the entire 360 degree rotation to move it forward and past the 12 rows of holes, even though we can start this process at any one of the three 120 degree segments.

Therefore, RL10 imposes the 360 degree cycle restriction after which RC6 determines the next 120 degree segment to permit clutch activation. In addition to this complexity, CBs RC5 and RC7 control the timing of the clutch checking that ensures a clutched feed mechanism actually moved.

When RC6 lets the CPU request activate the clutch, it first energizes clutch check relay 10 then with a slight time delay activates the clutch itself.  RC7 is a set of lobes which control when the error check takes place. This CB makes and breaks opposite to RC6, activating during the span when RC6 is open. These two cannot overlap activation and there is a required gap between the two sufficient to let the clutch engage and begin moving the feed mechanism.

RC5 is another trilobe cam, with the same timing as RC6, but used to activate other relays that ultimately lead to the checking that triggers our reader stop condition. We need to get the timing of RC5, RC7 and RL10 corrected before we can be sure that our reader is working according to its design. 

Using HP 2621A terminal with Altair 8800 replica

ALTAIR 8800 REPLICA CONNECTED TO HP 2621A TERMINAL

I recently bought and built an Altair 8800 replica - uses an Arduino and front panel interface - which I access over bluetooth to a modern PC running a terminal emulator. The modern hardware distracts from the sense of using the Altair, so I decided to connect it to one of my ET style HP terminals.

Arduino based Altair replica

The 2621A is called an ET type because the shape of the monitor head on its pedestal looks a bit like the alien from the ET movie. It runs over RS232, usually hooked to my HP 1000 minicomputer system. However, it could be driven by any system, using ASCII input and output.

HP 2621A "ET" terminal

A few minor difficulties sat between me and immediately connecting the terminal:

• Lack of a serial port on the Altair
• 12V levels on a real RS232 interface
• Terminal uses a Centronics 50 connector
• No cable to make the connection. 

The Altair replica does not have a real RS232 port, although it emulates the serial ports of the 88SIO, 882SIO and 88ACR cards from a real Altair. However, it has two micro USB ports on the Arduino and a bluetooth module inside. There is a simple configuration program built into the replica to assign these real ports to the virtual Altair serial ports.

On a recommendation from other builders of the Altair replica, I ordered a device from Hobbytronics that will plug into the Arduino native USB port and produce TTL voltage level RS232 signals. This gives me the protocol but not the voltages.

Convert native USB in CDC mode to TTL RS232

I then procured a MAX2232 chip based level converter which interfaces a TTL level RS232 device such as the Hobbytronics box with a 12V level RS232 device. This gives me the voltages but not the cable or connector.

Convert TTL RS232 to true 12V RS232

Next, I have a male Centronics 50 connector on order, which I will wire up between the level shifter board and the terminal. That resolves the last issue and provides everything I need to begin using the 2621A terminal with the Altair 8800 replica.

Centronics 50 male connector plugged into HP 2621A terminal

The bluetooth connection in the replica will let me transfer files to act as cassette tapes, paper tape or xmodem mechanisms to get external files into the Altair replica. It has simulated floppy and Pertec hard drives inside the replica, hosted on an SD card, thus I can do much of what I want without the need to access virtual paper tape or other files from outside the replica. 

BUYING CARPET - INFORMED CONSUMER WARNING

My home office needed a makeover now that I am retired and we want to use the space for storage. One element of the refresh is to replace the carpeting that is old, ripped and stained. The room is 14' 10" x 8' 3", a simple rectangle shape.

My wife and I selected a carpet that comes in both 12' and 15' wide rolls, since that way the room could be covered with no seams at all, just a 8+ foot length of 15' carpet. We bought from Home Depot and had the tech out to officially measure the room. Next step was to get a quote. Based on the carpet we chose, priced by the square foot, we guessed that the total cost would be in the 400-500 range.

In spite of the use of square feet in all the advertising and quoting, carpet is actually sold by the yard and you pay for the entire width of the roll times the length needed to cover the room. Knowing that, I expected that I would pay for 15 square yards - a 15' wide roll is 5 yards wide and the nearest size in yards to cover the 8+ foot room is 3 years- thus 5x3 yards of material.

We received a call with our quote which was for over $600. This was for 20 square yards of carpet. That told me that they had simply chosen the 12' wide roll, cutting it for the 15' length of the room. 20 square yards when all it would take is 15 square yards if the wider roll was used.

Fortunately we knew what was happening and could ask them to recalculate using the 15' roll. As expected, the cost came out right where we expected give that it now required 9 feet to be cut from the 15' roll. The deal was concluded and we expect the 15' segment, a 'special order' not in stock, to arrive at the installers in about two weeks after which they can come and install it.

We saved 1/3 of the cost of this job because we knew how they worked and the best way to lay the carpet. Even though when we first ordered the carpet we specified the 15' wide roll, and when the tech came for measurements we asked him to note that 15' rolls should be used, the quote desk approached this in a simple minded way that ballooned the price unnecessarily. 

Retrieved more images from the Xerox PARC archives

ARCHIVED 25 DISK CARTRIDGES

Today we set up our production line to process the 25 disk cartridges I retrieved from Xerox PARC earlier in the week. First we open each cartridge to inspect and clean the disk surfaces. Next, we read the entire contents of the cartridge into my FPGA based disk tool from a Diablo disk drive.

Next, the data from the disk tool is uploaded to a PC and formatted into Simh format. Finally, we check that each image boots up or can be opened. If there are passwords protecting the cartridge, we use a program to unlock them.

By the end of the session, we had 13 successful extractions of a cartridge and found two cartridges irreparably damaged when we opened them. One was missing the protective cap on the cartridge, exposing the edge of the platter where it had become bent at some point in the past.

There were three cartridges that had minor crash damage, which we will attempt to read as the last three cartridges once we deal with the other six cartridges on hand.

We picked up enough oxide to need to remove and clean the heads on our drives before we take on the last nine packs during the next session. We have found that we can clean the heads in about 90 minutes, thinks in part to the ultrasonic cleaner that loosens the impacted oxide on heads. Then, we can complete an alignment in less than an hour.

Diagnosing 1401 read-print issue, getting Fortran compiler running on 1401

ARCHIVING XEROX PARC CARTRIDGES

In preparation for our session on Friday, I drove all the previously archived cartridges over to PARC and exchanged them for 25 new ones. These were the top picks from a prioritized list of the 75 remaining cartridges from their database of disks. The expectation is that we can complete a batch of 25 in a week or so, then exchange those for the next group.

DIAGNOSING 1401 READ-PRINT PROBLEM

Both Ken and I brought in modern scopes to help shoot the problem, but we are still not certain we know the precise failure mode, due to the complexity of the 1402 card reader logic. That logic is implemented with relays, cams and microswitches, but as IBM added new feature after new feature to the unit, they took the easy way out with schematics. 

Rather than redrawing circuits to keep it clear, IBM added many, many off-page connectors for these changes such that tracing out the real circuit is extraordinarily difficult. Thus, we have a hazy idea of how the machine is actually functioning, with more than forty cams, about fifty relays, perhaps 80 diodes, and each relay has four to six independent sets of contacts. 

By the end of the day, we had narrowed our focus down to a pair of cam switches, RC6 and RC7. These are running continuously as long as the motor of the 1402 is spinning, while other relays named RL# operate only when the clutched part of the mechanism is rotating - during the feeding of cards. 

RC6 is the main timing point determining when the request from the 1401 will activate the clutch magnet. This happens at three equidistant spans around one 360 degree rotation of the motor wheel. As RC6 allows the processor request, first the pick coil of relay 10 (Clutch Control) is activated and then after a short time delay through an RC network, it activates the clutch magnet.

The clutch engages and begins moving the feed mechanism through its rotation, moving a card from one station to another. The stations are feed hopper, read check, read and stacker. Cam RC7 is set to complete a circuit during the intervals in between the three that enable clutching. Cam RC7 sets up the error check, where relay 10 is on if the processor requested to clutch but off otherwise

The Reader Stop condition occurs because the error check time determines that the clutched mechanism did not rotate, the feed relay 6 is not activated, but relay 10 is on. Essentially it tests to see if relays 6 and 10 agree, but only during the time that RC7 allows the check. 

RC6 and RC7 have only a 5 degree separation between their active times. For example, RC6 should switch off at 102 degrees and RC7 turns on at 107 degrees. When we checked the timing of RC7, it was turning on early, at 105 degrees. Another test seemed to show that RC6 is working late, turning off at 105 degrees. 

This overlap of RC6 and RC7 sets up a race condition where it is possible to falsely detect a failure to engage the clutch when in fact the reader is working properly. We will adjust the two cams to increase the gap between their operation, in our next Wednesday session. There may be other cams involved in this failure as well. 

FORTRAN COMPILER RUNS AGAIN ON 1401

Marc Verdiell and Mike Albaugh have been working for a while to produce a working tape of the 1401 Fortran II compiler. It is a 63 pass compiler (!) that will work even in a small memory system. Having overcome the final barriers they were able to compile and run a few sample programs today. 

Next up for the team is to accomplish this with an enhanced Fortran II compiler, a Fortran IV compiler, a Cobol compiler and hopefully RPG if we can locate that software. We also have a card oriented FARGO program to get running. Fargo was a predecessor to RPG, both of them are meant to make it easy to replace plugboard based accounting systems. 

Working on 1401 read-print issue, assisting a new IBM 1130 restoration effort

ADVICE FOR IBM 1130 SYSTEM RESTORATION

I was contacted by an official of a museum in Slovenia who has an IBM 1130 in the collection which they are planning to restore. I expect to share documentation and answer questions as this work proceeds.

They have a small machine, 4K or 8K, with the Garnet Rose color scheme offered by IBM during the S/360 and 1130 era. The other common color was Classic Blue, but rarely you could see a color such as the Sunshine Yellow that my personal 1130 sports.

DIAGNOSING WRITE-PRINT PROBLEM WITH IBM 1401 AT CHM

The 'German' 1401 system at Computer History Museum has a problem when rapidly reading cards and printing their contents on the 1403 printer. After some number of cards, the 1402 reader will enter a Reader Stop check condition.

We have a tight hand program which is very reliable in causing the check condition - read, print, read, print, read, print, read, halt - which will fail on the last read command virtually every time. This has been helpful in scoping signals to find the cause.

After working half a day on Monday, we narrowed the problem to one part of the Reader Stop circuit - not the card jam detection or other portions, but the part that ensure that the reader responds correctly to a read command.

To verify its operation, the reader compares the state of two relays, clutch check and read cycle. If they don't agree, it would mean that the CPU requested a read but the 1402 didn't move, or that the 1402 has moved a card but the CPU did not request it.

There is a resistor-capacitor network on the line to the reader clutch magnet, which delays when the clutch activates. The same activation signal goes directly to the Clutch Check relay. This means that Clutch Check is active while the mechanism begins its 360 spin of the cycle wheel.

Once the wheel has moved a bit from the idle position, it activates the Read Cycle relay. Then, later in the rotation, microswitches on cams cause the circuitry to compare the two relays condition. If they don't agree, a Reader Stop relay is engaged and the 1402 enters the check condition.

Disconnecting parts of the Reader Stop relay pick coil circuit, we isolated the stop condition to the circuitry looking for disagreements between the Clutch Check and Read Cycle relays.

To verify this, we removed the Clutch Check relay from its socket, which not only stops it from activating but also removes contacts necessary to detect the error condition. The reader ran without any stops in this condition.

We will need to do more testing to discover which case is being detected - which is engaged and which relay is inactive - but that will wait for our Wednesday work session. There is something about the delayed request for reading from the processor that triggers our error, but we don't yet know the details.

Why is the read request delayed? It is because of the relative timing of the printer and card reader, such that the last read command in our test program is occurring while the printer is copying its line of data from core memory. Since reading cards requires access to the core memory in real time matching card movement, the reading must be delayed while the printer logic is touching memory.

The printer in our installation has a speedup feature called a print buffer. Thus, when a print request is issued, the logic first copies all 132 characters of the print line from core memory and stores them in a special dedicated but small core memory. It requires about 2ms to copy the 132 characters over, after which the core memory is free for the long additional time it takes to fire printer hammers and space the paper.

In our test program, the 2ms transfer of printer data is underway when the last read command is issued, thus the CPU will block the read request from the card reader until printer transfer is complete. Thus the start of the read request to the 1402 is delayed a bit compared to the preceding read commands. 

Cataloging the archived Xerox PARC cartridges, overcoming password protection, work on 1401

ALTO DISK CARTRIDGE ARCHIVING

Developing record of all directory entries

I mounted and booted every cartridge image we had archived so far, issuing the ? command to list the directory of each. I did this under the Contralto simulator and took screen snapshots with that program. Each was a PNG format image file of one screen of the output.

These are all stored allowing a fairly quick scan through all the images to locate any program or file of interest (by name). A future effort might extract the file names themselves and create a quick machine searchable document.

Switching off password protection

Ken Shirriff did some investigation and determined a way to switch off password protection. It involves finding a given file, Sys.Boot, then looking at a password control field 768 bytes inside. That field contains a control flag, some SALT values and the hashed password.

Using a brute force attack, Ken recovered passwords that will unlock the six cartridges we have encountered so far that are protected. I decided to build a Python program to to this.

In order to accomplish the function, I would need to find the directory on disk, traverse its entries and locate the one for Sys.Boot. Then, with the file located, I would need to move 768 bytes into the file to capture the password control field.

The program can then store a null flag into the field and rewrite that sector to the disk image, thus switching off password protection. Alternatively the program could try a brute force attack to retrieve the password itself. 

There are complications in chasing the directory sectors, as individual directory entries can span sectors. Too, the location of the directory and of Sys.Boot varies across different disk images I have examined. I am searching for a guaranteed method that will work for all such images.

Fortunately, Ken told me of a much easier method. The first sector on the disk (track 0, head 0, sector 0) is always the first page of the Sys.Boot file. It has the first 512 bytes of that file and its label field points to the next sector of the file.

Jump to the next sector and indexing into that sector by 256 bytes will give you the password flag. It is FF FF for a protected disk. Set the flag to 00 00 and the task is done. I stripped down my Python program, gave it a Windows file open dialog box, and tested it with several protected cartridges.

IBM 1401 PROBLEM WITH READ-PRINT SEQUENCES

We spent more diagnostic time looking at the issue of false Reader Stop conditions when repeatedly reading cards and printing lines. This will fail sporadically on a job that reads and lists cards, but fails much more 'reliably' with tight code such as Read-Move-Print-Branch loops.

We discovered that the problem is a timing issue that occurs when the printer logic is transferring its data from the core memory locations 201-232 to the special internal memory buffer in the hardware. When you issue a Print command, it appears to finish rapidly, while the logic and physical printer hardware continues to print the line.

There is a 2 ms window where the logic fetches the 132 characters from main core memory and places them in the special buffer. During this 2ms, hardware will block the card reader logic from firing the reader clutch, since the card reader will also be accessing main core memory as it reads in each card.

With the sequence Read-Print-Read-Print-Read-Print-Read-Halt we usually fail on the last read. That read is delayed slightly by the printer transfer, then fires the clutch. The 1402 itself detects some problem, most likely that it thinks the Clutch didn't activate when commanded or that the clutch activated without a command from the processor.

It then raises the Stop condition which switches off the Reader Feed flipflop in the 1401, producing a characteristic very narrow clutch pulse. A number of conditions can cause the Reader Stop, although its main causes in a properly working machine are card jams or a card failing to feed from the hopper.

The system will also check its own operation by using a relay (10 - clutch check). These tests should be made only during a certain part of a feed cycle. At the enabled time, measured as a span of degrees of rotation of the reader mechanism, the clutch check relay must agree with the state of the clutch command coming from the 1401 processor.

We are looking for a case where the processor asked for a feed cycle but the reader isn't actually moving the cards forward, or the alternate case where the reader begins to move cards but the processor did not request it.

We will need to test the conditions triggering a Reader Stop to know which is the case causing our spurious stops. Is it a spurious jam, a movement thought to be uncommanded, or a failure to move after a command?

A card jam is detected if the microswitches that indicate a card is present at the hopper (card lever 1) or between check and read stations (card lever 2) don't close and open at the appropriate rotational positions in a feed cycle. Cards must clear stations and a new card show up at defined degree ranges. If this doesn't match, we probably have a jam inside.