Seemingly possessed Diablo disk drive now working

DEMONS BEGONE! - DIABLO DRIVE FAULT FINALLY FOUND AND FIXED

As readers may remember, we have been battling this drive which reads just fine but has problems writing correctly. If we take a cartridge written on other drives, this one will read it perfectly. If this drive writes anything, it is very likely to have errors reading back on this or any other drive.

The problems occur with both top and bottom heads. The oscilloscope showed that the previous contents of the sector were not fully erased. We swapped PCBs with other drives but the problem remained.

Today we decided to swap out the heads on the drive with known good heads from another drive, just to eliminate the heads as a cause of these symptoms. Even with all PCBs and the heads from a good drive swapped into this unit, the problems continued. 

There was not much left that could be wrong - a cable from a PCB to the disk head connectors, the backplane carrying signals between PCBs, and the electromechanical drive and arm mechanisms. That is, if this is not a case of possession by malevolent spirits. 

We ruled out the backplane after checking that all the signals required for writing were reaching the PCB that connects to the heads. We ruled out the cable and connectors to the heads by using a Time Domain Reflectometer and also measuring the resistance of each line. The TDR would show us shorts, open wires or other anomalies that cause reflected signals which may impact the quality of recording. 

At this point, Marc began to closely examine the mechanism that loads the heads down onto the rotating disk surface. This is a pair of brass prongs that pivot to force the two heads together, pinching them against the disk surface as it rotates. The back of the disk head has a raised metal ball that sits under the end of the brass prong, through which the prong exerts the diskward pressure. 

Marc could see the ball because the prong did not extend over the ball. The prong was about 3/32" shy of the ball. Looking at our other drives, we saw that the prong sits right over the ball on correctly operating drives.

Prong does not cover small metal ball on disk head

We looked at the bracket holding the prongs and saw they were bent out a bit from the machined metal structure that holds the heads. Using pliers, Marc bent the bracket to compensate, putting the prongs back over the metal balls on the disk heads. 

Adjusting bracket holding prongs

The failure mode was failure of the prongs to press the heads down against the disk surface as fully as on a correctly working drive. Just as seriously, the point where pressure was applied is now offset compared to the aerodynamic center of the head. 

This would cause the head to fly at an angle, not parallel to the disk surface, and have reduced pressure to force them down. The spacing from head magnetic poles to the disk surface was larger and uneven.

Prong properly positioned over metal ball

With the prongs adjusted, we fired up the drive and tested again. First I wrote a known image on the cartridge using my FPGA based disk tool, then did a read of the cartridge contents back to the tool. Zero checksum errors and a perfect match to the image being written!

We swapped back all the PCBs to the ones from this drive, moved the drive to the Alto and booted up to ensure it was working well. Problem solved! All that remains is to swap the heads back between our drive and this one, run an alignment, and do a final set of tests. 

We believe this problem is related to the bad disk crash we experienced early on in the repair of this drive. It was shipped to us by the owner, who followed our recommendation to secure the disk arm from movement by using a cable tie. It is likely that the cable tie was tightened much too much, bending the bracket outward and shifting the prongs out of position.

Very slight gap of bracket against metal of disk head holder

Our early crash, after swapping out the original bad heads for a replacement set, was associated with bent prongs after the loud noise and scraping sound. We have to assume that the bending during shipping caused both the early bad crash and the continuing write errors. 

The misalignment was very small and subtle. Worse, it is not a position measurement that is called out for checking in the maintenance manual, so we didn't spot it in all these months. At least it is corrected now and the drive can go home to support its Alto system. 

Finished assembly of the IBM 1130 Console Printer (1053) emulator box

COMPLETION OF BUILD OF IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I soldered the signal wires between the second SMS Paddle Card junction PCB and the Arduino. Four output wires run to the relay module,  which switches power from a third SMS Paddle card delivering 48V and 12V power from the 1130.

My initial connections to the Arduino used wires soldered onto header strips but it was too hard to control shorting side to side since the arduino has a double row of sockets. I then picked up a shield that plugs onto the Arduino and provides screw terminals for all the connectors. This gave me a more secure and reliable interconnect.

Given the tight quarters inside the box, I had to do a trial fit of the six PCBs (relay module, two junction boards, display board, BCD/LED converter and Arduino) to select the locations to mount everything. The display board and its converter mount on the inside of the top (face) plate, of course, stacked on standoffs.

