Monday, March 18, 2024

Battling the diagnostic program until I can run it on the physical 1130

NEW SIMULATOR AUTHOR SENT ME AN UPDATE THAT FIXES THE SWITCH ISSUE

The new version of the 1130 simulator, still in development by its author, includes support for the Console/Keyboard switch on the 1130 console with proper indication in the Area Code 1 device status word, bit 5, of the position of the switch.

This would allow me to more fully test the diagnostic memory image on the simulator that I would then be loading into the physical 1130 core memory. I am hoping it arrives any time now

ISSUES SETTING UP DIAGNOSTICS ON SIMULATORS

The proper execution of the keyboard/1053 diagnostic requires a working Console/Keyboard switch on the 1130, however the simulators I had do not implement that switch and default it to the Keyboard setting which blocks the diagnostic from testing the printer. 

Loading diagnostics involves stacking multiple card decks in a card reader and booting from the card reader. The relocatable loader (program 3AA) then reads in the diagnostic monitor (program 300) and the monitor reads in various diagnostic routines. In our case, we want to read in program 304 to test our console printer. 

It may seem simple to just put the three decks sequentially in the hopper and boot the reader, but the lack of accurate emulation of the card reader introduces failures. The simulators treat the readers as simplified devices, which is convenient to shield users from the complications of real 1130 operations, but that infidelity leads to problems. 

The card readers have a hopper into which cards are stacked and a station inside from which each card is read and ejected into the stacker. Because a card has to be fed from the hopper to the internal station prior to doing a read, the operator pushes the start button and the first card is fed into the station without the CPU or program noticing. 

When the bottom card in a hopper is fed into the machine during the read of the prior card, the machine turns off the Ready state. The last card is physically sitting in the internal station but cannot be read because the machine is not ready. This behavior is intentional as in the real world, very big decks of cards are used with cannot all fit in the hopper at one time. Each time the hopper empties, the operator adds more cards from the deck and pushes Start which turns on Ready and allows the program to continue reading more cards. 

However, when the hopper empties and the card in the internal station is really the final card of a deck, the operator just pushes the Start button without adding new cards to the hopper. Pushing Start with an empty hopper turns on the Ready status but also sets an indicator when the final card is read. This bit in the device status word, Last Card, tells the program that we should not loop attempting to read more cards. 

The simulators turn on Last Card automatically as the hopper empties. In real life, I could put the 3AA relocatable loader in the hopper, push start, and then boot it. When it came to a halt with the reader not ready, I could then put the 300 program deck in the hopper and push start. The machine would read the last card of 3AA and then that program would begin reading the subsequent cards from 300. 

When the 300 deck has its last card leave the hopper, the Ready condition goes off. Still no Last Card status. We add the 304 deck into the hopper and push Start. The 3AA program reads the last card of 300 and then the 300 program begins reading cards from the 304 deck. 

When the last card leaves the hopper of 304, if I push Start without inserting a new deck, the last card of 304 is read by 300 but the logic of the program will still try reading additional diagnostic decks, ignoring the Last Card status. 

For the 300 program, one must add a blank card to the end of the last diagnostic to be read by 300. Then, when it gets the Last Card and sees a blank, it begins executing the diagnostic program(s) it loaded. 

Thus the behavior of the reader and the Last Card indicator is quite pertinent to loading the diagnostics properly. the only way I can make this work is to stack the entire set of three programs (3AA, 300 and 304) plus a blank card into the hopper and boot the CR. 

Even after solving the card reader related issues, we have to choose when and how to stop the simulated 1130 in order to dump core contents that can be restarted on the real 1130. Restart is funny with the diagnostics, as one is actually first restarting the Diagnostic Monitor (300) which then restarts 304. Very easy for things to be tripped up so that the program does not start executing properly on the physical 1130. 

GETTING A SUITABLE MEMORY IMAGE THAT WORKS ON BOTH SIMULATOR AND 1130

