Developing 1053 console printer emulator for use with IBM 1130 systems

IBM 1130 TYPEWRITER (CONSOLE PRINTER) EMULATOR

I have thought about building a device to plug into the 1130 in lieu of the 1053 Selectric based console printer, since the device can get out of adjustment and block full use of the system. The device would be based on an Arduino with two SMS paddle cables that plug into the 1130 in place of the paddle cards from the 1053. 

SMS paddle cards

This device will communicate over a serial port to a terminal or PC where the output can be displayed and/or captured. An I/O Selectric operates at a maximum of 15.5 characters per second, with longer delays for operations such as carrier return, tabbing or line feed. This is easily within the performance of an Arduino without the need to do direct register manipulation or use interrupts. 

Today I coded the application which simply loops through these four steps:

1. Read all input lines to look for character selection or commands
2. Advance the state machines for print cycles, tracking the current column and movements
3. Transmit the appropriate outputcharacter, space, tab, line feed as appropriate
4. Control the feedback signals from the 1053 back to the 1130

The code sets a timer and uses it to decide how to step through the state machines. These are initially triggered by a positive value on the command or character selection lines, then they move through the 65 ms duration of a print cycle or the 2 second duration of a long movement command. Thus, it will take many loops through the logic for the time to elapse for state machine changes. 

Selectric typewriters choose which of four vertical bands of characters to print with two tilt control bits, T1 and T2. It also chooses which of 11 rotations of the current typeball hemisphere by using the rotate bits R1, R2, R2A and R5. On a typewriter, lower case and upper case letters are on separate hemispheres, thus a control line AUX determines which hemisphere should be rotated to the front. 

All told, these codes select one of 11 rotations on one of 4 tilts, for one of 2 hemispheres, a total of 88 printable character positions. The particular typeball installed determines the type of font and other characteristics. The console typeball, used on both 1130 and S/360 main consoles, has upper case letters on both hemispheres, thus there are two copies of each alphabetic letter. This reduces the number of unique characters on these balls to 62. 

The processor types a character by emitting one or more 1 bits on the signals T1, T2, R1, R2, R2A, R5 and AUX, which triggers a print cycle, rotating and tilting the ball before the mechanism slams it forward into the ribbon and onto the paper. The typewriter has a microswitch based feedback line that tells the processor when the mechanism has completed the critical part of the print cycle, after which a new character can be selected for typing. 

Other commands have discrete signals to the typewriter - line feed, carrier return, space without printing, backspace, tab, shift to uppercase, shift to lowercase, shift to use black ribbon and shift to use red ribbon. On the typewriter, the ribbon is inked with dual colors, top and bottom, thus the program can select the color which will be typed. Additional microswitches provide feedback for when long duration events such as carrier return have completed. 

I keep track of the current column, manipulating it as each character is printed, space or backspace occurs, resetting when the carrier returns, and arbitrarily choosing five columns for every tab. When the current column reaches 100, I emit a feedback signal; the typewriter has a microswitch near the end of line that accomplishes this task in a physical 1053. 

I have spare SMS paddle cards, which I will wire up to an Arduino in a case. I will need to use relays for the feedback signals, since the 1130 is expected 12 or 48V on those lines. The signals coming from the 1130 to my device are open collector outputs, thus they can work with the 5V pullup of the Arduino inputs. On the live 1053, these signals will ground 48V to operate solenoids, but my device does not have the voltage or current requirements being purely electronic. 

1053 printer - the 1130 adds 16 toggle switches across the faceplate as Console Entry Switches

Original FORTH from IBM 1130, meaning of pen markings on listings by Chuck Moore

CORRECTING BUGS IN ORIGINAL FORTH - AGAIN

The source materials we received in an email from Chuck Moore many years ago were scanned pages of an IBM 1130 assembler program and card images that we realized were early FORTH statements that built the language up from a few built in primitives to the interactive prompt for user input.