Board stack for 7 segment displays and BCD decoders

The other four had to be arranged around the bottom in convenient locations and installed on standoffs from the bottom of the box. I needed a trip to Anchor Electronics to pick up the mounting hardware before I could wrap things up. I probed each SMS paddle connector and verified its destination inside the box. 

Boards installed and wired up inside the box

Before the final close of the box I plugged it into a PC and fired up PuTTY to check out some functions. The five pushbuttons on the faceplate and the digital display were easy to check. I also did some tests using jumpers on the paddle cards to trigger various 1130 signal inputs - actually using spare sockets I own into which I plugged the paddle cards.

Box closed up but not yet labeled

I was able to fire print cycles (printing .), line feeds, plus exercise the front panel buttons. I will need to wire this up to sockets to be able to present valid combinations of inputs for the other characters - only certain combinations of T1, T2, R1, R2, R2A and R5 are valid and my logic tosses away invalid codes. Perhaps I will do this on the weekend.

I will do some cosmetic improvement of the placement of the buttons on the faceplate - widening the hole and gluing them down to make them align better. Labeling of the button functions using my label transfer technology will complete the cosmetics of the unit. This work will occur at a future date.

WIRING AND INSTALLING PARTS OF IBM 1130 CONSOLE PRINTER EMULATOR

ASSEMBLING IBM 1130 CONSOLE PRINTER (1053) EMULATOR BOX

I rough mounted my controls and digital display in the box while I work on the wiring of the SMS paddle card cables and other parts. I still need to mount the 7 segment BCD driver board underneath the display board, mount the adapter boards from the SMS cables, and the Arduino itself, before I can close up the box and have it ready for live testing on an IBM 1130 in a few weeks.

Face of the box containing the 1053 emulator, rough placement of buttons

The box has three buttons across the bottom in a row. From left to right, those are Tab, Space and Return functions. Above them is the digital display of the current column for the virtual carrier. To the left of the digital display are the tab setting buttons. The top of the two sets a tab stop at the current column while the bottom of the two will clear any stop at this column.

Junction boards to connect SMS cables into device

I used small breadboard PCBs to connect the SMS paddle card cables as a strain relief and means to ease the connection to my Arduino. Most of the signals are incoming and will go directly to the Arduino, but four of them are feedback signals that will come from a relay board which switches the 12V and 48V needed by the 1130 controller logic.

The inside of this box is going to be crowded, even though it is relatively large at 11 3/8 x 8 1/4 x 3", because of the five boards plus Arduino and all the wires between the parts. The key to construction will be mounting all the boards on standoffs inside.

By the end of the evening today, I had the first PCB fully wired to the header pins to take the 12 signals on SMS Paddle card 1 and route them into the Arduino. Tomorrow I will work on the PCB for SMS Paddle card 2, then start wiring the relay board into place. 

1130 Console Printer emulator working to spec, waiting only to connect to real IBM 1130

COMPLETED OFFLINE TESTING OF IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I wrapped up my testing today, using one Arduino as a test driver to simulate signals from the 1130 going to the emulator device I built. Everything is working exactly as I intended, particularly when used with a terminal emulator such as PuTTY that supports ANSI colors and the ASCII codes for backspace, new line, return etc.

Test validating lower case characters in black and upper in red

This is as far as I can go until I finish wiring up the device and can plug it into a real 1130 system to verify that it works properly in actual use. I have holes to drill and cut, parts to mount to the box, wires to identify from the SMS paddle cards and cables to wire into place. Should be another day or so before this can be set in place near my 1130 until I can rearrange the garage to power it up. 

Steady debugging work on IBM 1130 support devices plus improvements and design ideas

CONTINUING OFFLINE TESTING OF IBM 1130 CONSOLE PRINTER EMULATOR

Today I set up a second Arduino to drive the signals that would come from an 1130, allowing me to test out the correct behavior of my program. This is the most I can do until I fire up a real 1130 computer and test; it will take me some time to reorganize my garage before I can run the 1130 to accomplish this testing.

The IBM 1130 will pull the tilt and rotate lines low when it requests the console printer to type a character. There are four tilt levels on a type ball, selected by T1 and T2. There are five amounts of rotation to either side of the resting position of the type ball, plus the ball can rotate 180 degrees which on a typewriter separates the upper and lower case characters. Rotate codes are R1, R2, R2A, and R5.