I did find a version that I had hacked previously so that the monitor believed the switch was set to Console and didn't flag the actual state of the bit 5 as an error. With this version, I can restart on either simulator and see the 1053 output stream. It will not allow me to switch the diagnostic into keyboard mode where it echoes every keypress to the 1053, but I know the keyboard is working. 

TESTING WITH THE CONSOLE/KEYBOARD SWITCH 

I have two routes to testing on with the console/keyboard switch to  run both modes of the diagnostic. First, I can test on the simulator after I receive the new update, letting me figure out a memory load of the diagnostic that works when restarted and uses the Console/Keyboard switch. Second, I can figure out where I hacked the current memory load and adjust it so that it works with the physical 1130 and its switch. 

I will first complete the typewriter side run of the diagnostic to complete the formality that all is done on this 1130 restoration. Later I will do this testing so that they diagnostic runs on the restored machine with both modes depending upon the key setting. 

Making the keyboard Space bar work properly is continuing to be a challenge

LOOKING INTO THE POOR SPACE BAR OPERATION

The keyboard mechanism of an IBM 1130 is the same keyboard mechanism inside the IBM 024 and 029 keypunches, which were introduced along with the S/360, 1800 and 1130 systems in 1964. The mechanism was derived from the earlier keypunches such as the IBM 026 which was introduced in 1949 and continued on designs from much earlier in that century. 

On this machine, the space bar is quite low, barely is detected and may not restore properly. I had inspected the underside and found that a leaf spring associated with the key was out of position and perhaps adding friction. I fixed that, reassembled the machine but the problem persisted. 

I decided to really dig into the unit to figure out what was going wrong with Space and making it work well. That involved splitting the keyboard assembly into its two halves. 

DISASSEMBLY OF THE 1130 KEYBOARD TO IMPROVE SPACE BAR OPERATION

Physically the keyboard is two parts bolted together, the key unit and the permutation unit. A key unit has the physical spring loaded keys, a mechanism that ensure no more than one key can be pressed down at a time, and some levers that project into the permutation unit to select the permutation bar assigned to each key. 

I separated the two as my issue is mechanical, most likely in the linkage from the space bar to the permutation bar but possibly in the permutation bar latch for that key. Both are exposed by the separation. 

KEYBOARD OF THE IBM 1130 - EXPLANATION

It is a complicated beast because it has to convert the push of a single key into the Hollerith code associated with that key. For example, the letter a is a combination of the 12 and 1 rows on a punch card thus its Hollerith code is 12-1. a $ is 11-3-8 as it has three holes punched (in rows 11, 3 and 8). The numbers themselves were very simple, the digit 4 is a hole in column 4 or Hollerith code 4. 

Add to this complication the fact that the keypunch had more characters than physical keys, such that it needed a shift key. This was generally labeled the Numeric key and pushing it would encode an alternate character for each key pressed. 

As you may be able to see, the key marked F has a semicolon (;) printed above the F. If the Numeric shift is held down while pressing that key, the card has a code of 11-6-8 but without the shift key this must produce 12-6 instead.

Handling the code translation for shift as well as the need to emit multiple row signals for a single key press involved a combination of mechanical and electrical solutions. The keylever would latch down and lock the keyboard, but in that latched position it will cause a permutation bar to be pulled downward in the back half of the machine called the permutation unit.

The Hollerith code was generated by switches activated by the permutation bar so it had to remain down and locked until the computer had captured those bit values. A restoring solenoid was activated by the computer (or the manual KB Restore button) which pushed the permutation bar back to its idle position and pushed they key back up. Thus typing at speed involved the keyboard latching, the computer grabbing the character and then restoring the keyboard before the user's finger next pressed a key. 

Each permutation bar has fifteen notches in it vertically, which align with fifteen pivoting horizontal bails. A bail has a microswitch at the end, thus pivoting a particular bail closes the circuit for that bail. Each bail has tabs extending backwards for every key that should pivot this bail. Lack of a tab means the bail does not energize. 

