Restoring the original source code for FORTH on the IBM 1130

RESURRECTING ORIGINAL FORTH IMPLEMENTATION

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.