An additional signal AUX is sent but is always 1 for printed characters and 0 for control commands (CR, LF, TAB, SPACE, BACKSPACE, UPSHIFT, DOWNSHIFT, PICKREDRIBBON and PICKBLACKRIBBON). This is consistent with the intended use of that bit, which is to fire the print cycle on the selectric when the values of T1, T2, R1, R2, R2A and R5 are all zero. It also fires a print cycle for any other tilt and rotation selection, causing no harm.

When the tilt and rotate values are all zero, they select the home position of the ball (the 0 for lower case side and | for upper case hemisphere ) but the machine won't activate unless one of the select characters is switched on, thus AUX  will be used to trigger a print cycle. If it were on with a control command, that would fire a spurious print cycle and type a 0 character, but the 1130 only uses it to print the tilt 0, rotate 0 home position.

The AUX signal is called the CHECK signal on other I/O Selectrics and its role is to institute a parity check on the value of the tilt and rotate signals, plus to trigger a cycle for the home position (0) if that is being printed. That is used when there are contacts on the I/O Selectric that route back feedback on the actuation of the tilt, rotate and check selection. Since the 1130 does not use the feedback switches, it doesn't do any parity generation or checking.

1130 console printer typeball characters

Selecting which hemisphere (upper or lower case side) is done by the upshift and downshift command signals which take their own print cycle to actuate. The controller logic in the 1130 recognizes when the ball must be shifted to the other side and institutes an upshift or downshift operation transparently before typing the requested character.

Whiffletree adder for rotating a selectric typeball

The Selectric mechanism uses a Whiffletree mechanism to tighten up on the rotate tape in five steps, twisting the typeball to one of five step rotations away from its rest or home position. The R1 lever pulls the tape to rotate a single character away from home. The R2 moves two steps. R1 and R2 together will move three steps away. When R2A is activated along with R2, the typeball is rotated four positions from home and when R2A, R2 and R1 are all activated, a maximum rotation of five is achieved. It is not valid to have just R2A active, nor R2A and R1 alone.

The remaining lever, R5, is used to reverse the direction of rotation. This converts the sum computed by the Whiffletree to a negative number, twisting the typeball 1 to 5 steps from home in the opposite direction from positive numbers. Thus, R1, R2 and R2A select one of five rotations and R5 determines the direction of rotation of the ball. Including the home position, no rotation, this gives 11 positions around the ball where characters can be positioned. .

Tilt whiffletree and tape

The tilt mechanism has a simpler Whiffletree adder which only has to sum two bits for produce 0 to 3 as a tilt amount. This selects one of four bands circling around the perimeter of the typeball. The combination of four bands with 11 rotary positions each allows for the selection of any of 44 type characters on the hemisphere of the ball.

A different mechanism will rotate the ball 180 degrees when the "Shift" key is pressed to move between the upper case and the lower case halves of the typeball. Including these two halves, a selectric typeball has 88 addressable character positions.

To select the letter V you would switch on T1, R1, R2A and R5 which select tilt band 1 and rotate position -3. The 1130 typeball has capital letters on both hemispheres, confusingly, so that the same code T1, R-3 will print a V on either the upper or lower case sides of the ball.

For non-alphabetic characters, unique characters exist on each side. The character 2 is on the lower case side only, with tilt code 0 and rotation +1, selected by activating only R1. If the ball is turned to the upper case side, the same R1 will generate a + instead of 2.

The tilt, rotate, aux and command signals are all inverted logic - high when off and pulled down to logic level 0 when activated. The 1130 uses open collector drivers for these signals, allowing them to float to whatever level they wish until activated by pulling them to ground. With a real 1053, the lines float to +48V through the solenoids and the act of grounding them energizes the solenoid coil.

In my device, the Arduino provides a weak pullup to +5V on these lines, allowing the 1130 drivers to pull them to ground when activated. Since I have no way to set up the second Arduino as an open collector driver, I must temporarily switch off the pullup behavior on my device to allow the second Arduino to drive it properly.

I stuck seven signal jumpers and bridged grounds between these two Arduinos, driven and driver, then rustled up two laptops to connect them to. My goal is to work through the various characters to assure myself that I decode the bits correctly and drive the emulated typewriter. As part of the test I put a scope on the feedback lines to watch the CB Response feedback for appropriateness.

Testbed to drive select codes