Tabs on a bail to associate it with certain keys

Contacts on the sides of bails, switched when bail rotates

As we can see, pressing a key activates certain bails so that we translate one key into a pattern of 15 bits. The astute reader may wonder at this point why not just use 12 bails, so that the output is the direct Hollerith code for that key as it twists selected bails. The reason is the Shift key and the second set of characters associated with most keys. 

At the bottom of most permutation bars is a microswitch that is closed when the permutation bar is latched downward. Thus, we actually have 15 bits from the bails plus 1 bit from the latch contact below the permutation bar. 

The shift keys (Numeric and Alpha) direct power to bails and latches. Some bails are only powered by the Numeric condition and others only by the Alpha condition while one is powered by the joint Alphameric bus. Similarly the latch contacts are powered the Shift, Numeric or Alphameric buses. Alphameric is the always powered whereas Numeric and Alpha are switched by the Numeric key. 

Wiring of 1130 keyboard

The bail contacts are circled in green, the remaining are the latch contacts. This clever connection of latch contacts, bail contacts and the Numeric key along with the selective use of tabs to activate bails produce the Hollerith codes for all the keys.

A few of the keys on the keyboard do not latch down nor activate permutation bars - Numeric and KB Restore. Some do their encoding purely through the latch contacts - Space bar, Erase Field, End of Field, Backspace and Interrupt Request - even though they latch down the permutation bar. 

CAN'T FIND SOURCE OF PROBLEM IN EITHER HALF

I looked carefully, tripped and reset the permutation bar for the Space key many times, verified that the linkage from the key on the key assembly was good as well. 



As is visible in the top picture, the keys have those long levers with right angle hooks. When a key is depressed, the hook is pulled backwards into the key unit. That hook fits around the triggers you can see in the upper opening of the picture immediately above this text. It pulls forward on the trigger there and the permutation bar is moved downward to its latched position.


These are the permutation bars with their latches at the top half of the picture. The far side which you can't see has the fifteen notches that can move tabs on the bails. In the case of the Space key, the hollerith pattern is an absence of holes (bits) so there are no tabs fitting into this permutation bar. 


The bottom of each permutation bar will press down and close a set of contacts (the latch contacts) when that bar is locked down. In the case of the Space key, the only electrical connection made is the latch contact below the permutation bar, which tells the controller logic that a space was pressed. 

I can see nothing wrong or even different with the space permutation bar and any other one. Similarly I can find nothing wrong with the space key mechanism and its lever that trips the permutation trigger - the same as the others on the unit. No signs of corrosion, rubbing or other friction. 

REASSEMBLED AND TRIED AGAIN

I put the two halves together, the keyboard back in the 1130 and closed everything up. The space bar was working fine as I held the keyboard in my hand, so I was hopeful. Alas, when closed up in the machine, the space key was back to its bad ways. Even worse, when I powered up the machine, I heard nonstop restoring which is an indication of some new problem I introduced in the keyboard probably a contact that was disturbed. 

RAN OUT OF TIME BUT WILL SOLVE THIS TOMORROW

Tomorrow when I return to the shop, I will bring two things. I will bring a version of the printer diagnostic that I believe will function well enough to work out the 1053. I will also come with a new theory that something is mechanically binding when the keyboard unit is screwed down into the 1130 or when the lamp & pushbutton plate is placed over it. 

Adjusting 1053 printer and achieving excellent results

CHECKING AND ADJUSTING SINGLE SHOT TIMERS FIRST

The controller logic for the 1053 is oriented around a pair of single shots - timers that emit a single pulse of a fixed duration when activated. They are intended to last 25 milliseconds each. The selection solenoids are activated during the first 25 millisecond interval and not active during the second 25 millisecond interval. The logic waits to get the feedback from the -CB Response and +TWR Interlock wires from all the switches in the typewriter, keeping on an interlock latch until the feedback shows we are done before ending the print cycle and giving status to the CPU. 

