Built battery for Roomba, discovered original FORTH software from 1130

REBUILDING BATTERY FOR ORIGINAL ROOMBA VACUUM CLEANER

I cut some thick art paper stock and wrapped each cell to insulate the sides. Once the cells are connected by spot welding nickle plated steep straps, I will hot glue the cells together to eliminate any chance of shorting.

Wrapped cell on left, paper above

My next challenge was to work out a method to spot weld without a welding helmet, yet to protect my eyes from the UV produced by the welding. If I can hold a welding glass in front of my eyes while reliably holding the welding electrodes in the proper place, then activate the welding unit with a third limb, it would work.

I spot welded the strips for each half (six cells), but am not convinced the spot welds are solid enough to work reliably. I put them aside and go back another day to add more weld spots to all the strips.

RECREATING ORIGINAL FORTH IMPLEMENTATION ON IBM 1130

When Charles Moore created the FORTH language, it was famously done on an IBM 1130 whose restriction of file names to five characters forced Chuck to make his fourth generation language name become FORTH.

I have been in contact with Chuck and the Silicon Valley FORTH Interest Group (SV-FIG) to try to recover the original code. It looked like no copy existed until I discovered an obscure reference from 2011 on the 1130 google group which suggested that Chuck did send some code to a friend of mine.

I contacted Bob Flanders, who dug through his old email and discovered a previously unnoticed attachment which contained sixteen scanned images. These were twelve pages of an IBM 1130 assembler run and four pages of cryptic FORTH-like code.

I typed in the sixteen pages to make them machine readable, then Bob and I began to attempt a resurrection. The assembler program implements some basic primitives in FORTH, then reads card images from a fixed location on a disk drive which we believe are the contents of the four cryptic pages.

The cryptic card images are the remainder of the FORTH language, extended from the hard coded primitives in the assembler program. They define forth operators such as DUP, building them up from the primitives. Some of the primitives and FORTH operators are different from modern FORTH, or are synonyms.

For example, you extend FORTH with statements that are delimited by : and ; but period and comma are synonyms. Those synonyms are in the cryptic code, rather than the more well known colon and semi-colon.

FORTH compiles statements, thus a key part of the cryptic card file are functions and definitions to build up 1130 machine instructions. Near the end of the cryptic file, it creates the interactive prompt system from the console keyboard and console printer, issuing the message HI THERE to the console and waiting for the user to continue.

We spent quite a bit of time looking hard for typos, but are now in the debugging phase where we are trying to get it all to work properly.

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

VINTAGE COMPUTER FESTIVAL IN SEATTLE

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.

MAME EMULATION OF HP 2645A TERMINAL

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.

REBUILDING ORIGINAL ROOMBA BATTERY PACK

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. 

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

HP 1000 SYSTEM RESTORATION

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. 

Finished archiving all known Xerox PARC disk cartridges

ARCHIVING MORE XEROX PARC DISC 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.

RETRIEVING HISTORICAL 360 ERA TAPE DATA

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. 

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

REBUILDING BATTERY PACK FOR ORIGINAL ROOMBA VACUUM

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 DIGS INTO THE IBM 1401 SYSTEM CARD READER LOGIC (1402)

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.