After validating the tilt and rotate codes, I began focusing on the decoding and printing part of the emulator, issuing all the various shift and rotate codes for typeball characters. Once these were reliably working, both upper and lower case characters, the commands such as space and backspace had to be tested.

Most of the commanded operations are working fine, but I have some problem remaining in the LineFeed and Tab commands which are hanging. Working fine are space, backspace, upshift, downshift, CrLf, ShifttoRed and ShifttoBlack. I had to pack it in for the night but hopefully tomorrow will see everything working properly.

Part of the design is some tolerance to minor variations in the arrival of the various select lines from the 1130, matching the mechanical inertia in the Selectric mechanism and thus permitting a bit of skew in the turn on of tilt and rotate codes. I will add some minor delay between flipping on signals to test this out when I continue tomorrow.

IMPROVEMENT TO IBM 1130 CORE LOADER DEVICE

Based on another good idea by Peter Vaughan of TNMoC, I added an activation toggle character to the device. It powers up inactive, but can be turned on and set to the first location to load words by a character, then proceeds as before to load words and change the address as desired, until the activation character is again issued which causes the device to surrender control back to the human operator.

RESEARCH ON SUPPORTING THE APL (987/988) TYPEBALL ON 1053 EMULATOR

The APL language was supported by a selectric typeball but the language required more than the 88 characters supported on one ball. The solution adds some challenges for my 1130 console printer emulator.  There are 18 characters which were formed by typing one character, backspacing and typing a second character, the combination of which represents a single new APL character.

APL characters that existed at the time of APL/1130

If I look back at the last two print operations in my emulator, I could match the 18 sequences of char 1, backspace and char 2 from the table. If writing a terminal emulator for the PC side of the emulator, I can replace those triple character sequences with the unicode representation of the intended single APL character.

There are at least two other ways to accomplish this with the emulator. I could watch in the emulator and when detecting the last of the three character sequences, I could backspace again and then emit the appropriate unicode. Or, I could create each print line graphically rather than as text, so that a backspace does not erase the pixels left with the printing of char 1. Then, the pixels from char 2 would be added to form the appearance of overstrike on a typewriter.

The problem with the last method is that the data is really graphical images, so that any stored file from a session would not be searchable for text and instead will print as a bitmap. This may or may not be acceptable to a potential user.

The middle method allows for any terminal emulator that implements the ASCII backspace by erasing the prior character and positioning the cursor back one column. The first method requires a custom terminal emulator be written to address these compound characters. 

Improved version of IBM 1130 Console Printer emulator, plus work on possessed Diablo drive for Xerox Alto

WORK ON DEMONICALLY POSSESSED DIABLO DRIVE FOR XEROX ALTO

This Friday we put the heads back on the demonic drive, a Diablo disk we are repairing for a fellow Alto owner. This drive has not only fought long and hard against restoration, damaging heads, cartridges and egos, but has the uncanny ability to cause other, previously working, drives to fail when brought in contact with this evil device.

The heads were aligned and we confirmed the problems writing on this drive. It writes sectors which have a high chance of encountering read errors when the sector is read at some later time. Using my disk tool, if the exact same pattern were written to the sector multiple times, eventually the sector would read cleanly. Any variation in the pattern, even the nondeterministic variations on a real Xerox Alto due to other demands on the CPU, and there is no improved readability.

We examined the command signals for writing and turning on the erase head, which were all good. This makes sense because the drive would fail with swapped read/write PCBs from working drives, so the flaw couldn't be in the board itself.

We swapped a third read/write board into the drive, one from our working Diablo drive in our Alto. It produced much much better results in the demon drive. We brought the entire demon drive along with our good read/write PCB over to hook to the Alto, where we found that it was almost good enough.

We found it worked adequately most times when writing on the first half of the cartridge, but at high cylinder numbers it became much more prone to read errors after writing. Because the bit density increases as the arm moves to concentric tracks nearer the hub, we found the drive had circuitry that boosts the write and erase current when tracks from 128 to 203 are being addressed.

Again, this drive is right on the margin of working properly. Swapping among three seemingly identical read/write PCBs, we find that one of them produces behavior a bit better than the other two. We see a deficit in current through the heads, although the static resistance of the head windings are the same on all drives. Further, both the top and bottom heads work the same way.

True to the demonic nature of this drive, when we reattached our working Diablo drive back into the Alto we found that the contact had once again spread badness to the innocent drive. Our arm motor was no longer seeking.