On the scanned pages of the early FORTH statements were a few black pen notations which I now realize were placed there while Chuck Moore was debugging his FORTH system. One notation was a change in the size of the disk buffer (a vector named IN) which was originally coded as x140 words in length but the marker corrected that to x141.

This makes perfect sense if you know the 1130 system. The disk drives were organized in sectors of 321 words, which is x141 in hex. Further, the system software for the 1130, Disk Monitor System, used the first word of a sector to contain the sector number and left only 320 words for user content.

This was just a convention established by the software. Since FORTH eliminates the use of DMS and other system software, instead handling disk I/O directly with raw 1130 instructions, there was no need to abide by the convention concerning the first word. Bumping the count from 320 to 321 words allowed Chuck to use the full physical capacity of each disk sector.

It would have been a subtle error to catch, as most lines of input in a disk block would have trailing blanks. That meant that reading the disk sector with a short count would leave the very last word untouched. If the buffer had a word of spaces there, it would be unaffected by any subsequent disk I/O. Only when he was testing some program that used the very last word of a sector would he have discovered the need to increase the length of the I/O buffer.

There are two other statements in his scanned pages which have pen markings on them - the CREATE verb and the EMPLACE verb. As I was slowly checking out the operation of every verb in this system, I found that EMPLACE was not working correctly. It should have allowed the user to place text into the disk buffer, taking the users keystrokes terminated either by an apostrophe character or a length of 40. Instead, it was writing the entered keystrokes into low memory.

I then figured out how to modify EMPLACE to make it work as I think was intended, but it was clear that Chuck Moore had known it wasn't working, based on his pen marking, although not yet having rewritten it to work properly.

The final spot with a marking, the CREATE verb, has underlined 2E0 SECTOR which is where he chooses to begin the area for user disk blocks. It corresponds to how I configured the simulated disk drive on the 1130 simulator, but he may have either confirmed the location or meant to change it to match some different disk drive layout. In either case, I don't think it is incorrect.

Therefore, we had one defect corrected in pen, one identified but not yet addressed, and an underline that either confirmed the address or highlighted were to change the starting sector for user disk files. 

Set up tape drive to archive 7 track tape reels by recording flux transitions and decoding by software

PREPARING TAPE DRIVE FOR 7 TRACK TAPE RECOVERY

Computer History Museum aims to preserve software history by reading and archiving mag tape source material, some of which are too degraded to read on standard tape drives. When data recovery services also fail to extract the contents, extraordinary measures are needed.

The early efforts were focused on 9 track tapes, using a logic analyzer with very deep memory to record the raw flux transitions from the tape head as tape streamed past. This data was analyzed by software that handled skew, bit crowding and other effects of magnetic recording to produce an image of the tape contents. Len Shustek was the primary driver of this effort, with help from Paul Pierce and Al Kossow. 

It is time to begin recovering 7 track tapes, using the logic analyzer and a suitable drive where the raw flux transitions can be captured. Museum staff had two transports in the queue for modifications to handle this task, a Qualstar 1052 and a faster, more capable HP 7970E. For both, they physically installed heads with seven tracks, where they waited in the queue to be wired up and adjusted.

Ken Shirriff and I stepped in to help get the first of the transports working with the 7 track head. The new head was actually a dual 7 and 9 track reading head from a different system, with cables ending in winchester type high density connectors. We had no documentation on the pin assignments for the head.

The Qualstar drive had three connectors which attached to its original head assembly, but with a service manual available on Bitsavers we would know the pin assignments. These connectors were .1" spacing types, two of them were 10x2 double connectors and one was a 3x1 single row. Our job was to appropriately mate the heads to these connectors. The museum was willing to have the high density connectors cut from the new tape head, leaving only the more standard .1" types. 

One of the 10x2 connectors was on a PCB and this one attached to the read side of the original head assembly. The other two connectors were for the write and erase heads, thus we detached those cables frm the drive entirely. Using the schematic we drew out the pin assignments on our 10x2 connector.

After severing the cables from the new head to detach the high density connectors, we prepared these to solder onto a new PCB we would make. The outside stiff plastic shield was trimmed back, exposing a shielded braid and a number of twisted wire groups inside. As expected, there were seven groups of wires, one per track on the tape head.

