Saturday, March 17, 2018

Historical recreation/restoration of original FORTH on the IBM 1130


FORTH was created back in 1968 on an IBM 1130 by Charles Moore, then ported to a large number of machines and expanded over the years. I managed to get the scanned listing pages of his original code working on the IBM 1130 simulator from Brian Knittel.

The system consisted of a 12 page assembler program that scanned input from disk, parsed it into words and processed a dictionary. It implemented a small number of primitive operations itself, but opened and processed a disk file with more than 200 punched card images to extend the language to its full breadth. 

The disk file teaches the system how to compile FORTH statements into 1130 machine code, adds a wealth of verbs, provides console/keyboard support and implements a disk based file access. The culmination of this 'boot up' disk file is a prompt on the console printer (HI THERE) and the ability to type in FORTH statements interactively.

The language evolved quite a bit from this first implementation, thus part of the restoration of the system involves reverse engineering, with the aid of 'archeological study' using old documents written by Moore and others from 1970 and later. 

The modern FORTH language defines words (verbs) using a colon (:) to begin and terminates the definition by a semicolon (;). Chuck Moore allowed for and used synonyms of period (.) and comma (,). In modern FORTH, the period is used to print the contents of the top of stack, but not in the original system.

The 200+ card images on the disk file used to 'boot up' FORTH are mostly sequences of definitions such as


The above definition builds on many prior definitions - only the word INC is provided in the assembler program primitives while the rest are built up by prior card images. This establish an area on disk for FORTH statements to be stored and read, at a hard coded sector /02E0 on disk, thus working outside the 1130's monitor system and utilities. 

In addition to definitions, FORTH will compile verbs to 1130 machine instructions using the keyword OPERATION, but that keyword is not used in modern FORTH. These compiled definitions look like 


This verb CHARACTER above will compile an 1130 instruction to directly do I/O to the keyboard, yielding an XIO instruction which reads one keystroke. It then calls a compiled routine to convert the input character from hollerith card code, converts it over to the console printer coding (selectric PTTC/8) and does an echo of the key to the printer. 

By the time of the CHARACTER definition, substantial functionality is already present, culminating in the final card image (FORTH statement) that starts the interactive user session:


The verb HOME, for example, will cause the disk drive to seek to track 0 (its home position), types HI THERE on the console printer and waits for user commands from the console. 

Since FORTH bypasses the 1130 monitor system and utilities, it takes direct control of the disk for its boot up file and user files. The assembler program has hardcoded the location on disk of the 200+ boot up card images. The FORTH statements in the boot up disk file have hardcoded locations such as sector /2E0 which is track 92, head 0, sector 0 on the disk. 

In order to get this running, I had to coerce the 1130 monitor and utilities in order to store the boot up card images on disk and to allow writing to sector /2E0 where FORTH is pointing. The monitor protects stored programs and data by setting a file protect line, below which writes are blocked, so I needed a disk image where the file protect line was below track 92. 

An 1130 can have disk packs mounted in a number of different disk drives. The monitor uses cartridge serial numbers to name packs, allowing files to be located by cartridge number and file name. FORTH does away with this. The verb HOME was coded to talk to the second disk drive, thus I had to discover this and establish a disk image mounted on that drive to allow FORTH to run.

At this point, I can issue FORTH commands and interact, but I don't understand some critical facts yet. These would have been documented in a language reference or with comments in a more modern version of FORTH, but this first instance was purely used by Charles Moore. It had no other users and no need for such documentation.

Before the second programmer began to use FORTH, it had been ported to a Burroughs machine with some significant change to the language, then evolved further as Charles Moore moved to new employment and eventually founded the FORTH company to spread the language. 

I have two documents written by Moore while he was at the original site of FORTH (Mohasco Inc) but written in 1970 after he had already evolved it to the Burroughs versions with features such as multi-user operation that didn't exist on the 1130. Neither of these is a language reference, but they do reflect the concepts and principles upon which FORTH was built. 

Somewhat later documents, such as a history of the early years of FORTH written by Moore or a user guide from Kitts Peak Observatory written in 1979, offer hazier hints. Some command verbs had changed two or more times between the 1968 FORTH and the versions discussed in these later documents.

Bob Flanders and I will be painstakingly studying the dense and undocumented FORTH boot up card images alongside the Rosetta Stone documents listed above, hoping to build up enough of an understanding, an informal language reference for original 1968 FORTH, that we use it for programming purposes. 

Monday, March 5, 2018

Various items - disk drives, ethernet tools and FORTH exploration