Of course, once we took the drive out and did some detailed investigation we found that it was working properly again. We know of no mechanism that would leap across an air gap to a powered down drive and damage the arm motor solely because a card was in the demon drive earlier or the cables had been attached earlier to the demon drive.

This is once again a very striking coincidence. We suspect we may have a slowly failing rotary arm motor or drive electronics, something we will have to watch and fix once it stays broken long enough to track down.

As for the demon drive, we will continue with additional tests next week until we figure out the real issues and appropriate ways to resolve them. 

ENHANCEMENTS TO IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I received a number of good suggestions from readers of this blog, almost all of which I incorporated into a new version of the PC1053 emulator device. One I chose not to add since it would give different behavior than a real 1053 console printer and one I dropped after testing because the effect was not discernable.

The device will not simulate the actual time that a long operation (tabbing or carrier return) will take place, rather than a fixed representative time as originally designed. It is based on the high speed return feature built into the 1053 console printers used with the IBM 1130. These will take a bit over a second to return from the maximum distance of 120 columns. Tabbing occurs at a rate of 40 columns per second.

Tab stops can be set and cleared by the operator at the PC terminal emulator by issuing new commands TS xxx and TC xxx to set or clear tab stops at column xxx. This allows the user to programmatically set the tab stops from a PC file such that they are remembered across sessions.

One suggestion was to mimic the autorepeat key behaviors found on newer Selectrics and modern terminals, where a key such as space initially fires once, but with an elongated push, it will begin to produce multiple repeating spaces until it is released. Since the 1053 console printer does not behave this way, even though it would be handy, I am not going to build this into the emulator.

My first take at the design would have the column indicator, a three digit display, leap instantaneously from the current position to the next tab stop. There was a suggestion to have the digits change at the rate of movement of the carrier, providing a ripple effect on the display as it moves.

At first I was building that into the device so that it changed the numbers on the column display as it sat in the state machine for the tab or CR movement. However, I discovered that the numbers changed so rapidly that one could not see much other than a blur. A tab of 60 columns occurs in 1.5 seconds, thus the one's digit changes in 25 milliseconds and the tens digit changes each 250 ms.

I relaxed the realism a bit, doing a quick blur of the column display after the tab operation has completed. It still gives the impression of quickly tabbing across, a flickering rather than instant change, but doesn't attempt exact timing on the display; only the feedback signal to the 1130 has exact timing.

On a real 1053, if a CR is requested when the carrier is to the left of the left margin, it will return all the way to column 1. I handle the left margin by spacing over after each \r is sent to the terminal emulator, such that the text prints at the appropriate offset from the left edge.

I mimic this behavior, where CR from a column before the left margin will return to 1, but once the carrier has advanced past the left margin, a CR brings us back to the margin. It took a bit more code to make this happen, but it is a more realistic behavior.

My testing showed all actions I could test with buttons and commands were working properly. Tomorrow, I will have to dummy up a way to inject tilt/rotate and other commands the same way that the 1130 will, to verify the rest of the code.

Build of IBM 1130 console printer (1053) emulator along with testing

BUILDING IBM 1130 EMULATOR FOR 1053 CONSOLE PRINTER

My parts all arrived allowing me to begin wiring up the emulator for the console printer of the IBM 1130. This printer is a 1053, an I/O or computer drive Selectric typewriter sans keyboard. The 1053 printer attaches to the 1130 computer via three SMS paddle cards - two for signals and one for power.

My device is wired with two paddle cards to plug into the two signal card sockets in the 1130. The device is built into a box, with the cables out to the paddle cards coming from the rear and a USB cable on the side to attach to a PC.

The feedback signals that are sent back to the controller circuits, which are expecting 48V and 12V. While I could build in two power supplies just for this need, it is probably easier to grab power from the 1130 via the third SMS paddle card that supplies the 1053 with 48V, 12V and 220VAC. I only need the two DC voltages and ground.

I first wired together two small boards, one holding 3 side by side 7-segment displays that will show the current print column. On the real 1053, a horizontal plexiglas strip on the front face of the printer has numbering across it and a small blue indicator attached to the typewriter carrier moves to show where the typeball will strike next.

These displays will be fed by my code in an Arduino Mega 2560 mounted in the box, which tracks the location based on spacing, backspace, carrier return, typing and tab activities to reflect where the 1053 carrier would have been at any moment. I output three BCD characters to 74LS48 chips which drive the common cathode 7 segment displays.