All seven tracks had the same color coding on the wire groups. The group was three wires, red, blue and white, twisted together to help with shielding from outside EM fields. Using an ohmmeter, we decided that the white wire was a center tape on each coil in the head, with blue and red providing the pulse as magnetic flux changes passed under the head. 

We arbitrarily assigned blue to represent the + polarity from the schematic and red for -, and prepared for wiring. One thing we could not determine was which track each group of wires belonged to. We handled that later.

We made use of a small breadboard PCB, trimmed down to size, where we could install a 10x2 set of .1" spaced pins to accept the connector PCB from the tape drive. We would install 10x1 pin rails on the reverse side to the outside of the connector we just built, allowing us to solder the fine wires from the tape head. 

One complication came from the nature of these breadboard PCBs - the holes that are spaced .1" apart are bridged together in six rows, thus the connector we would place in the middle would by default have each pair of pins in a column shorted together. A box cutter and additional work with a small screwdriver broke the traces on the PCB to isolate the breadboard into two rows of three interconnected holes, allowing the two sides of the 10x2 to be electrically isolated.

I drilled two holes in the PCB to allow use of a cable tie to hold the end of the tape head cable down to our new board. Soldering was straightforward although not easy due to the fine wires when stripped and springiness of the wire insulation. Forceps, two of use working in concert and a bit of care allowed the soldering of all seven tape channels to our board. 

I grabbed a L plate to mount this new PCB inside the tape drive chassis in a convenient spot. It required the drilling of one hold through the side of the drive chassis and we had our new board plugged into the tape drive read head connector PCB and everything securely mounted.

This particular tape drive has a read electronics circuit which first amplifies the head signal through a differential video amplifier, then further boots it with an op-amp. The logic analyzer will pick off the analog signal at the output of that op amp. We knew they needed at least 2 volt swing on the op amp output to decode the transitions well, thus our first check was to see the signals produced by a test tape. 

Success, with approximately 7 volts peak to peak coming from the output of the op amp! We had two more checks to make, before we could wrap up the job. First, we had to verify that all seven tracks were functioning properly, producing good signals out of the op amps assigned to their channels. Second, we wanted to determine the ordering of the channels to know which track each represented, from top to bottom of the tape head.

The Qualstar drive was built as a 9 track machine, therefore the read board had nine channels which were exact copies of the video amplifier, op amp and other circuits designed to handle a single tape track. We were only using 7 of them, obviously. These were channels 100, 200, 500, 600, 700, 800, and 900, to use the naming from the Qualstar schematic. 

Ken came up with a clever way to identify the order of the channels from top to bottom of the head. Using diagnostic mode on the drive, we could command it to drive the tape forward at a steady rate, while we watched signals from the op-amp outputs. Ken took a sheet of paper and slid it down between the tape and tape head, watching carefully to see which of two op amp signals would decline first. That told us which of two channels were closer to the top.

Now, it was a simple matter to keep moving the scope probes around, doing pair-wise comparisons, until we had a definitive order from top to bottom. It turned out that we had channels, from top to bottom, of 

• 100
• 200
• 500
• 900
• 700
• 600
• 800

We know that the parity track is at the bottom, with the least significant bit of a character at the top. That allows the museum to wire the logic analyzer appropriately and recover the 6 bit data characters plus parity as flux transitions. 

Understanding original FORTH

UNDERSTANDING THE ORIGINAL FORTH 

I have guessed that Chuck Moore established a layout for disk blocks used by his first implementation of FORTH, written on an IBM 1130 back in 1968-1970 when he was at Mohasco. FORTH handles access to the disk itself using raw 1130 instructions, not the Disk Monitor System or its utilities. Because of that, he can ignore the conventions used by DMS.

A disk file on an IBM 1130 consists of physical sectors of 321 words, with the convention reserving the first word to contain the sector number. This is a check against errors in reading or writing, since the first word should match the sector number associated with that physical location on disk.