I put the oscilloscope on the test point and turned some potentiometers until the timers were 24 ms long as they fired, based on the numbers in the IBM 1130 FE Maintenance Manual. This ensures that the solenoids are powered for the right amount of the cycle and removed after the selection has been locked into the typeball by the detent.

Probes to watch the SS duration

Adjustments for single shot card

Single shot outputs

INTELLIGENTLY SETTING THE PRINT CYCLE SWITCH

The issue that causes problems with continuous print cycles is that the solenoids are moving the tilt and rotate mechanism while the ball is still locked at its current position. The make timing of the contact for print cycles was moved forward until the point where the ball detent was completely removed. The ball is then free to swing to whatever tilt or rotation position it wants even though it is pivoting back to its rest position. 

Unit out and ready for adjustment

I had several points of reference, including the position of the bails moving up and down at the time the switch should close, the condition of the detent on the typeball when it is safe to start selecting new rotate/tilt positions and the degree wheel markings. I was quite confident by the end that I have the print cycle feedback adjusted exactly right. 

Print cycle feedback switch with cam

Top with setscrew visible

HAND LOOP RESULTS WITH CONTINUOUS STREAMS

I used a very tight hand loop to fire off 1053 commands as rapidly as it would report completion of the prior action. I chose a number of worst case situations, such as adjacent characters at the extremes of rotation (-5 and +5), adjacent characters at the extremes of tilt (0 and 3), and quite a few combinations I threw at it. 

The typewriter performed brilliantly, the print quality is excellent and I am only waiting to run the KB/1053 diagnostic as a kind of formal signoff but have no doubt the console printer will ace any test thrown at it. 

Good output

STILL FIGHTING TO GET THE DIAGNOSTIC TO RUN AGAIN

After time single stepping through instructions and poring over the program code, I see what has happened. When I prepared this memory image, I set bit switch 15 on which tells the diagnostic monitor to load the next test (304 - the KB/1053 diagnostic) but halt it initially. This was used so that options could be set before starting the diagnostic. 

Indeed the code was loaded and the entry is properly set up in the tables inside the diagnostic monitor. The problem is that the monitor will start a halted program only once - when it first sees a restart with the halted diagnostic - but after that it considers that the diagnostic completed successfully and will never run it again. There seems to be no way to ask the monitor to run it again. 

I am still waiting for the update to the simulator which will give me the use of the Console/Keyboard switch allowing me to build a memory load that I am able to prove will work by running it on the simulator. I see the execution of this program as only a formality. 

Sunday, March 17, 2024

Some diagnostic runs - successes and minor setbacks

CPU DIAGNOSTIC RUN COMPLETED

The code exercised every variant of every instruction and all the corner cases. When it was complete, we can be certain that the processor is working perfectly. 

KEYBOARD AND 1053 PRINTER DIAGOSTIC RUN STILL NOT COMPLETE

I continue to have difficulties getting a version of the diagnostic in core that will continue and operate on the real machine. The challenge is due to shortcomings in the 1130 simulators that I have been using to set up programs before saving the memory image. 

The IBM 1130 has a switch on the console which is a lever that can be flipped to either Keyboard or Console setting. This drives one bit in the device status word for the printer/keyboard (area code 1), with a 1 in bit 5 if the switch is set to Console otherwise 0 for Keyboard. It does nothing at all other than reflect its setting in the DSW. 

The 16 console entry switches are a unique area code - 7 - and can always be ready by an XIO. The purpose of the switch, therefore is advisory to the program. There are programs that either expect the operator to type in values on the keyboard or enter values on the console entry switches based on how this switch was set. 

Programs can make use of this switch to select between different modes of operation or parts of a program. The diagnostic monitor program that hosts many of the more sophisticated diagnostics, including the keyboard/printer one, watches for the switch and informs the test programs of its setting any time the switch is changed. 

With the switch flipped to keyboard, the diagnostic will select the keyboard and echo every character pressed on the 1053 typewriter. The switch when flipped to Console causes the diagnostic to run a number of tests for the 1053 correct operation. 