We had two disk drives that needed to have heads cleaned, installed, and aligned. One was left over from the archiving of the final group of Xerox PARC cartridges, where we had a minor crash trying to read a damaged pack. The other is a drive we are repairing for another Alto owner, who kept suffering disk crashes until shipping the drive to us for a look.

The heads were cleaned and installed in both drives. We decided to align and test the second drive, which would allow us to send it back to its owner and free up space for other restoration work. The alignment process worked fine and the heads fly with no crashing, but the drive fails to respond to the Alto when cabled up.

We will have to spend time debugging this to figure out what other components are not working. Not enough time was left to align our first drive, but it is ready for when we return next week. 


Marc built a nice enclosure for the ethernet tool developed by Ken. This tool hooks to the Alto ethernet card on the back of the computer, eliminating the need for an external transceiver and the need to run the original Xerox 3Mb/s version of ethernet. The tool converts to modern 10/100Mbs ethernet, provides a file server and other functionality, plus other routing services, all in a compact shape.


The FORTH system consisted of an assembler program that did the most basic functions of the language, reading an extensive set of FORTH statements from a disk file to yeild the full language and its interactive use of the IBM 1130 console printer and keyboard. The assembler program appears to be working correctly and my focus is now on ensuring the bootstrap statements on the disk file are working properly.

The assembler program expects the file to contain punched card images, in EBCDIC, packing two card columns per 16 bit word. Thus, each 320 word disk sector holds eight punched cards at 40 words per card.

The file is a sequential set of disk sectors, with the lowest sector containing the first 8 cards, the next higher sector holding cards 9 to 16, and so forth. Unfortunately, it gets a bit strange within each sector.

The eight cards in each sector are loaded in reverse, meaning that the first sector has card 8 at the beginning of the disk sector, next comes 7, all the way to card 1 at the end of the sector. That means a strictly sequential read through the disk file would receive cards 8 . . . 1, 16 . .. 9, 24 . . . 17 and so on. I need to reorder the card images within each sector but not across sectors.

The last oddity is that the card images, forty words that hold columns 1 to 80 normally, are swapped around so that the first word read in each card image has card columns 79 & 80, the next word is columns 77 & 78, all the way to the right where the last word has columns 1 & 2. I need my program to reverse all the words in each card image, after reordering the card images inside the sector.

I first did this reversing with an assembler program but I later switched over to a Fortran IV program because it provided a more natural way to reference sectors in a file. The Disk Monitor System attempts to file protect any stored file, blocking assembler I/O calls that attempt to write below the protect line, while Fortran ignores the protection scheme entirely.

With the file loaded with all its reversals, I set into debugging the operation of the FORTH system - I can see it loading elements into the dictionary but after just a few dozen card images executed, it goes awry. 

Friday, March 2, 2018

Restoring the original source code for FORTH on the IBM 1130


Working my way through the source code highlighted a few challenges to be overcome before we have this running fully. The format of some FORTH code on disk was more obscure than it appeared and the coding techniques in the assembler code, while clever, were not clear.

The assembler code in turn will read data from a fixed location on the disk drive, which are the card images of the FORTH code that extends from the few primitives built in to provide all the math, stack manipulation, disk, typewriter and keyboard control, queueing, and functions to compile FORTH statements into native 1130 machine instructions.

The code shows that the card images are 40 words each, with two card columns packed into each 16 bit word. That format, packed EBCDIC, is directly handled by the 1130 monitor system. Therefore, I used the utility program DUP to load the card images to disk in the target area. Each disk sector of 320 words contains eight cards.

After further inspection, however, it was clear that the code would take card images starting at the end of the sector and working back to the beginning, thus the utility load had reversed the order of each group of eight cards.

In addition, the code flipped all the words inside a card image, so that the code could read from the highest memory address down to the first word. That is, reading it right to left. I had to store the card images in the format expected, not the way that DUP would load them.

The code that scanned the lines coming in from disk employed a virtual algorithm that had each character in its own 16 bit word. To save space, however, they were actually processed in packed mode. Thus, all the pointers to the disk buffer were multiplied by two, appearing to address a 640 word buffer at a core location twice that of the actual buffer. In retrieving words, the code would shift the address right by one bit to pick up the real word. It took a few minutes to realize this.

No diagnostic output exists as the code operates and no easy method exists to watch what is happening inside. I have to put in simple wait instructions and step through the operation on the console of the simulated 1130, if I wish to see what is occurring and where any problems first arise.

Wednesday, February 28, 2018

Built battery for Roomba, discovered original FORTH software from 1130


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.


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.

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.