An 1130 disk consists of 203 tracks or cylinders, each is a circular path on the rotating disk surface, the circles arranged concentrically from the outer side to the inner side over a 2" wide span of the 7" disk radius. The track closest to the outside is track 0, also called the home cylinder. The disk drive reports when the positioning arm is at the home position.

The disk is a two sided platter, thus there are two read/write heads, top and bottom. For each track/cylinder, we can access top and bottom separately, doubling the data capacity at that track.
As the disk rotates, it is divided into four segments each of which stores 321 words, one physical sector.

Thus, each side of a platter has four sectors, a total of 8 per track, and the entire disk holds up to 8 * 204 sectors or roughly 512K words. A few of the end tracks are reserved to serve as replacements for a track that may contain a bad spot which won't allow correct reading/writing. These alternate tracks are hidden from the user's accessible capacity, as they replace 1 for 1 any bad track.

We can number sectors starting at 0, with 4 on the top head and the next 4 on the bottom head. Thus, track 0 has sectors 0 to 7, track 1 has sectors 8 to 15, and so it continues. Chuck picked sector 2E0 as the beginning of the area for FORTH user disk data, which is sector number 736 in decimal. That means it begins at track 92 with top head, sector 0.

As formatted by DMS, the disk contains 2E0 in the first word of track 92, top head, sector 0 and each subsequent cylinder contains the relevant sector number. The IBM simulator watches this first word, writing a warning message if a user reads or writes a sector where the first word does not match the sector number.

Chuck instead is using the first word as some kind of integer counter, which is incremented each time the CREATE verb is issued. The verb EMPLACE which seems to accept user input to put it into the buffer, writing back the sector, starts that data at the 30th word into the buffer.

I suspect there are other format constraints as well, but will need to study this further before I fully decode the format and can begin using FORTH correctly. Since at the time this was written, only Chuck Moore used it, there was no need for written documentation or even comments in the code to steer another person towards using it properly. He was the world's sole FORTH programmer. 

Setting up a High Frequency ham radio station

AMATEUR RADIO INSTALLATION

A club I belong to recently auctioned off some items to members that came from the estate of a former member, and I acquired a Kenwood TS-940s transceiver for an extremely low price. This is a 250W system that operates on 160 meters up to 10 meters. It was a top end system for its time, introduced in 1985, selling at a price tag, in todays dollars, of about $5,000.

It had all the optional filters installed (both CW and AM) that improve reception of weak and noisy signals by tailoring the width of the signal to block out adjacent noise. I now have to build an antenna and put this into operation, something I didn't plan on doing. My defense is that I was seduced by the extreme bargain.

I decided to improve its operation, taking advantage of more modern computer control and digital signal processing capabilities. I am connecting it through a pan adapter to a PC for that purpose. A pan adapter takes the intermediate frequency output of the transceiver (around 8MHz) and processes about 200KHz on either side of that frequency.

The pan adapter (LP PAN 2) provides two audio frequencies representing the I and Q, in phase and 90 degrees out of phase signals, into a Xonar U7 USB based sound card which digitizes those signals. Using the I and Q, software can act as a spectrum analyzer, showing the 200KHz spectrum surrounding the current tuned frequency of the receiver.

I can immediately see on a screen where signals exist and their relative strength. It also shows the nature of the signal (e.g. single side band or CW or slow scan TV or radio teletype). This spectrum can be shown over time as a waterfall display.

The software will do much more sophisticated noise filtering and signal processing than the state of the art back when the Kenwood was built, which is applied and the PC speakers used to output the cleaned up and stronger audio.

As well, the software controls the Kenwood radio, switching bands, modes, tuning and anything else I want it to do. Thus, if I see an interesting signal on the waterfall display, I just click on it to tune the radio.

To control the radio remotely, Kenwood provided an optional AUX board, the IF-10b, which is rare. Its outputs are TTL serial but would need voltage conversion to connect to a real serial port. Since I didn't expect this was in my radio, I ordered a third party PIEXX board that provides true RS232 and connector.