The IBM 1130 simulator written by Brian Knittel and shared on his ibm1130.org website does not implement the switch. It is a labeled graphic on his GUI of the console but it doesn't switch nor drive the DSW bit 5. The result is that the switch always appears to be in the Keyboard setting, thus the diagnostic won't test the 1053 other than by an echo of keys but only as fast as you can type them. 

A much more accurate and complete simulator is being developed by a professor from a university in Brazil and I have been using an early, pre-publication copy to run things that fail on the original 1130 simulator. Unfortunately, at this time while the simulator has a switch that you can set to either position, its state is not reflected in the DSW. Once again, the default appears to be a setting of Keyboard so the diagnostic won't run on the new simulator either. 

I did some hacking to get it to run once or twice a few days ago, but I struggled through much of today without having a memory image that will start up on the real 1130 and run the printer side of the diagnostic.

HANDLOOP TESTING OF KEYBOARD AND 1053

I set up some simple hand loops in the machine to check out the keyboard and the console printer. The program for the keyboard would display in the 1130 accumulator the resulting code for any key pressed. I could check these against the Hollerith code assigned to each character and found them all to produce the proper bits. I did discover that the Space bar was wedged kind of low and not very reliable. 

The hand loop for the 1053 would read the console entry switches as a pair of typewriter codes and issue them. It runs rapidly. Sometimes I single-stepped the routine to watch the results and to verify that the machine correctly selected every character. Other times I let it run continuously. 

I was able to verify that the controller logic did detect the end of line and inserted an automatic carrier return and line feed as needed. I did sot some anomalies, in fact it appeared that the feedback switches I so carefully set to the manual specifications made some behaviors worse. A string of characters that are in the same case produced a string of J on the paper with some crowding. If I continuously issued pairs of a CR and a printed character, the typed character was not always in column 1. This may be a result of a very short 2 column return but it may be an adjustment issue. 

WORK NEEDED TO CORRECT THE ISSUES I SPOTTED

There is a mechanical issue in the keyboard which makes the Space bar stiff, both hard to depress and hard to restore. I may have to partially disassemble the keyboard to find and correct the issue. 

I plan to put my oscilloscope on the machine to monitor the feedback lines while I perform the hand loop on some of the problem situations. I will check the duration of the single shot timers in the controller electronics as well as time my response signals. 

As for the erroneous J output, I know I can correct this by extending the duration of the print cycle feedback switch. The worst that can happen if it is too long is that the typewriter never hits its max 15.5 cps pace, which is better than trying to fire solenoids while we are still in the midst of printing. 

Finally, I will continue to work on ways of getting a valid memory image of the diagnostic such that I can fire it up in Console mode and test everything fully. 

Saturday, March 16, 2024

Ran core memory diagnostics and adjusted various items on the IBM 1130

I USED THE CONSOLE LOADER TO LOAD VARIOUS DIAGNOSTICS TO MEMORY

Because this loader is operating switches normally intended for the human operator, it isn't very fast. We load a bit more than four core words per 3 seconds elapsed time, so that a full 8K machine load would require one hour and forty minutes. Fortunately the diagnostics are all developed to fit in the smallest 1130 configuration, 4K words, thus the load time is always less than 50 minutes and sometimes substantially less for simple tests. 

If my unreliable Lenovo laptop would avoid blue-screening for that length of time, I would load memory. It was quite hard today and I finally dug out an old Win 8.1 tablet and set it up to load core. 

CORE MEMORY TESTS

I ran a set of core memory tests that hammer away at all the core locations to find any issues. It runs as both a high and a low test. Since the code for the test has to sit in memory, it means those relatively few addresses are not checked with one test. The two different tests use different regions to place the test code, thus running the pair ensures that all 8,192 words are checked out. \

ADJUSTED ALL THE FEEDBACK SWITCHES IN THE 1053