A real 1053 has three blue buttons across the bottom of the front face, to allow the operator to space, tab or return the carrier to the left margin. My device will have three red rectangular pushbuttons for these functions, placed below the digital column display.

IBM 1053 console printer

In addition, a real 1053 has a blue toggle handle on the left side of the front face which is pushed upwards to set a tab stop at the current column or pushed down to clear a tab stop at this spot. I installed two more red pushbuttons, mounted in a column on the left side of my box, to provide the set and clear functions.

The circuits inside an 1130 that control the 1053 effectively open collector drivers, although they have a snubber diode to absorb the reverse EMF when the solenoid coils are switched off. The solenoids inside the 1053 are attached to +48V and the other ends run to the 1130 driver cards.

Since these are open collector cards, I will be switching 5V instead of 48V. Further, with no solenoid coil involved, there is no reverse EMF. I configured the Arduino inputs to pullup mode, meaning that a resistor inside the Arduino keeps the line at 5V unless the open collector driver circuit activates and pulls it to ground. This makes the inputs inverse logic - high means not active, grounding them is a logical 1.

A 1053 printer has a number of microswitches inside that collectively provide four feedback functions. In the 1053, they take 12V from the CPU and switch it back to the 1130 to indicate when the print cycle is active and when the machine is busy doing long actions such as tab or carrier return. The other two lines indicate when the carrier it at the right margin and when there is no more paper. The 1053 has a pin feed roller and takes continuous form paper with pinfeed strips on each side.

Due to the 12V requirement, I control relays from the Arduino at 5V and those relays switch the 12V to the feedback lines into the 1130. Some resistors round out the component list for this device. Inside the box I have an Arduino, digital display board, 74LS48 driver board and a resistor board mounted.

Column display active

I had to carefully mark and cut out the locations for the five pushbuttons and the three 7 segment displays to be mounted on the board. Additionally, I had to mark and drill holes for the mounting screws for the various boards inside the box. Finally, the holes on the back for the SMS paddle card cables and side for the USB cable were drilled. 

I updated by Arduino code to provide for logical commands from the user terminal to the device, to set the left and right margins. Eventually, I could add support for switching the typeballs since the 1053 could optionally make use of an APL character set ball when the machine was running APL. 

Testing began with the commands from the PC, then proceeded to test the five buttons that provide SPACE, TAB, CR, TabSET and TabCLR. I tested them in concert with the margin commands to ensure that a CR took us to the left margin, that space moved us forward and that tabs were appropriately set and advanced to the proper stop. 

I discovered a few problems and cleaned them up. By the end of the day, I could set and clear tabs stops. tab reliably to the location, do carrier returns back to the left margin and space ahead. The space button will fire space cycles as long as the button is depressed. Since the Selectric will cycle at 15.5 characters or spaces per second, it is quite hard to get just one space. 

The solution will be modifying behavior of the buttons, which I will achieve electrically rather than trying to handle this in the Arduino code. I want the behavior to be reasonable for an operator. Therefore I want a one-shot that sends one short pulse to the Arduino then stays off until the button is released by the operator. 

Time to build three one-shots on a small PCB - the tab set and tab clear buttons are pushed while the column is not changing, and are idempotent, so multiple actions while the button is pressed are not an issue. 

Thus the remaining tasks are:

• Build and test the three one-shots
• Rewire existing device to use with one-shots
• Simulate various signals from 1130 and observe results on scope
• Mark and cut openings on box for displays, pushbuttons and cable exits
• Install and wire two SMS paddle connector cables into the device
• Mount Ardinuo, displays, switches and related boards
• Install and wire third SMS paddle connector for 48 and 12V power
• Install and plug in long USB cable to Arduino
• Test on an IBM 1130 to verify correct operation

Pictures of the recent conversion of a 9 track tape drive to archive 7 track tapes

CONVERSION OF 9 TRACK QUALSTAR DRIVE TO 7 TRACK FOR DIGITIZING FLUX

I recently posted an account of the installation of a 7 track head to a 9 track tape drive, allowing the magnetic flux reversals to be recorded by a logic analyzer and converted to tape contents by software postprocessing. Because I took no pictures during the work, the prior entry was pure text. A reader has asked for pictures (for the work in question and also for future posts).

Dual 9 and 7 track head (7 tracks on left)

Rubber wrapped cables from new head, plus existing wires from drive to its old head connectors