As I opened up the system and removed parts to get to the mounting point for my PIEXX board, I discovered that this radio already had the IF-10b. I could have saved money with an inexpensive RS232 level shifter board, but perhaps with the cost of DIN connectors to use the existing AUX ports on the radio, the cost difference isn't that high. Plus, I can sell the original IF-10b board on eBay.

I also noticed that this radio has the auto tuner installed. The model of the radio, TS-940s, means it had no autotuner. The model would be TS-940sat for that capability. It appears the prior owner retrofitted the autotuner, however, so that is another unexpected plus.

An autotuner will adjust the electrical characteristics of the connected antenna to reduce wasted energy and reflected signals coming back from the antenna. This is termed SWR, but to simplify things this autotuner adjusts the impedance of the radio to match what is sees from the antenna.

It does this by adjusting a variable capacitor and a variable inductor, using two servo motors, seeking the closest match possible. This autotuner can't match every possible antenna impedance, but works for a wide range of reasonable antennas. A push of a button and the motors whir as it tunes up to the lowest SWR.

My home location is very challenging for erecting HF antennas. Normally one would either erect a large metal tower with rotating beam antennas up high, or string long horizontal dipole antennas. At 160 meter band, the dipole would need to be 80 meters long, quite a bit longer than my property. It would be very very hard to squeeze a dipole for 80m on a 123 by 73 foot lot.

Horizontal antennas, whether a rotating beam up on a tower or a dipole, are directional. They deliver more power relatively in one direction than the other, whereas vertical antennas are omnidirectional.
Output power of 250 W is radiated evenly in all directions with a vertical, whereas a horizontal will appear to be about 4X as powerful in its best direction compared to the vertical. My lot is aligned so that its long direction would cause a dipole to be aimed north and south, instead of west/east where more of the potential contacts exist.

The lot is small enough and the rear is cement with a swimming pool, so no room for a large tower. Further, there are 12KV electric lines running above my back fence, quite lethal if any antenna were to fall onto them. This severely restricts possible placement of anything vertical from the ground, whether a tower or vertical antenna.

Even my front yard, which would look terrible with a metal tower, has very tall trees in front whose canopies cover much of the front. Trees absorb RF and interfere with antenna characteristics as well.
That leaves a vertical antenna as the option. The problem with a vertical antenna is that it requires a good RF ground plane underneath it to operate properly.

The usual ground plane for a vertical antenna is perhaps 90 radial wires laid along or just beneath the ground at 1/4 wavelength - so 40 meter diameter circle for the 160m band and 20 meter for the 80 meter band. This is impractical on my lot, even if I didn't have the concrete and pool in the way.

The alternatives to the full ground plane produce a less effective antenna. It can reflect quite a bit of RF power back down the shield of the antenna feed coax cable, which can cause burns and lots of interference in the house.

There are tricks, each with its corresponding compromise downside, such as using tuned rods that electrically appear to be 1/4 wavelength but are actually shorter. One can have a number of elevated rods partway up the vertical antenna mast, but at the bottom of the active section, called counterpoises. These still stick out quite a bit horizontally, but would be up in the air on the mast.

I would need the vertical antenna with counterpoises to be above my house due to the restrictions of the lot and the power lines. I am still studying the best places to put those. In the interim, I will make due with a temporary vertical antenna called a random wire type.

This is a 33 foot wire which I will hook to the top of a telescoping fiberglass pole, held on the side of my building at a location where it can't fall onto the power lines. At the bottom is an impedance matching box and to which I will hook some wire lengths as counterpoises.

I bought an external antenna tuner which handles more severe mismatches, to tune this random wire to my transceiver for this interim operation period. There are various techniques including boxes called artificial grounds that will minimize or eliminate any RF coming inside on the feed line.

It will be inefficient and perhaps require lots of tuning as I switch bands, but should let me operate on all my bands while I work on a more permanent HF antenna using a vertical with counterpoises atop my house.