I found that several of the feedback switches were badly out of adjustment. I am not surprised since so many of the machine's adjustments were also very bad. I patiently worked through all seven until I was certain the switch made and broke at the correct times. 

Three of the switches cover the one-cycle long functions, ensuring that no new commands are sent during portions of the cycle when nothing else should be moving. The print cycle is one such function, where the switch informs the controller electronics that the print is in progress and later lets the electronics know when the cycle can be considered over. 

Even if the there is a bit more time spent with the type ball returning to rest, for example, it is safe and efficient to trigger the character selection solenoids for the next character to be printed. The machine does not need to stop at the end of a cycle and start up again, in this case, so that it can achieve its maximum print rate of 15.5 characters per second. 

A shift cycle to reposition the typeball between the upper and lower case sides of the element are times when the control electronics should not trigger a character print cycle. This switch reflects the shift activity and informs the electronics when it is safe to start the following print cycle. 

Finally, a space cycle involves one spin of the operational cam and movement of the carrier one column to the right, but should not occur with other functions like print, shift or tab. A switch reflects the state of the space operation back to the controller electronics.

Adjusting these involved a combination of actions. Some of the switches had to be disassembled and portions bent to achieve specific conditions, then all of them needed the position of their bracket adjusted. A couple also had cams whose relative position on the shaft needed a change in order to achieve the various make/break times within the tolerances specified.

To measure these, I used a continuity meter and the hand cycle wheel. It has degree markings to assess contact timings for shift, space and parts of tab and carrier return. A different wheel is attached to the print shaft on the other side of the typewriter to measure the degree of rotation for the switch during a print cycle. 

There are two indefinite duration functions on the 1053 - carrier return and tab. The time it takes is multiples of cycles and depends on the start and stop columns as well. While these are underway the controller electronics should not be printing or actuating other functions, so these are interlocks to block other actions. 

For both of them, the are triggered by an operation clutch which rotates to engage the mechanisms that move the carrier forward to a tab stop or backwards in a return operation. It takes finite time for the clutch cycle to latch in and begin the return or tab, but after that the function continues until it hits a tab stop or the margins of the machine. 

To cover these, a pair of switches in parallel are implemented for each of those indefinite duration functions - thus four switches in total. One switch is activated as the operational clutch begins to activate the return or tab. Once the mechanism has been latched into place for carrier motion, another switch detects that the pawls are forced out of the rack so that the carrier can zoom left or right. 

While the operational clutch cycle completes and its switch opens up, the switch on the return or tab latches takes over and continues the interlock interval until the ending event stops those functions. That is, either the carrier hits a tab stop or the carrier hits a margin. Having both switches for a function provides an interlock from when CR is first initiated until it is complete, or similarly from when a tab is initiated until the carrier stops at a margin or tab stop. 

ONE BIT NOT LIGHTING ON DISPLAY, WAS ONLY A LOOSE WIRE

As I was running and studying various diagnostics, I had noticed that bit 11 of the Storage Buffer Register (memory contents) was not lighting. I had recorded this, assuming that a bulb had burned out which needed replacement. However, when I did the Lamp Test function on the machine, all bulbs were illuminated.

When I opened the back of the display pedestal I could see that the wire bringing the signal for SBR bit 11 was not on the pin of the display board. I pushed it back in place and could check off this task as well. 

MINOR CONCERN OVER UNDOCUMENTED FEATURE INSTALLED ON THIS MACHINE

This machine has a featured called IBM Channel RPQ installed on it, which installs 37 SLT cards into compartment A-A1 and adds six unique connectors that don't exist on standard 1130 systems. These feed a connector that I believe was connected to a third party line printer. This feature provides access to fetch and store data in memory, to raise interrupts (generally on IL3), and to respond to XIO commands on area code 24. 

A failure in some of those functions could trigger spurious interrupts, modify memory without warning or corrupt data being transferred around in the system. This system did NOT come with its ALDs. Since I have never seen an ALD for a system with this RPQ installed, I have no documentation for what it does in case I need to debug it. 