Anchor board during wiring, to adapt existing head connector to the new head's cable

Read board in the Qualstar drive, with 9 identical columns of electronics

Qualstar drive moving tape across head while we examine the signal from the head

Example of our pairwise tests with paper shim between head and tape, top channel declined first in this test

Enhancements made to the 1053 Console Printer emulator for IBM 1130

IBM 1130 CONSOLE PRINTER EMULATOR (FOR 1053 PRINTER)

I decided to improve the project I roughed out and coded a few days ago, adding more complete emulation of the 1053 console printer atop the IBM 1130. The 1053 is based on the IBM selectric typewriter, an output only version of the 1052 which was the operator console on the IBM 360 mainframes.

The 1053 attaches to the 1130 system through two SMS paddle cards and a power connector. The paddle card is a short printed circuit board that mates with the 16 signal SMS socket - using technology developed for IBM's transistor generation of systems such as the 1401 and 7090.

Typing a character involves triggering one or more of the tilt and rotate signals, which starts a print cycle on the typewriter and causes the print ball to tilt and rotate to bring the intended character to face the paper as the ball strikes forward through the ribbon to the paper.

In addition to typing a single character, the mechanism can be asked to space, backspace, tab, return the carrier, drop to a new line, shift to 'upper' or 'lower' case mode, and shift between red and black ribbon colors.

The typewriter has a series of microswitches that provide feedback on the status of the mechanism. Selecting the new character to type has to wait until the print cycle is nearly complete from the last typed letter. Letters shouldn't be typed while the carrier is still moving towards the left or moving to a tab or the paper is moving down to the next line.

My emulator will capture the requested letter or action, but also provide the appropriate feedback at the same timing as a real 1053. On the front of a 1053 printer are three pushbuttons and an up-down toggle lever. The lever will set or clear a tab stop at the current column. The buttons cause a space, tab or return to be performed. An indicator shows through a horizontal plastic scale to mark which column the carrier has reached. 

My initial design did not display the current column. It had no means of requesting the space, return or tab operation that is provided by the three buttons. More seriously, it made a naive assumption of tab stops a fixed number of columns apart, rather than allowing the setting or clearing  of arbitrary stops. 

Many programs written to use the 1053 would expect the operator to set up tab stops at suitable positions - using a simplistic tab scheme would distort the output. I therefore decided to model the tab lever and three buttons. Three seven-segment LED displays will show the current column number digitally. 

The Arduino had 26 unassigned pins based on my initial design. 9 pins were sufficient to drive three BCD to 7-segment decoders (the high order display wired to only decode 0000 or 0001). Five more signals hooked to five pushbutton switches will provide for the faceplate functions of the 1053.

I have ordered all the parts, other than a larger and more suitable enclosure to hold the emulator, its display digits and pushbuttons. I have SMS paddle cards and sockets to wire up everything, once the remaining parts arrive.

There are a last two dimensions of the 1053 that I was not fully reflecting with the emulator. Two of the characters on the typeball of the 1053 are not in ASCII. The cent sign ¢ and the logical not ¬ are those missing characters. 

A solution is the UTF-8 encoding supported by many terminal emulators, which would let me represent the two characters properly. Too, using a terminal emulator program with mono color type would not display the effect of programs choosing red or black ribbon colors. Thus I would need to adopt some color selection mechanism that fit with common emulator programs. If the terminal program supports ANSI color selection, I can make use of that. 

I can switch to UTF-8 and capture the two missing characters from their Unicode values, rather than my initial decision to type some artificial string such as {cent sign} which will distort spacing of the remainder of the typed line. It does not fix the ribbon color issue but UTF-8 would at least cause each letter to take up one column on the screen. 

The ANSI colors are selected by sending a sequence esc[##m to the terminal, where esc is 0x1b, and the one or two digits of ## are:

• 1 sets on bold mode (higher intensity)
• 0 resets intensity and other color selections
• 47 sets the background to white
• 30 sets the foreground (text) color to black
• 31 sets the foreground color to red

I therefore set the terminal initially with esc[0m esc[47m and esc[30m then process a shift to red with the sequence esc[31m and esc[1m while a shift to black is the sequence esc[0m esc[47m esc[30m sent to the terminal. 

My final bit of code converted the integer column number to ones, tens and hundreds digits, then wrote each out in BCD to the hardware that will convert BCD to 7-segment LED display drive signals. 

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.