This illustrates how quickly a bargain can spiral into significant spending and work - antennas, tuners, pan adapters and all the rest of the gear that goes with the very inexpensive transceiver. 

Making substantial progress understanding original FORTH

ORIGINAL FORTH RECONSTRUCTION

I have worked my way line by line through the 202 card images that evolve from the few built in primitives to the working FORTH system. I am still puzzling over a number near the end of the deck, related to commands working with user disk blocks, since these are so interlinked.

One of the design goals of FORTH was to simplify use of computers by eliminating the need to deal with the operating software of the computer. This is starkly visible with original FORTH, where even the file directory structure is bypassed.

Chuck Moore wrote his verbs to manage console and disk I/O to directly manage the hardware, eliminating almost everything in the Disk Monitor System that supported the 1130. To type a character on the console typewriter, Chuck would form the machine instruction to start the I/O, override the interrupt handler to return to another verb and thereby handle everything with no DMS involvement. 

I/O on the 1130 is controlled by the XIO instruction, which points to a two word area that contains a memory address or value, a device address, a command code and a few other flags. The commands are simple - read, write, initiate read, initiate write, control, and sense device are the major ones. 

The difference between a command and its initiate counterpart is that a read brings in a single word at a time, while initiate read starts a read of some length which depends on a DMA like capability where the device will access memory to enter or fetch each word. 

When a device needs attention or has completed a requested I/O operation, it interrupts the CPU. There are a small number of interrupt levels (prioritized with 0 highest). Each level is assigned a core address starting with 0008 for level 0. When the interrupt occurs, the processor executes a BSI I instruction through the address in those low core locations. 

A BSI (Branch and Store IAR) instruction will store the prior instruction address in the target location and branch to the word after (target+1). This is a subroutine call, since the code can return to the interrupted location by an indirect branch through the saved address from the BSI. 

Chuck plugged in the address of a compiled verb into the loc core address to handle the interrupt that will occur when he issues an I/O instruction. For example, the console typewriter and console keyboard use interrupt level 4, which involves low core address 000C. 

Thus, in proto-FORTH, he grabbed the address of a verb to handle the interrupt (e.g. LOC READY to get the address of the verb READY) and stored it as the interrupt handler (STO L  000C)

When an interrupt handle has completed its processing, it returns using a Branch Indirect pointing at the address saved by the BSI that implemented the interrupt. To switch off the interrupt, a special bit is added to a Branch instruction to turn off the current interrupt level. The normal branch is a BSC; with the special bit, it is a BOSC. Chuck's verb READY will return at its end using a BOSC.

He did the same with his user disk functions. The small assembler language program that provides the initial small number of primitives does use DMS to read the card images from disk that extend and complete the language, but once the extension card images are processed, DMS is needed no longer.

Since I/O operations take a relatively long time compared to processing speed, the FORTH code must wait until the interrupt before it continues. Chuck handles this by using a structure he built as a verb QUEUE. It will sit in a wait state (via the instruction WAIT) until the interrupt handler (e.g. READY) modifies the code in QUEUE to become a return to FORTH processing. After building and issuing an XIO instruction, his verb ENQUEUE sets up the QUEUE verb to wait.

Neat, tight and clever code, built up from the card images, taking the few simple primitives of the assembler FORTH core and providing I/O support. It is an example of the design philosophy of the language itself. 

The user can create disk 'files', load and edit FORTH statements and data in those blocks and retreive them to cause them to be interpreted by FORTH. A block may provide additional functionality, such as a more powerful editing system, through extending the language with even more verbs. 

To save space in the limited core memory and dictionary space, these are only added to the dictionary when needed, by a user fetching the block. Useful verbs are available to support extending and dropping such incremental functionality, such as the FORGET verb which drops everything in the dictionary from a target verb onward, freeing the space. 

Disk and editing support involves a group of interrelated verbs and nouns. Data areas like IN which hold the 321 word block from the disk drive, other nouns for line number, sector number and so forth. Verbs such as CREATE, ACTIVATE and DELETE deal with the blocks, while others such as EMPLACE or SEARCH to manage the contents inside a disk block.