Because IBM would customize ALDs for its 1130, 1800 and 360 systems, displaying only the parts that were configured for the specific serial numbered machine, it is very important that systems which need restoration have their specific ALDs on hand. 

This is only a minor worry because there is some documentation about the RPQ in this manual on bitsavers - Bitsavers manual - which has just enough that I could trace out the logic to reverse engineer this if needed. 

TOMORROWS ACTIVITY PLAN

I expect to perform final runs of the CPU diagnostics and the Keyboard/Printer diagnostic as a checkout prior to preparation of the machine for shipment. 







Friday, March 15, 2024

Verification of 1053 Console Printer - final testing

CHECKING OUT THE SENSE BITS

Area code 1 (the device address) is shared between the keyboard and the 1053 typewriter, since one is input-only and the other is output-only, so the correct subunit is inferred from the type of IO request. Because they are shared, the device status word contains bits for both subunits. We are concerned only with the bits associated with the typewriter:

  • Bit 0 - The typewriter has responded/completed a request
  • Bit 2 - The device(s) that responded raised a request for interrupt on level 4
  • Bit 4 - Printer busy - has received a request but not yet responded with completion
  • Bit 5 - The printer does not have paper forms in it or is busy

I can test out these with some hand code to issue a command that is long, such as carrier return, and then immediately check status. I should see bit 4 on because it is in the midst of the operation, but no other bit at this time since we didn't wait for the typewriter to finish.

Putting the machine in Single Instruction mode while doing the above will let me check the DSW after the carrier return has completed but before the computer accepts the interrupt request from the device. I should see bits 0 and 2 turned on, the rest off. 

When I step through the interrupt handler and reset the device during the Sense DSW, all bits should be off. 

Finally, I can take the paper out, issue a sense DSW, and see that bits 4 and 5 are turned on. 

Using the above procedure I tested the controller logic and am satisfied that the DSW is being handled properly. 

USING THE IBM DIAGNOSTICS TO SHAKE OUT THE TYPEWRITER

Once it appeared that the 1053 responded properly to space, backspace, CR/LF, LF, tab and character typing, including shifting between cases and shifting ribbon colors, I could move on to the next phase. That phase used my console loader feature to load core memory with the 1053 diagnostic program, then test the printer with that diagnostic suite. 

I used an IBM 1130 simulator to load the card decks that start the console/keyboard diagnostic program, then when it paused waiting for operator action, I dumped the virtual memory to a text file. I only had to add the activation and deactivation commands to the front and back of the file to have it ready to load into the physical 1130.

My console loader issues a prompt (> character) when it is ready for the next command, thus I needed a program to upload the text files of loader commands with pacing. I remember terminal programs in the past that had a standard capability for text file transmission where I could specify a prompt that the program waits for. However, none of the programs I have or found have this as a menu choice - Putty, Teraterm, and Hyperterminal are among the serial terminal emulators that I tried. 

Fortunately, Teraterm has a scripting language that has features such as wait ">" that I used to pop up a file open dialog and transmit the file line by line waiting for the prompt. It worked great. 

A terminal program uploaded the file to set the memory contents so that we ended up with the 1130 having the paused diagnostic in memory and the IAR set to the point where it would resume execution. 

DIAGNOSTIC PROGRAM RESULTS - IS EVERYTHING WORKING?

The diagnostic program has two major modes - keyboard echo and 1053 testing. The echo function prints whatever character is typed on the keyboard, allowing a test of both the KB and the typewriter. I used this to work through all the characters on both sides of the typeball. The 1053 testing has a number of subtests, such as tab and CR tests, upper case letter tests, ribbon color shifts and other ways of validating that the typewriter is performing properly.

The diagnostic program proved out all the functions of the 1053, and suggested only a few minor adjustments to make to the typewriter, thus cementing my belief that the 1053 is complete and the 1130 system can be prepared for its move back to its home at the System Source Museum. 