One challenge we had with this original FORTH was the lack of the verb that is basic in all subsequent FORTH implementations, the period, which removes the top entry in the stack and prints it on the console. It may be that some set of existing commands provide this capability, but I have not yet discovered how to do this.

Therefore, I wrote my own FORTH verb to extend the system further, and named it period. In proto-FORTH, the period is a primitive that is a synonym for colon as the start of a definition. The card deck used period extensively, but at the end of that deck, I redefined period with my command and viola, original FORTH now has the verb to print the top of stack. 

        10 30 + .

The line above will print 40 on a new line as soon as the period is encountered, removing it from the stack. This makes life much easier as we explore this original FORTH.

Exhaustive documentation and deconstruction of original FORTH

ANNOTATING AND DECONSTRUCTING FORTH

One aspect of FORTH on the 1130 makes the task of investigating and deconstructing the behavior easy. The assembler code is always loaded starting at hex 0900 and that means the locations of the dictionary entries are always the same for the FORTH statements executed off the disk file as part of FORTH bootup.

I dug through core memory to extract the locations of the dictionary entries once FORTH typed its HI THERE prompt for user input. Every dictionary entry has a fixed part, four cells that are sequentially arranged from the built in primitives up to the final word in the dictionary. In addition, there is a variable part that is arranged beginning at hex 1A00 and growing upwards.

The fixed entry has the first four characters of the name of this entry, an address to execute when this word is encountered, and a parameter cell that is used for some but not all types of words. Notice that words are only defined by the first four characters, thus CHARACTER and CHARSUM will refer to the same entry in the dictionary. 

Entries that are defined by : and ; bracketing a string of words will establish a dictionary entry in the name of the first word, then in the variable entry will store the remaining words, separated by blanks, up to an including the trailing ; character. 

Entries that are defined by an initial OPERATION word are stored as an entry under the next word. The remaining words are compiled immediately into 1130 machine instructions, set up as a callable subroutine. Subroutines are entered using the BSI instruction, which stores the return address in the first cell and then executes for a while before branching back to the return address. 

If the words being compiled (in an OPERATION block, called a CODE block in more recent FORTH) are definitions that were saved as text by :;, then they are now compiled. This proceeds recursively if an entry in turn references another regular definition, or calling the subroutine if the entry in turn references some CODE/OPERATION compiled code.

I can see the 1130 instructions and data that are set up in the code blocks, helping me to understand how it all works. For the text saved entries (those defined with :;) I have to see that entry used in a code block before it is actually compiled. I can either find a code block which referred to a text definition, seeing what was generated from it, or I can set up my own code block as a new entry after the user prompt. My code block can refer to a text entry, causing it to be compiled. 

Using these tricks, I very slowly and painfully built up an annotation of every FORTH statement, showing what it produced. There are two results of these statements - changes to the stack and additions to the variable dictionary -- so I extended normal FORTH shorthand for documentation.

It is normal for a FORTH definition to show what must be on the stack before execution and what is left on the stack afterwards. For example, (n m -- c) means n is on the top of the stack and m is the entry below it. They are both consumed and a result c is left on the stack after we finish execution.

I chose to add a new shorthand for the output to the variable dictionary entry as var: (a, b, c, . . . ) where a, etc are what is added to the variable entry. I discuss any unusual aspects in the text below that shorthand. As an example, the statement:

   :L 400 INST;               (n -- ) var: (n OR 0400)

takes a cell on the stack which is the basis for an instruction, ORs that with 0400 to produce an instruction that is in 1130 long format, and sticks that instruction in the variable stack. If this is called with C000 in the stack, the basis for a load instruction, then we will have C400 on the variable stack when the word L is executed. 

Later in the disk file of FORTH commands, very sophisticated operations are built from these more basic verbs. My documentation will shift to focus upon the high level behavior, although I will still retain my stack and variable dictionary shorthands. 

It will take me several more days before I have the entire file interpreted. At that point I should be able to use it properly.