There is a air cylinder to stop the carrier at the left margin which needs a slight tweak. The last three test routines are called, rock, roll and twist and they subject the typeball to extreme rotations or tilts between adjacent characters as a way of spotting any subtle issues. I can see that the feedback circuit timing in the typewriter needs a bit of adjustment.

The 1053 has seven microswitches, three of which are activated by cams and the others by levers. They pace the controller from firing solenoids to trigger the next function. There are points in each cycle or function where they should block the controller logic because the mechanism is in the midst of some movement which is incompatible with printing or other functions until it complete. It won't take long to set these all to their optimum points. The result is already extremely good.

The line of heavy asterisks is a function that types a + in one color, backspaces to type a 0 around it, then spaces over three spots. It does this across the line, the returns the carrier and does the same offset by one column. A third time results in the line being filled in. Any mispositioning of spacing, backspacing or print escapement will be very obvious to the eye. It was pleasingly accurate. 

METHOD TO TEST ELECTRONICS WITHOUT TYPEWRITER - AN ASIDE

I had designed and built a 1053 Emulator box which will plug into the SMS card sockets in the 1130 and respond just as the physical 1053 would. It provides for all the features and functions of the typewriter, tracking the current column that the carrier would have reached. The current column is displayed on three 7-segment displays. It offers the same three buttons on the front (Carrier Return, Space and Tab) plus Tab Set and Tab Clear. 

Each of the character selection codes that have solenoids fired by the 1130's controller logic, T1, T2, R1, R2, R2A, R5 and AUX, are detected and trigger the activation of feedback microswitch circuits to indicate the progress of the mechanical movement. As well, we determine which character on the typeball was selected and print that over the serial connection to the terminal program on a PC. These match exactly the glyphs on the typeball including the two characters that must be represented in Unicode as they are not in ASCII (¬ and ¢). 

The solenoids for motion are implemented by appropriate numbers of spaces, backspaces and CR/LF on the terminal. Thus, when activating TAB we look up the next location where the tab stop was set by the Tab Set button, then space until the cursor is at that column. Spacing simply emits a single space character. CR/LF and LF solenoids inject the ASCII control codes for these actions. Backspacing involves its own control codes to move the cursor back to the prior column. As well, it uses the ASCII color sequences with the terminal to show the characters in either black or red depending on how the ribbon color solenoids were activated. 

Tuesday, March 12, 2024

Loaded fresh bicolor ribbon in the Selectric cartridge

RIBBON CARTRIDGES FOR THE 1053

1053 uses Selectric 1 fabric ribbon cartridges, which is an alternative to the carbon coated mylar ribbons commonly used on the typewriter series. Because it has a dual color feature, the ribbon is a 9/16" fabric strip that has black ink on the bottom half and red ink impregnated into the top half. By changing the portion of the ribbon that is lifted in front of the typeball, the 1053 can print characters in either color. 

These bicolor fabric ribbons were never very popular but with the passing of time they have become even rarer. New old stock can be purchased but often the ink is partially dried out in those cartridges when you take them out of the packaging. 

FRESH RIBBON AVAILABLE FOR OTHER PURPOSES

Fortunately for us, 9/16" fabric ribbon is still used with quite a few other typewriters or printing devices so there are plenty of brand new ribbons on the market. Dual color ribbons are also still being manufactured, thus we could buy a brand new dual color ribbon but it won't come in the Selectric ribbon cartridge. It is wound on reels used on the other equipment but not compatible with our 1053. 

OPENED CARTRIDGE, SWAPPED RIBBON AND WOUND IT UP

The cartridge is easy to open the dried up old ribbon can be removed. That allowed me to wind the newly purchased ribbon on the parts from the Selectric cartridge and put it back together. Voila, a fresh bicolor ribbon to put on the typewriter. 

GREAT FRESH TYPING AS A RESULT

Here is an example of a program typing in both black and red on the restored 1053. The print quality is quite good.