Still battling persnickety selectric typewriter mechanim. Wired up the board to emulate the Prog Load button for virtual 2501 reader

1053 CONSOLE PRINTER RESTORATION

My adjustment for the carrier return latching issue has corrected the problem. I now sails across to the left margin whenever activated. Making progress. The unlatching when it reaches the left side is better but still will occasionally fail to fully unlatch. In those cases the movement seems mushy also.

I remain very happy with the character selection and shift operation of the console printer. I get every letter, typed cleanly, in both hemispheres. The remaining problems are generally independent of each other, allowing me to attack and fix each one in whatever order suits me.

I have adjustments for the carrier return unlatch, after I do a basic test with a spring scale to verify that the leftward pressure is appropriate. It should be around 2 pounds of pull to the left. I can adjust the governor that establishes the amount of pull.

I still have a few issues which I am working my way through, in addition to the carrier return failure to reliably unlatch at the left margin. Sometimes the index operation sticks on and feeds down many lines before it releases. Tab is still not adjusted to activate under program control. Lastly, I still see some poor spacing especially all the way at the left margin.

The poor spacing is likely the dastardly solidified lubricants which are so hard to completely flush from the unit without a total disassembly and bath in solvents. With continued use, this will improve, but initially I can just set the left margin over more to the right, to avoid the region where this occurs.

It may also be that my space escapement lever isn't moving far enough, so that at the end the tooth is just barely touching the rack. I will try to make some adjustments later to see whether this helps, but not today.

The runaway index is a failure of the interposer restorer to latch it back up - a matter of inspection and adjustment. It may also involve a missing spring out of the untold hundreds of tiny springs that are sprinkled across this mechanism.

Relatching for the indexing interposer was being blocked by a loose, excess spring down in the mechanism. After I moved it out of the way, but alas did not extract it completely, the index seemed to fire once and reset quite reliably.

The tab issue remains open to investigation. Definitely something wrong in the whole interposer/trigger mechanism, but not sure what it is right now. Unfortunately, none of the service manuals or the diagrams in the parts list are a complete view of the mechanism and how it should be operating. I spent some time in the late afternoon studying everything I could on this section of a selectric.

When the other pull links are operated, they pull down on the interposer enough for the latch at the front to slip off, the spring then pulls the interposer back and it operates a cycle. No amount of tugging on the tab pull link will cause it to move down enough to slip the latch free, so it never moves backwards. Still no resolution.

I triggered both space and backspace operations, but the carrier was just dancing left and right a slight bit for both of them. Upon inspection I found that the tiny spring that holds the backspace operational lever towards the front had popped off. With both mechanisms tripping at the same time, the carrier didn't know which way to move. If I hold the backspace lever where it should go, a space operation works fine. I have the spring but attaching it is a PITA (pain in . . .), so perhaps later tonight.

The more I pull on the tab interposer, the more it seems that it is hung up on something, as it won't slide backwards as it should with a slight release, instead requiring a substantial push from the front panel button mechanism. Once it slides back, the tab function works just fine.

Some possibilities for the problem with the tab interposer:

• loose spring inside somewhere jamming the movement
• burr on interposer stopping it from sliding free
• maladjustment of interposer (from among several adjustments)
• misplacement of tab interlock swingarm

Once I can figure out and fix the tab issue, replace the spring on the backspace latch, and get the return torque adjusted better, and repair the ribbon color nylon cable, I expect to have a pretty decent console printer.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent some free time in the morning putting in all the wires on the emulation engine board so that I am only waiting for the ICs, resistors and capacitors in order to finish it up. I used a prototyping board which means I have to put discrete wires for each connection between pin pairs Over lunch I tested to be sure there are no shorts among adjacent lines and that every connection was proper and sound.

I am feeling a bit nervous about the clock speed of the emulation engine - designed to be 0.1 seconds - as the various switched circuits attached to 1130 buttons might need a bit more time. More importantly, I want to be sure that the PC program will see the machine complete its reset, then store all eighty words of the boot card image into core before the emulation engine presses the Prog Start button.

I decided to slow down the clock to 0.2 or 0.25 seconds. The entire emulated Prog Load sequence will still only take 2 or 2.5 seconds, which is fast enough to see immediate when the user pushes on the Prog Load button on the PC side program. I just needed to parallel the timing capacitor with another, to increase the total capacitance, thus increasing the RC constant of the circuit and slowing the timer pops. I will get a suitable capacitor later and test now at 0.1 seconds.

When the components arrived this afternoon, I wired in the resistors and capacitors, then did a final test for shorts and incorrect connections. I put together a quick testbench, hung the scope on the lines and listened to the relays as I triggered a cycle.

Initially it did not work satisfactorily, with the flaw being in its initialization and reset circuit. When it was running it counted up and fired the relays exactly as desired, but without resetting to the initial state after a cycle, it wasn't usable. I put it aside to mull over tonight and make adjustments to the logic tomorrow.

While running the 1130 to test and adjust the 1053 console printer, I was using the SAC Interface Box to reload the diagnostic program whenever it seemed to be wedged up. At one point, when I tried to power it back up for another round of diagnostic test loading, the box didn't fire up the fans or power supply. I have good power to the outlet and the cord looks fine, so I had a new issue to have to debug.

The connector for the AC input to the power supply itself, inside my box, seemed properly seated but a bit of wiggling brought the box back to life. With this resolved, I can go back to my testing tomorrow.

In the meantime, I expanded my UCW (unit control word), which keeps status for each of the twenty possible peripherals that can be hooked to the box, to include interrupt levels 0 and 1. The logic for setting, resetting and reporting the two new levels was added as well, so that once I have this enhancement wired into the 1131, I can start supporting virtual (PC based) and real (hardware hooked to the box) devices such as the 1442 and 1132 that require these interrupt levels. 

Console Printer (1053) adjustment/testing and enhancement of the SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

I hooked up the scope to the busy lines on the adapter - the line from the typewriter mechanism into the adapter and then the official busy line that is produced by the adapter logic. I used it in conjunction with my testing to figure out when problems arise.

Mechanically, I made adjustments to the five pull links that the operational magnets yank when the solenoids are activated. These fire the Tab, Return, Index, Space and Backspace cycles respectively. Four of the five were too loose, so that the pull link didn't trip the interposer to fire off a cycle. The Tab link, on the other hand, isn't firing the interposer regardless of the adjustment.

I adjusted the four links so that they would trip when I pushed down on the operational magnet armature, which I believe will make them work well although for completeness I checked this under diagnostic control. What I found is very encouraging. Spacing, backspaces, indexing and carrier returns are triggered reliably by program command.

I have a few problems with carrier return which are purely in the mechanical side of the typewriter, and for some reason tab won't trigger when I yank on the pull link. I imagine this is also purely a mechanical issue inside the typewriter.

When I ran the diagnostic, it was typing away, triggering returns, and in the test for alignment it would forward space to type black 0 characters then backspace and type a red + inside. These looked quite nice most times it tried this test. The characters on both upper and lower case side of the typeball typed cleanly.

Here is what is unresolved as of dinnertime:

• Carrier return doesn't latch as it should, stops after an inch of travel
• Carrier return is not pushing the left margin stop hard enough to unlatch
• Tab does not activate by pull link at all
• My broken nylon ribbon is stopping the machine from activating the red/black ink halves of the ribbon under program control

The lack of activation of the tab interposer means that some adjustment is way off so that it won't unlatch on a pull downwards. The only reason it activates by the button on the front panel is because that forces the interposer back. If I can figure out what is wrong with the triggering mechanism on the interposer, it should fix all these problems.

The carrier return is a more pernicious problem - the toughest part of the machine to rehabilitate. Within this, there are two subparts - not moving far enough to latch and not unlatching on the far side. Frankly, I have to check that the high speed gearing is engaging, as the failure to unlatch at the end could be a result of slow or anemic movement. There is also a clutch spring on the operational shaft that can affect the carrier speed. 

The nylon ribbon for selecting the color of the ribbon is a simple attachment and adjustment, if I can repair the end or find a new part.

After a bit of studying, concentrating on the carrier return problem where it doesn't latch, I knew what was wrong. There is an adjustment where the latch edge should overthrow the slot in the keeper but it isn't even clearing the edge most times. I loosened the nut and moved the bolt head down to achieve the overthrow I wanted.

I did accidentally loosen a nearby nut first, and in spite of tightening it back down, I have to adjust that one to get the mechanism back to working properly. The adjustment is twisting the escapement, as it has to during a return operation to pull the escapement teeth out of the rack, but if it doesn't release fully it will stop the spacing and tab. That is the current symptom.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I put in some time changing the logic in the fpga to add a transaction type to be sent from the PC that requests activation of my emulated Prog Load button - a sequence of Imm Stop, Reset and then Prog Start key presses. In between the Reset and the Prog Start, the PC program will have to write the 80 words into low storage which will get executed when the Prog Start key finally activates.

I also built in the new signals for Interrupt Level 0 and 1, but have not yet changed my UCW design or other logic to fully implement these new signals. Basically, I need two bits to control these two levels, plus the logic that sets and resets the bits as IO device adapters work, and the logic that first the interrupt requests when the UCW bits are set.

I began assembling the logic card for the Prog Load engine that will sit in the 1131 under the keyboard. The parts won't all be here for a few days but I could put in IC sockets and do some wiring. I found a convenient set of signals from the fpga to handle the four signals for the handling of interrupt levels 0 and 1, but I haven't yet selected a pin for the trigger to my Prog Load engine.

The sequence to activate this, from the PC program side, is:

1. verify that there is a binary mode card deck loaded into the virtual 2501 reader
2. issue a transaction with code 14 and special value 127 which triggers the emulation engine in the machine.
3. verify that the USB link returns the same command code 14 and word value 127.
4. issue status fetches for the word that has the Reset line as one of its bits
5. wait for the Reset line to go active, meaning that the emulation engine pushed Imm Stop and now Reset buttons
6. wait for the Reset line to go inactive, meaning that the processor is waiting at IAR of 0x0000
7. request cycle steal writes for the first card image, in boot format, into locations 0000 to 004F
8. at this point, do nothing. The emulation engine will push Prog Start to begin executing at 0000

There are several independent mechanisms that have to work in the proper sequence, but I don't have much ability to synchronize them. After I fire off the emulation engine for the Program Load, by sending the command type 14 from PC to the fpga, that engine has no interaction with the fpga.

The emulation engine steps through a ten stage state machine with its own on-board clock operating at about 10 Hertz or a click every 0.1 second. The machine presses the Imm Stop key for .1 second, pauses for .1 second, then pushes the Reset  button for .1 second. then waits a half second before pushing the Prog Start button for .1 second and finishing.

During the half second, the PC has to see the Reset signal drop, meaning the action of that button has finished, then the PC will request 80 write cycles to load memory with the boot instructions. It can't start too early or the 1130 will still be in reset and not able to handle the cycle steal write cycles. If the 80 characters aren't stored by the time that the Prog Start key is pushed to begin execution, the boot instructions might not yet be in core. 

Working through the 1053 Console Printer (IO Selectric) diagnostics and making adustments

1053 CONSOLE PRINTER RESTORATION

I worked on the adjustments for the shift mechanism and it now seems to reliably move between upper case and lower case positions when I manually push on the appropriate solenoid. I attempted a power on test, but there is still the unresolved issue of a level 4 interrupt that is unexpected or not cleared. I will need to shoot that first.

Another humid day, although a bit less hot with highs only forecast to reach the upper 70s (F). It is sticky in a way that we normally don't experience out here.

If I hadn't run into a diagnostic that was checking for extraneous device interrupts, I wouldn't have found this error in my fpga logic until sometime later. My change fixed this problem, so that I can move back to the debugging of the console printer.

It is now shifting properly but I suspect it is still getting lost in a busy state. I am bashing my way through the diagnostic, in equal parts understanding what it is saying, how it works and what problems it is flagging. 

Another issue solved - I adjusted the ribbon color mechanism so that it shifts between black and red ink portions of the ribbon under program control. The remaining issues to work on:

• Return button on front of printer panel starts CR but it is not latching properly into return mode (this will be fixed with an adjustment)
• Getting lost in some state, but not sure what causes it until I understand the diagnostic better
• XIO request for CR not activating a cycle
• XIO request for Tab not activating a cycle
• XIO request for backspace not activating a cycle
• XIO request for line feed (index) not activating a cycle

Part of the diagnostic operation echoes from the keyboard to the console printer. I tried quite a few keys and it is getting the correct character, but I need to do a more exhaustive test to validate everything. The space bar, a separate microswitch, is erratic in its operation and needs contact cleaning. 

I put the diagnostic into a mode where I can type individual characters or movement commands by setting their value in the bit switches. I used that to validate all the XIO results. However, I can't quite get the diagnostic into that mode.

I did get some sporadic junk jammed onto the incoming data line, which I suspect is from one of my peripherals, so I uncabled the 1442 reader/punch and the 1132 printer for now. I can concentrate on debugging the keyboard, console printer and my peripherals hooked through the SAC Interface Box. 

I found a few more adjustments that improved operation. I think the situation where the machine gets lost with CR and tab operation is going to be gone, but I still have to get all the operational magnets to trip their operational clutches when the solenoid is engaged. The other issue I know I still have is the failure of a CR to latch up.

Normally, when the CR solenoid or Return button trips the operational clutch, it takes one cycle of the operational shaft to start the carrier into its return motion, but since that motion lasts longer than a rotation of the operational shaft, it has to latch the mechanism. The carrier slams into the left side at the end of a return, which unlatches the mechanism. My problem is that the mechanism isn't latching up so that when you trigger a return, it moves just about an inch until the operational cycle is over and then it stops. 

While I was adjusting the heavy printer, which involves tipping it on its back and upright again several times, I managed to clumsily snag and rip off the nylon tape that shifts the ribbon between black and red halves. This is frustrating, as I have done this once before, and it was JUST ADJUSTED TO WORK WELL this morning. I will figure out how to attach a new hook to the end of the tape, put it back on, and adjust again, but I won't do this until everything else is working cleanly. 

I found that the stickiness in the carrier return mechanism latching up is easing up as I work it more and more. It must be residual hardened grease in the mechanism which will only go away with time and exercise. It is still not latching perfectly every time but much better already.

Even when I push down on the armatures of the various operational solenoids, the link is not tripping the cycle for any of those functions - tab, return, index, space and backspace - thus I have it narrowed down to inside the 1053 mechanism, not an adapter electronics issue. 

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I had to look over the fpga logic to see if I am somehow interfering with the operation of the interrupt level which is shared between the console printer and my virtual 2501 logic here. I did find that the logic to load the interrupting device in an ILSW was flawed - it always would dump that bit pattern if the device issued an XIO Sense ILSW, even if it wasn't actually triggering the interrupt level.

What is special about an XIO Sense ILSW, compared to every other function of an XIO, is that the device number (area code) is ignored. The instruction is issued in an interrupt handler in order to figure out which device(s) have triggered the interrupt and branch into their device specific interrupt handler. As a result, whenever an XIO Sense ILSW is triggered, all of my FSMs were triggered even though the program was working with area code 1, the console printer/keyboard.

I have one FSM for each device which is triggered by any XIO Sense ILSW regardless of device and returns the bit pattern for that device. For interrupt levels with multiple devices implemented in my fpga logic, there will be more than one of these FSMs operating at the same time.

The bit pattern is 0 for all devices that did not trigger an interrupt, but since all the the device patterns are tied together in an OR, that works fine. Only the device, if any, that is requesting an interrupt on the level will have a 1 bit high in its assigned position in the ILSW.

I began thinking about the enclosure and physical construction details of the circuitry that will sit under or near the keyboard and remotely actuate the buttons needed to emulate a Program Load.

Designing enhancement for SAC Interface Box and working on misadjustment of console printer shift mechanism

1053 CONSOLE PRINTER RESTORATION

My suspicions are focused on the known problem where the typewriter won't perform shift cycles - it should switch hemispheres on the typeball and those cycles will fire off a cycle and response, although won't pass along an interrupt to the processor. If the cycle is not occurring, it might cause something to time out in the adapter and thus present an interrupt when none should happen.

My first investigation will be into the shift mechanism, getting it working properly before I go on to debug some of the other symptoms. Now that the lack of interrupts is resolved, I have to check and fix:

• no shift
• CR by program command doesn't work
• red/black ribbon shift not adjusted right
• Tab by program command doesn't work
• Backspace by program command doesn't work

In addition I have to test the index (line feed) function to see if that works under program command. Due to the 90+ degree temperatures today, I chose to keep the machine powered down until it had cooled by early evening. Instead, I removed the cover from the console printer in order to begin working on the failure to shift, the red/black ribbon adjustment and other possible adjustment issues. 

Working on the machine with the covers off, I can tell that the shift mechanism is not working properly. I am digging into it as much as I can stand, due to the heat, while my portable air conditioner tries to make the workshop habitable. It took several hours and didn't get the temps down low enough to power up the 1130 until the late evening, past when I was interested in working. Des

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I have specific locations on the backplane where I will tie in my four signals to allow the box to manage interrupt levels 0 and 1. These are one the two swing out gates under the console printer and display panel, that swing open to the rear. The gate at the rear is A and behind it will swing out gate B. One each gate, there are three card compartments, each with a backplane. These are A1, B1 and C1 from left to right when looking at the SLT cards, or reversed when looking at the backplane side.

On the inner gate B, on the backplane for compartment A1 and in row 7, we have card G7 pin B02 which emits +Int Lvl 0 and pin D20 which emits +Int Lvl 1. These two signals can be redriven out to my box in order to see the state of these two interrupt levels.

Also in that compartment is card J7, whose pin B13 is an input -Int Lvl 0 Req which I can wire-or to a gate that will pull it down to ground request a level 0 interrupt. The final signal is on the other gate, A, in card compartment C1, where the card at H7 has an input pin D05 for -Int Lvl 1 Req which can be similarly wire-or pulled to ground to request an interrupt on level 1.

I need two open collector gates to pull the interrupt requests down to ground, and two buffer gates to redrive the interrupt status signals, using four twisted pairs in a cable to run out from the 1130 to the box. At the same time, I will run the line for my "program load" function on a fifth twisted pair.

A small board I will build will be triggered by the program load signal I will send, which fires three relays with suitable timing so that it activates the Immediate Stop switch, then the Reset switch, and finally pushes the Program Start button, with the timing permitting my box to use cycle stealing to load in eight words of boot program right in between Reset and Prog Start. I have ordered the relays for the task but still have to design and build the sequencer logic.

I whipped up a conceptual design with a 555 timer popping each 1/2 second when not held in reset, driving a binary counter chip which I would feed trough a decoder to get 10 single distinct output lines as it counted. The first two would fire the Imm Stop and the Reset relays, then it would count up to 9 and fire the Prog Start relay. When 10 fired, it would reset a S/R flipflop which held the counter and timer chips in reset until the next trigger pulse set the flipflop to do it all again.

The SAC interface from the 1130 included the Reset state signal, so that I could synchronize this all from my box. I would fire the trigger to set the S/R flipflop, wait until I saw reset activate and then deactivate, use cycle steal to write locations 0000 to 004F with the 80 column boot card image and then later the counter would get up to 9 and trigger the Prog Start button to make it execute.

I ordered the discrete chips and other parts I needed so that I could wire this together and begin testing. At the same time, I ordered some parts to implement a small card that fit inside the 1130 to receive and drive my four additional interrupt level signals out from the 1131 to the SAC Interface Box. I should be able to build these circuits by mid to late this coming week, once the parts arrive, and then I can cable this into the new improved SAC Interface Box. 

Planning an enhancement for SAC Interface Box, plus debugging the Console Printer operation

1053 CONSOLE PRINTER RESTORATION

I dove into some diagnosis - since the printer staying busy is a symptom that affects other diagnostics as well, I decided I should dive into this one first. I hooked up the scope to the signal lines coming from the console printer in order to check for a flaw inside the selectric mechanism.

It appears to be working properly - the scope shows the response switch dropping as it should during the cycle on the typewriter, and the interlock for tab and carrier return (long operations) seems to be working too. However, the status as far as the diagnostic code is that the printer is busy (DSW bit 4 is on).

In addition to the adapter making this active during the course of a mechanical typing operation, it can be on if the end of line switch is set. That is an important clue, since my machine had a local mod by the previous owner that activated a buzzer when end of line is on. I moved the scope line over to see what level is emitted on the wire.

When the End of Line signal was verified, I did some bare metal testing on the machine. The results were mixed. When I commanded it to write any signal character, it seemed to always get the tilt and rotate correct to make it happen properly. Space commands also produced an appropriate motion of the carrier. That is about the limit of what worked correctly.

I could see that the two commands, Shift to Red and Shift to Black, were doing something as the tape tension changed on the nylon tape that should be pulling on a pivot inside the carrier. However, the outcome was always the same, red ink for the character. This is probably just an adjustment issue for the tape tension.

Regardless of whether I requested an upper case or lower case carrier, that is carriers from one or the other hemisphere, the ball stayed where it was. There is a problem with the shift operation that should be commanded by the adapter logic. I will need to chase it down to find out whether the adapter is triggering a cycle but the mechanism won't more, or whether the issue is in the adapter.

When I push the front panel buttons that mechanically trip the selectric mechanisms, I got space, tab and carrier return. However, when I entered the control character that should cause those to happen, only space worked. Backspace, Tab and CR all failed to start any movement. Again, the location of the fault, either in the adapter logic or in my typewriter mechanism, will be determined by checking for a solenoid pulse when the movement is commanded.

Most troubling is that the level 4 interrupt that should occur is not triggered. I issue an XIO Write, it types a character but no interrupt. Unless the Interrupt Delay switch is on under the covers somehow, this situation shouldn't happen. There seemed to be the appropriate Print Response condition in the DSW when I checked it, but I could do a more exhaustive sequence of tests to see what repeated Write commands without a reset cause.

The good news - at least from a time to repair standpoint, is that the Interrupt Delay switch was indeed set. When I was snaking the cable from the console printer back down inside the machine, where it runs near the bank of CE switches, it must have snagged that one and turned it on. With the switch fixed, typing a character does cause a level 4 interrupt just as it should.

Now, when I run the keyboard/typewriter diagnostic, it waits with a different error - 30F9 - which means that an interrupt level is high when it should be reset. That is, I trigger the first typewriter action and the machine is not resetting the interrupt level as it should.

My suspicion is that I have a defect in my SAC Interface Box fpga logic, since my virtual 2501 card reader is also using IL4. My guess is that somehow my logic is getting confused when it sees the machine enter IL4, so that the machine continues to request that interrupt level after the typewriter adapter has dropped its request.

This could be a indirect symptom of a timing issue within the typewriter, such that the adapter isn't in a good state and it is the cause of the IL4 demand. I will sort this out by scoping the IL4 request line on my box, as well as by looking through my logic to see if another device using IL4 might cause this behavior in my state machines.

If it weren't in the mid 90s (F) out here, I would be doing more testing but it isn't fair to the machine to run it in the high temperatures. I did go through the adapter logic to try to find situations that might cause some of those symptoms - it could be misadjusted feedback from contact switches in the typewriter, or could be bad logic due to a failed component.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I looked for the 1134/1055 diagnostic module so that I could test out my paper tape reader and punch implemented through my SAC Interface Box, but as the installation from which I received the machine did not have these installed, they didn't punch and save the diagnostics either. Same for the 1627 plotter module and the 2501 card reader diagnostics, both of which would be quite helpful in testing out my work.

I would like to be able to punch out cards, either physically on the 1442 reader/punch or virtually to the PC, but the only punch devices supported by the 1130 system are 1442 models. These use interrupt level 0, which the SAC interface doesn't support. I did some research to see how I could add in the support for those levels, plus the three machine pushbuttons Imm Stop, Reset, and Prog Start.

I found where I can monitor the signals for interrupt level 0 and 1 active, thus I only need to add some driver circuit to get the signals over to my SAC Interface Box. Similarly, I found two spots where I could 'wire-or' a signal to request interrupt level 0 or 1, simply by pulling the line down to ground. If I add a suitable receiver circuit from the SAC Interface Box I can inject the interrupt level requests.

As far as the three pushbuttons are concerned, a bank of relays will allow me to control these remotely. The Immediate stop is a simple N/O switch, and the Reset button is a simple N/C switch, but the Program Start switches the +12V between the N/C and N/O outputs to a circuit that needs to see the pair of signals swap between opposite levels. If I drive this with a relay I can activate it with a single line and do so from multiple places.

I will install the relay bank inside the 1131, under the keyboard, and wire the three activation lines out to my SAC Interface box, along with the four interrupt level based signals I found above. I do have to tie up fpga pins to add the functionality, but I can use just five.

The reason I only need five is that my only use for the Imm Stop, Reset and Prog Start buttons is to implement the equivalent of the Prog Load button - where my box will push those three in a fixed sequence. I will have a sequencer that pushes Imm Stop, Reset, then pauses long enough for my PC side program to push down the 80 columns of boot card image, before the sequencer pushes the final Prog Start button.

Provided Program Load (boot) mode for the virtual 2501 card reader

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I updated the virtual 2501 card reader function to properly handle a binary deck that has a card in Program Load format at the front, such that pushing the Program Load button on my program will load core from location 0000 to 004F (eighty columns) exactly it would on a physical reader.

Each word in memory is 16 bits wide, but a card column only has twelve rows of data. The normal card reader places those rows (12, 11, 0, 1 . . . 9) left justified in a word with four zeroes on the right. That would be pretty useless for instructions coded on a boot card.

The Program Load mode loads rows 12, 11, 0, 1 and 2 into the left five bits of a word, sets the next three bits to zero, then has the value of row 3 stored in both bit 8 and bit 9 of the word. The remaining rows 4 to 9 are stored in bits 10 to 15 of the word. The bits that are set to zero are used for long mode instructions and for selecting index registers, but aren't needed for simple short instructions, thus one can use the short instructions to modify any later instruction words that need the bits.

The only action I can't cause is the execution of the code beginning at address zero, because the SAC Interface does not have that signal available. I do have the ability to separately operate the Program Start button on the machine, so that IF it was reset, the IAR would be at 0000 and pushing start through the added wiring would begin execution.

It is possible to wire up the Immediate Stop and Reset buttons too, so that I can fully automate the Program Load capability, at the cost of an additional cable to the SAC Interface Box and two more I/O pins on the fpga. The two pins will select which of the three buttons to activate (or none for the default state).

Running diagnostic card decks on the 1130 - CPU completely validated, some issues with console typewriter

1053 CONSOLE PRINTER RESTORATION

I installed my replacement USB parallel port onto the card reader interface and read in the binary deck would be booted to run the typewriter diagnostics. I did a test on the 1130 simulator first, which looked promising, so I will try to use it with my SAC Interface Box to run tests on the real 1130. . 

The simulator allows me to dump out the contents of the simulated core memory, which I can then load into the physical 1130 using my interface box. I did so and fired up the diagnostic program. I am not getting the results I should on the typewriter, but the program is indeed working. I suspect that one or more of the feedback switches is not working properly, but extensive testing is going to be needed.


SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I was not seeing the slave select line go high, which tells me I have a missing pullup. I will configure the pullup on the Arduino side, as that is a trifle easier, and see if I can get the select line to delineate individual frames as intended.

After dinner, I fired up the new version of the Arduino, but don't see the slave select line moving from ground. This might be an issue inside the VHDL modules I used for the SPI master and slave.

I created a memory load of the 1132 printer diagnostics, in the same way I created the keyboard/typewriter file, so that I I can exercise that device, and tried to create a memory load of the CPU diagnostic tests. I processed the card decks that are normally booted on the 1130 through its 1442 card reader, but read them into the simulator on my PC instead. Booting them on the simulator and dumping the memory contents at a known wait point makes them loadable through my interface box.

I then tried the CPU diagnostics on the live machine. Unfortunately, the CPU diagnostic doesn't run under the diagnostic monitor like the others - it uses the basic diagnostic loader instead.At night I built that deck to boot in the 1130 simulator in order to create a usable memory load.

I then fired up the 1132 printer diagnostic test, which stops with the error "console printer does not come out of busy", which was my suspicion about the errors with the typewriter test module. I may be able to bypass the need to type on the console printer, in order to have the diagnostic continue and test out my 1132 line printer.

Finally, I had the CPU function test diagnostic ready and took it out to run on the real 1130. It has several steps, the first couple are ultra fast, checking for all 16 console switches on, then all off. The third step runs for quite a while - several minutes of CPU bound activity with the lights flashing - then stops with the final wait value (x3003) which signals successful completion of all tests.

When I ran the same test on the IBM 1130 simulator on my laptop, all steps completed instantaneously, not many minutes as on the real 1130 system. Because of that, I wasn't expecting the very long time it took to exercise all the instructions in as many variants and conditions as possible.

I do have diagnostics for the 1403 printer, 1134 paper tape reader, 1055 paper tape punch and 1627 plotter, all of which are either handled by my SAC Interface Box as a adapter to real peripherals or as a virtual 1403 printer hosted on my PC.

It would be very helpful if I had the 2501 card reader diagnostic program, but the machine I have did not have that device in its configuration so it didn't come with that test module. Thus, I can't directly test my virtual 2501 reader hosted on the PC, until I can create and punch the diagnostic module I need.

I would love to be able to punch card decks to a virtual punch hosted on the PC, but the only punch devices supported by the 1130 and its software are the 1442 models. These use interrupt and cycle steal levels that are not made available on the SAC interface, so I can't emulate them. 

Testing Paper Tape Reader for 1130, plus other news.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I did locate one of my Arduino Mega boards and began hooking everything up. I had to find the 48V power supply I cannibalized from some Cisco gear and wire it up with a switching transistor that could handle the inductive load of the solenoid with its back-EMF when shut off. Slowly and steadily I identified signals from the tape reader mechanism, set up the clutch pick logic and wired it up to my SAC Interface box.

When I fired it up, I could see the clock and data lines active outbound from my fpga, but I am not sure that the Arduino is receiving the frames. One issue appears to be a startup point for the link, some set of bytes that will be exchanged and both side starting normal operation once they see the agreed pattern from the other side.

I also need to instrument up both sides, so that I know what is happening internally. I have some LEDs and scope points I can use on the master side (SAC Interface Box) and can hook up other LEDs to display the state of the Arduino slave.

While the link seems to be working incorrectly, sporadically the conditions were right to trigger a burst of paper tape read commands. If I can get the link working properly first, the rest should shake out easily.

REPAIRING DOCUMATION READER INTERFACE

I had blown out the USB to parallel port board used with the Documation reader to convert physical card decks into PC based files that could be used with the IBM 1130 simulator as well as my interface unit to the real 1130.

The replacement board was three days late, thanks to poor USPS performance, but it arrived this afternoon. It is almost dark out, so I will do the connection and testing of the card reader tomorrow morning. I need to power up the data center shed, where the reader sits, and could use daylight inside.

PARTS FROM AN 1130 ARRIVE, A GIFT FROM A FRIEND ON THE EAST COAST

A friend is thinning out his collection and thoughtfully sent me two parts from an 1130, the rotary mode switch plate and the start/stop switch for the internal disk drive. My replica of that switch plate uses a switch that doesn't detente at the same angles as the 1130 used, so that my labeled positions and the pointer of the knob are out of sync. This plate will definitely improve the fidelity of my replica machine.

1130 parts I received from a friend

Hooking up Paper Tape reader to slave Arduino and linking it to the SAC Interface Box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

The code in the Arduino didn't look optimal, so I did a rewrite that is much more satisfying. The code takes an interrupt whenever the SPI inteface completes exchanging a byte. It handles the logic of the frame of 10 bytes, sending out the 8 bytes of inbound signals to the fpga while receiving the 8 bytes that were outbound from the master.

The main loop of the Arduino is thus presented with a steadily refreshed set of signals being exchanged and can operate based on reading and updating those values. For example, by looking at the high order bit of the second outgoing byte, the paper tape reader logic will kick off a cycle of moving the tape one space and send back the value read in the first inbound byte.

The state machine for the paper tape read operation steps through the interlocked protocol - an outbound request for read, an inbound response when done, then the outbound request is dropped and finally the inbound response drops to finish a cycle.

I began testing of the link between the Arduino and fpga, as I hooked up my paper tape reader to be ready for live testing when it was time. I had to make a few adjustments to pin assignments to stay clear of the SPI lines that are hooked to the ztex FPGA board, otherwise it was easy to set up, up until the moment I went looking for one of my Arduino Mega2560 boards. I couldn't find where I had stored them.

I did work on the wiring connections from the PT reader, so that I knew which lines represented the 8 channels to be read, the roller switch that indicates a read cycle in progress, and the ready/not ready indicator. I also had to validate the pick line which would fire the solenoid based clutch and request a cycle. This proceeded with my signal tracer and alligator clips.

Once I debug the logic I should have a paper tape reader operational, accessible from 1130 software, appearing to be a 1054 paper tape reader. That device appears the same as the IBM 1134 reader, the only difference being slower reading speed for the 1054.

My link should also support punching on a paper tape punch as if it were an IBM 1055 unit, however until I finish working on my tape punch device and figuring out the interface, I think the logic in the fpga is correct for this, but haven't written the Arduino functionality that will drive the interface to the unit. Right now, it responds to software but appears to be 'not ready' and thus won't accept punch commands.

The tape reader is driven by a solenoid that engages one cycle of the mechanism, pulling the tape forward by one sprocket hole. During the rotation, the pins rise then fall. If there is a hole in the paper tape for a particular channel, that pin rises up through the hole, whereas any channels which are not punched have their pins blocked. A switch informs the Arduino when the cycle is underway; the controller waits for 2 milliseconds and then senses which pins have risen through holes in the tape. It takes about 85 more milliseconds for the cycle to finish up.

The controller logic in the fpga is triggered by an XIO Control instruction from the 1130, which sets the read tape request bit on the medium SPI link (byte 2 bit 7). When the Arduino side sees this request bit set, it engages the solenoid on the reader and latches in the value of the holes we read. The character read is sent back from Arduino to FPGA on byte 1.

The Arduino also samples the state of the Not Ready microswitch from the reader and reflects that status on byte 2 bit 5 going back to the FPGA. Whenever the reader Not Ready signal is active, the FPGA logic has an all blank character in its buffer, but that gets replaced when the drive goes Ready and then completes an XIO Control operation to read a character. Subsequent XIO Control update the character in the FPGA.

Any time the 1130 issues an XIO Read instruction, it picks up the current character held in the fpga logic - that is blank until we complete an XIO Control. As the tape cycle completes, the Arduino signals this by setting the reader response bit (byte 2 bit 7). The FPGA will trigger an IO interrupt to tell the software that a character is available to be read with XIO Read.

The FPGA drops the read request bit once it sees the response bit come back from the Arduino. To wrap up the operation, the Arduino waits for that request to drop and then clears its response signal. Thus, software issues XIO Control, takes an interrupt when the tape movement finishes, issues an XIO Sense Device to see the reader response bit and clear the interrupt, then issues an XIO Read to move the character into the processor. 

Completed medium speed link logic for SAC box, implementing paper tape over the link, and thinking about 1442 reader/punch repair

Finally done with the conference I was attending and back to the workshop. I worked on using the slave Arduino to control the paper tape reader and punch peripherals.

1442 CARD READER/PUNCH RESTORATION

I spoke with a friend who might be able to machine a replacement wheel, but the issue of what type of gripping surface to apply as a 'tire' around the circumference remains unsolved. The metal wheel itself is intact, the issue is with the broken tire.

In addition, began thinking of how I might rebuild the missing portion of the 'tire' with a ceramic or epoxy based layer, topped with appropriate grit. The key will be ensuring the diameter of the finished wheel is as close to the unbroken sister wheel as possible.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

All the logic to allow testing of the medium speed SPI link between a slave microcontroller and the SAC Interface box master FPGA is complete - as an Arduino instantiation. Other slave devices are possible, such as mbed controllers, Raspberry Pi, Edison, etc.

My logic to drive the paper tape reader and punch (virtually these are an IBM 1134 reader and an IBM 1055 punch) was adjusted, removing the timers and logic to directly drive the clutch of the devices. Instead, it now follows an interlocked cycle over the SPI link, where a device gets a request, it eventually posts a response, then the fpga drops the request and finally the Arduino drops the response.

The Arduino is responsible for timing the clutch activation, for suppressing delivery of a data byte on the first request after the reader goes ready, and for maintaining the state of the response and not ready signals.

The fpga will maintain the state of the busy signal, return a DSW when requested by a Sense Device, return the character value when processing an XIO Read command, and will maintain and restore the response state for both devices as far as triggering interrupts.

My initial implementation may miss subtleties, such as the behavior if a request is sent to a device which is not ready, but I will research what should happen with real peripherals and then model it as I go through testing.

Away but making a bit of progress with FPGA design

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

As I am away from home attending the Intel Developers Conference, I had limited access to the project. I did make progress on the medium speed SPI link protocol, which transfers 64 signals each way between the microcontroller based slave device and my master unit.  With the VHDL essentially completed for the FPGA side, but not tested, I put in some time finalizing the Arduino implementation for the slave unit.

Building up the medium SPI link with an Arduino endpoint

It is blazingly hot here at 10AM, which limited the time I would spend in the shed working on the card reader. Even the garage/workshop is uncomfortably hot. It will be ideal for developing new logic, which is what I will be doing. The temperature hit 100F which is more than 20 degrees above what we are accustomed to.

PERTEC D3422 DRIVE RESTORATION

Now that I found a few smudges that are raised above the head surface, I went back to cleaning the head focusing on those spots. Too, I worked to remove more of the smeared goo from inside the slot where the magnet poles are exposed. The microscope image shows the raised spots completely gone, so the only cleanup I could still do is to continue removing dirt from the slot.

Head with the surface dirt removed completely

Slot that could use a bit more cleaning, optionally

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Before it got too hot, I went out to inspect the card reader interface, hoping to figure out why it isn't working with my PCs. I found that the USB interface is jumpered for external power, not USB power. I isolated it and tried it with USB power, which did cause the PC to recognize it immediately.

That means I have to work out how I powered the circuit, since something is not connected that should be. I remember using a bench power supply with the unit, so I have to move that out to the shed and hook it up to the appropriate wires. I feel pretty good about the chance that this will work properly once I have it hooked up.

I brought the power supply to the shed, wired it up and tried to do the card reading, but the USB device was not recognized on the PC. Further, when I touched the USB device I felt something very hot, so I shut the power down immediately. I don't know what went wrong, probably how I wired things up, nor do I know if there is permanent damage to the USB module.

Separately, I modified my slave fpga high speed link to receive several of the 1130 status signals and the value of the B register. I will display the B reg on the seven segment display and used the eight LEDs to display the timing states T0, T2, T4, T6, X0, X2, X4 and X6.

On the USB device for the card reader, I saw that my cable connector was shifted one pin off when installed, which is what shorted the USB board., Unfortunately, even with the connector in its proper place, the usb chip gets extremely hot. I had to order a replacement part before I can read the decks in as PC files. It will arrive by the end of the week.

I began working on an Arudino slave to hang on the medium speed SPI link, with a very simple protocol to exchange 64 input and output signals, enough to allow the slave microcontroller to be all output, all output or any combination. The transaction begins with a byte of 0xAA, has eight bytes of data and a trailing 0x55. During the eight data byte transfers, the flow is bidirectional.

The Arduino side was set up to mirror back what was sent, but real logic would be substituted for the mirroring when an Arduino is set up to handle specific peripheral(s). I began on the master fpga side, building the state machine to exchange the state of the signals when triggered. Three nested FSMs to handle this - one to exchange a frame, one to step through the ten bytes of a frame, and one to exchange a byte over the SPI link. 

Still cleaning Pertec disk head before returning it to service; working on SAC Interface Box

PERTEC D3422 DRIVE RESTORATION

I fired up the microscope and examined the cleaned disk head to see if there are any protrusions, scratches or chips that could disturb the airflow that is essential to the head flying properly above the platter surface on its 125 microinch cushion of air.

Pertec head with crud inside slot but undamaged rim and undamaged head poles

Leading edge of head is undamaged, just a bit of soot, and head slot undamaged at top

The edges of the head and its surface is almost totally clean. I did see a couple of raised spots which I have to continue to clean, as these would be candidates to cause a head crash if they remain. The leading and trailing edges, and the entire rim of the head, are clean from damage.

Raised anomaly at top left of light blur

Raised anomaly at right side near edge

The slot for the erase and read/write head poles don't have any dings or raised sections at the head surface, but are still a bit dirty with residual good compared to my sample of a good head. There are a couple of pictures that lead me to believe this head slot can be cleaned satisfactorily.

Head slot with residual gunk but crisp edges

Slot of an undamaged but similar head for comparison

I included a picture of a metallic slider from a Diablo drive that suffered a crash, with clear scratches on the surface that render the head unusable. By comparison the Pertec head sustained almost zero damage. I saw a couple of anomalies which look like raised crud on the ceramic surface - if these can be fully removed, I will be comfortable returning this head to service.

Now this is a crashed head (from Diablo drive)

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I fired up the interface box to resume testing of the virtual 2501 card reader capability, but found that the pesky, fragile connections for inbound signals to the 1130 are acting up again. I am not happy at all with the quality of the connections and will be thinking about possible modifications to make it more robust.

Meanwhile, I have to find a way to create memory images of various important programs, such as diagnostics, so that I can just load them into core and start up. Otherwise, there is a process of step by step bootstrapping which involves decks of punched cards, a somewhat tedious process.

The normal workflow to run a diagnostic, for instance the keyboard/console test, is to put the relocating loader deck in the card reader hopper, followed by the Diagnostic Monitor II deck, followed by the test(s) in question, followed by a blank card. The Program Load button causes the first card to be booted into memory, after which the program reads in the loader and then the monitor and finally the tests.

Without a physical card reader, I could do this one of two ways. The first is to convert the first card of the relocating loader into its memory contents as if it were entered by a Program Load but the machine was kept in Single Instruction mode so nothing executed. This could be placed in storage by my 'load core from file' function. When this program is told to run by setting the IAR to 0 and pushing Program Start, it will attempt to read further cards from the 2501 card reader.

My virtual card reader would have a PC file containing the rest of the relocating loader, the diagnostic monitor and the keyboard.console test plus a final blank card. I would tell my interface box to load a binary file into the virtual 2501 reader, after which it 'should' read everything in and begin executing the test.

A second way would be to stack up the decks in the IBM simulator program on the PC, boot from the card reader and have the decks read in and begin execution on the simulator. At this point, with the test poised to run, I can dump the memory contents into a file which can be loaded into core by my interface box. I need a machine configuration that matches my intended hardware, in particular it needs a 2501 card reader, plus I need the binary decks for the 2501 relocating loader, the diagnostic monitor II and the keyboard/console test.

I have the decks for the diag monitor II and the keyboard/console test, which I can read in using my Documation card reader to create the PC side files. I am not sure if I have the 2501 relocating loader deck - if not I have to make use of a copy from the IBM simulator or assemble a deck. Finally, I need to boot in the one card of the relocating loader into core, in single step mode, to create the core image for use on my real hardware.

My real 1130 came with a 1442 card reader, not the 2501, thus I don't have a bootable deck of a 2501 relocatable loader. I made an attempt to boot the stack of the 1442 relo loader, the diag monitor II and the keyboard/console test into the IBM simulator, hoping to create a usable core memory load from that.

Somehow my interface between the Documation reader and the PC program is not working - the USB device is not showing up as a serial port. I tried it on two different PCs, but ran out of willingness to debug this further. The reason - it is in the upper nineties right now and the card readers are in the datacenter shed, which does not have air conditioning. Too brutal to stay in there for an extended period. I was willing to nurse a small card deck through, but that was all. This will wait for tomorrow. 

SAC Interface box fast SPI link debugged and working

PERTEC D3422 DRIVE RESTORATION

I opened the disk cartridge to examine the platter surfaces more closely. My original thought was to see if there was any way that it made sense to keep using this cartridge, with suitable cleaning. However, when I looked on the pack, I saw some small divot marks at random points around the surface, where the aluminum substrate would shine through. I don't like the look of those, so this pack is now officially a discard.

Underside of platter, notice divot and black streak

I superficially examined my other two packs - the platters look clean and free of any scratches or other defects. I will clean them carefully with 99% IPA and inspect them more closely before they go live in the disk drive (with the cleaned and reinstalled disk head)

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My initial test of the new error correcting fast SPI link led to it rejecting 100% of all frames - the good news is that it is detecting multi bit errors and tossing them. The cause, however, has to be determined. It isn't likely to be line noise, instead I suspect I am doing something wrong with the detection and correction.

When I looked closer, I could see that the Hamming SEC-DED function that I am using reverses the field bit for bit compared to all the other uses. That is, the bit that represents the data pattern with only the low order digit on, d0 in the rest of my logic, is at the end of the string inside the Hamming package but is at the start of the string in the rest of my logic.

Too, the placement of the additional parity bit that infers the double bit detection capability is after the parity for the cells with an address ending in 1, rather than after the parity for the cells whose address has addresses with the 64 bit position on.

I had to work with the code and definitions to get the strings oriented the same way and to merge the proper parity bits into position. It became harder than I expected, because they didn't intersperse the parity bits in the same way as the usual definition. I will have to look through the logic for the hamming package very, very carefully in order to get everything converted to work properly.

That was way too much trouble, given internal logic that divided up the range of the encoded field without interspersing parity, I had to return to the orientation and sequencing in the Hamming module, then change my frame layout to match.

With those changes made, I tested again and had a solid link reliably carrying the data to and fro, regardless of the bit patterns in the 104 data bit portion. I cobbled up some code to display the checksum on the seven-segment displays, so that I could see it was generating a non-zero and ever changing CRC in the frames. I also froze the random counters when button 0 is pressed.

With that change, I verified that there was a continual change to the CRC checksum and that if I froze the counters, it would still update as I manipulated eight of the data bits (of the 104) using the eight slide switches. This was performing very well. I transfer a frame of 104 bits every 23 microseconds,a frame rate about 45K frames per second. As long as I am dealing with devices that can handle being serviced in the range of 100us, no special engineering is needed.

I did add in all the signals for the connectors on the slave FPGA board, as a convenience, for when I assign and hook up various peripherals to this board. I have 64 connections available on the board. Each additional set of peripheral connections could be handled by adding another slave board. A slave board provides a net of 60 signals, since it takes four signals from the Ztex board to form the additional fast SPI link.

The logic also includes a medium speed SPI link operating at 50KHz, transporting single bytes, thus approaching 5K bytes per second or one byte each 200us. Since any unit hooked to the medium speed link would have multiple bytes to exchange to manage its attached peripherals, it is suitable for objects that need service in the range of milliseconds. There is no error checking or correcting on these links, as their slow speed should not leave them vulnerable to noise or other channel errors. I intend to attach devices such as Arduinos to these medium links.

Pertec head looks salvageable

PERTEC D3422 DRIVE RESTORATION

I spent half an hour doing more cleaning of the crashed disk head and the results are looking quite promising. By comparison, look at the smudge on the non-crashed head from the lower surface of the removable pack. Not a mark on the disk surface and a bit of this tarry streaking which I have removed now.

Good head with a bit of tar smearing

The top head looks clean and undamaged. The only area that needs further cleaning is the narrow gap for the read/write/erase magnetic poles - there is a bit of the tarry goop still in there, but I think I can get it out with more careful cleaning. The head may appear to be a different color than the good one above, but that is a photo artifact; they are the same white color.

Crashed head after more cleaning

Bit of tar still in pole gap, otherwise looking pretty good

I cleaned the disk surface but there is still a noticeable mark, so I am not so upbeat about the chance of saving the cartridge. I do have two other cartridges on hand, one of which I will use once I clean it carefully.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I set up the slave FPGA to produce an ever varying set of signals on the 104 data lines carried on the fast SPI link between it and the master FPGA in the SAC Interface Box. This way, I can be sure that

CRC and Hamming SEC-DED logic is properly validating the link data. 

SAC Interface fast link error checking logic improvement

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I found an Opencore program to generate the VHDL for my hamming SECDED code which will give me the automatic error correction I want, without having to develop my own logic to create the syndrome (indicator of a single bit error and its location), as well apply the syndrome to correct the data.

The only delay came from fighting through the install of g++ on a minGW system I have on a Windows system - since I only use these systems very rarely for specific code or compile requirements, it takes me a while to sort out what is necessary to make it run properly.

In this case, it is the PATH variable which Msys is setting to add /mingw/bin , not c:/mingw/bin, thus confusing Windows and failing to find the compiler and other executables. With that fixed, when I run the g++ compiler, a spurious error asking to ready a specific hard disk (that doesn't exist on this system) which a Google search finds is a packaging error in how the g++ module was set up for installation.

Bypassing the false hard disk error brings me to an error where the module is using a standard library function (strcpy) but the include file is not being accessed. I will look to see what other configuration issue might be behind this new symptom.

Another set of known issues that many have experienced, but the workaround was easy to implement and finally the program was running. I used it to spit out the Hamming encoder/decoder VHDL for 120 bit data and transferred it over to my SAC Interface workstation.

I finished restructuring the data pump logic for the fast SPI link - stepping the data through the Hamming and CRC processes. Once this is ready, I have to make corresponding changes to the VHDL to run in a Nexys2 board, which is the other end of the fast link. Only when both are prepared can I begin testing the fast link.

CHM 1401 issue with group mark resolved, working on improved fast SPI link logic on SAC Interface Box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I continued to set up the logic to produce a 16 bit CRC of the 104 bits of data in a frame, which is then converted to 128 bits using a SECDED Hamming code scheme. I also picked one of the 104 data bits to be a 'parity error on last frame' indicator back to the sender, allowing retransmission of frames to be sure I don't miss transient conditions that occur while frames are being discarded due to link errors.

Right now my hamming receiver logic will detect single or double bit errors in the combined data + CRC frame, but I have not implemented the single bit error correction that this error checking scheme makes possible.

I really have to think through the state machines for sending and receiving frames, as there are multiple places to detect errors (hamming check and CRC check) and various ways the logic should recover, depending on the error.

For example, a single bit error detected and corrected, which then passes the CRC test, should be considered the same as an error free frame. However, if the CRC does not match, the packet needs to be rejected and a flag bit sent back asking the sender to repeat the frame.

I am kicking around various designs of the state machine(s) and thinking about the implications of each choice. If I reject an error frame and ask for it to be resent, that means that some short duration signal changes might have passed entirely between the time the original frame was composed, during the time it is being re-transmitted, but before the next frame of content is sent.

The alternative to this also allows me to just throw away frames in error, rather than seeking a re-transmit. The alternative is to always use an interlocking scheme to request actions, so that a request or response can't be lost due to short term link noise. This is more consistent with the idea for the link, which is a bidirectional data pump which simply copies a set of 104 registered signals from one side to the other, meanwhile the other is sending its own set of 104 registered signals back to the first side. The signals in each direction are independent except for any interlocked transaction protocols I set up.

1401 SYSTEM REPAIR AT CHM

One team member found mention of an RPQ that could be put on a 1401 whose purpose was to treat a groupmark as a 12-5-8 instead of the usual 12-7-8 card code. No documentation or wiring diagrams at the museum show this RPQ installed, but another team member remembered having seen some mystery switches inside the card reader/punch.

We looked today at lunchtime, found the mystery switches with a clear marking that they involved groupmark for read and punch separately. Both had a 'normal' mode and a 'IBM 705' mode, which makes sense since the older 705 mainframe used 12-5-8 for a groupmark instead of 12-7-8. So, we have the RPQ installed but our ALDs and other wiring diagrams don't show it at all.

The RPQ switches inside the reader/punch

The switches were both in their "705" position. We flipped them up to "Normal", hooked up the mystery wire on gate 01B4, and the machine now reads 12-7-8 cards into memory as a groupmark without any validity checks. It also punches a groupmark in memory (BA8421) as a 12-7-8, just as it should.

Back when this problem was first experienced, somebody must have recently reached inside the machine and changed the setting of the switches. The first time the museum demonstrators tried to run the tape program after this mystery change of the switches, the deck having the 12-7-8 in some cards, they got the read validity check and reported it to us. With no mention of the RPQ, all our documentation said that a 12-7-8 was a valid groupmark thus we had an erroneous check condition. Later, others discovered that punching a groupmark produced the wrong hole pattern.

It took weeks of diagnosis because the ALD manuals and other documentation did not reflect the machine as it exists. This RPQ is rare enough that nobody on the team had every experienced it on another 1401; if some one had, we would at least have known to check for the RPQ and perhaps looked inside the covers of the reader/punch for the switches.

The upside is that the team learned quite a bit about some facets of the machine and its design as a result of investigating this situation. The downsides include knowing our schematics are out of sync with the machine and, since there is an unmarked third switch next to the RPQ switches, we may have yet another unknown RPQ on the machine which could bite us down the road. 

Mostly 1401 restoration today

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I did a small bit of logic reorganization and improvement for the high speed SPI link in order to make use of the CRC generation and testing functionality I added. The CRC module makes use of a reset signal  that clears the internal generator to its initial state and an enable input to prepare it to generate CRC.

1401 RESTORATION AT CHM

The CT 1401 system had a number of problems that we looked at. It would record a punch check immediately upon the Start button activation, while no punch instruction was issued and no activity was underway on the 1402 punch side. When punching any contents, the first column would have rows 12, 11, 1, 2, 3, 4, 5, 6, 7, 8 and 9 punched, regardless of the contents of memory location 101 which should instead be punched. Attempting to punch a groupmark character, which is BA8421 in memory and produces hollerith 12, 7 and 8 holes, instead produces the hollerith pattern 12, 5 and 8.

We still have the mystery signal line that had been causing incorrect validity checks when reading the 12-7-8 pattern (groupmark), which comes from 11 unknown cards on gate 01B7. That remains disconnected and its connection or disconnection makes no difference to any of the problems from the first paragraph.

Tracing the punch check at Start, we found a card with a shorted transistor, replaced the transistor and found that the spurious punch check no longer occurs. Testing further, we found that the problem causing column 1 to have almost every row punched is also gone, apparently caused by the same flaw.

The only remaining problem at that point was the improper decoding of BA8421 from memory into the pattern 12-5-8 on the card. The logic for choosing holes to punch on the card is a bit unusual. It involves a decision as each row of the card passes into the punch station. Remember that the card is moving through the machine so that the top edge of the card (row 12) moves through, where all 80 columns would get holes punched if the character in the punch buffer for that column requires a 12 punch. Then, it gets to the 11 row where all columns needing an 11 hole are punched. Continuing through the card, each row gets punched until it finishes with the bottom of the card, row 9.

As each row reaches the punch station, the processor logic places the row number in the A register, starting with BA for row 12 and decrementing each time the punch advances to the next row (B, A, all bits off, 1, 2, 21, 4, 41, 42, 421, 8, and finally 81 to represent the row number.

At the time when each row has been reached, the 1401 logic will read all 80 columns of memory into the B register, one at a time, and decode that character in B to decide what to punch. There is logic that looks at the current row number (register A) and the current character value (register B) to see if it matches a situation that needs a hole punched. All the various conditions (e.g. if row is 12 and the B and A bits are on in memory, fire the punch magnet) are wired together, so that any of the gates firing will put a hole in the card at the column being processed at the current row.

We removed the gate that fires the punch magnet at the time when we are at row 5 from the wire-or and put a scope on the output of the card - it was not firing. That means that the gate punching a hole in row 5 for our groupmark is not the one that is intended to drive a hole at this time. Some other gate is firing at the wrong time, meaning it should be firing at a register A value such as 7 for row 7, but is misfiring while we are at row 5.

We put the card for row 5 back in the net and began to put the extender on the card that drives the hole punch for row 7, to see if it is firing but at the wrong time. However, we got a new error symptom. Our punch buffer had 30 groupmarks in it to punch from column 1 to 30, but now the card had the bad pattern 12-5-8 in columns 1 to 11 and 20 to 30, but was producing no holes in columns 12 to 19. The logic was throwing a punch check, meaning that what was read from the card (blanks) didn't match the number of holes that should be punched for a BA8421 character. The punch check was valid, but the lack of punching was not.

We tried other characters in the locations for columns 11 to 19 but no holes were ever punched regardless of the data pattern. This is very mysterious because the punch magnet drivers are addressed by a column address decoder which outputs 18 signals - a tens position value of 1 to 8 plus a units position value of 0 to 9, which together address each of the 80 driver cards.

Even though the machine is looping through the 80 columns serially during a row, so that the punch magnets are not fired simultaneously but instead in a ripple wave from column 1 to 80, each column has a driver for its own punch magnet. The wire-or conditions for punching a hole at a particular column in this row are combined with the 18 column addressing signals to fire a given punch magnet.

A scope on the logic to select the column 12 driver showed a clean signal for the tens digit value 1, but nothing good on the input for the units digit 2. If anything it should have been the reverse.

If one of the column addressing lines were bad, the failure would either be in the ones or tens place consistently across the card - e.g. fails to punch 2, 12, 22, 32 etc or fails to punch 30 to 39. we were set to test the driving for the tens position value 1 when the problem got worse. The machine began to skip punching holes for all columns from 1 to 16. At this point we had to leave. 

Adding CRC to the fast SPI link capability of the SAC Interface Box

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I made another try to run the DCIP utility on the 1130 today, after loading the file from my PC into memory via the SAC Interface Box, but it still looped. I did notice that the 1442 reader is in a funny state, which might be causing problems with the program.

The reader didn't put on the power lamp until I pushed the NPRO button, then I could hear a hum from the motor spinning. Since I have the belts removed, having taken out the punch mechanism, the reader isn't really in good shape to run. I will remove the cables from the 1131 to the 1442 for the time being.

I decided to bolster the reliability of the high speed link I will use between the main (ztex) fpga and secondary fpga or microcontroller boards to provide more fanout of signal lines. I need the data exchanged to be extremely reliable as a flipped bit might trigger some FSM shift or affect the mechanical motion of a peripheral.

The current logic is a SECDED (single error correcting, double error detecting) hamming code that carries 120 bits of data with 8 bits of parity to allow some self-correcting, but some multiple bit errors can slip through.

I decided to take 16 bits of the 120 bit payload space for a cyclical redundancy check (CRC) which is generated on the remaining 104 bits of payload, after which the data plus CRC is encoded with the hamming coding.

The idea is that the hamming code can correct the infrequent single bit errors, but then the CRC validates that the presumably recovered/validated data pack passes muster. This will let me push the technology in terms of distance and bit rate without having to spend too much on extreme link technology.

I found a great website (www.outputlogic.com) which creates VHDL or Verilog for parallel CRC logic - pretty much any width and polynomial, emitting code that is free to use as long as you retain the copyright notice. I spent the evening finishing up the CRC generation and checking logic inside the SAC Interface box, using the parallel CRC logic I just included.

Removed and began to clean the Pertec head, got SAC Interface fpga board back in operation to resume debugging of logic

PERTEC D3422 DRIVE RESTORATION

I pulled the bad head out of the drive to see what it looked like. It was quite ugly but the material on the head looks suspiciously like it was a bit of gooey insulation that lurked somewhere in the machine and finally made its way out into the gap between head and disk.

Disk head after removal from drive, post-crash

The ceramic 'slider' of the head appears bright and shiny after I have the head substantially cleaned, whereas a hard particle like grit would have cut lines into the surface. However, until I have 100% of the contaminant off the head I can't determine if it is free of scratches or projections.

First pass cleaning material off head 

I applied 99% isopropyl alcohol with low-lint swabs and pads, which removed layers of the surface junk - much like the insulation itself for which IPA is not a good solvent. It took many passes with swabs and pads to get it as far as I have; the mini-flood of IPA on each pass loosens a bit more of the top layer of the crud and allows it to be pushed off.

After quite a few additional passes, getting closer to clean

I am comparing it to the existing heads that were not crashed but will also look with a microscope to check for fine scratches especially anything that sticks up and disturbs airflow. The small slit where the read and erase head poles stick up is the likely spot for such damage, although the two round holes which maintain flying height could also get damage on their rim.

In a very interesting coincidence, about four months ago I saw an auction for a used disk head which appeared in good condition and might have been suitable for repair of the Diablo drive I also own. It was actually a head for a Pertec D3000 series drive, something that meant nothing to me at the time.

I know from the marking that it is a 2400RPM version (higher bit rate/frequency) but don't know if it is compatible in the other key metrics - bits per inch along the circumference of the track and tracks per inch radially from the hub. It won't help in this case, as it is a bottom head while I crashed my top head. Still, I thought I would mention the unexpected connection.

Crashed head on left, Pertec head from eBay on right

I found a Memorex head that is extremely similar looking on ebay, but it is for a 100tpi, 100bpi, 2400 rpm drive so it won't work. The most critical is the tracks per inch, which reflects the width of the recorded signal. The Pertec drive writes and reads tracks that are half as wide, requiring a narrower pole, thus this head would stomp on adjacent tracks anytime it wrote.

My testing setup, scoping successful read - prior to head crash

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I sorted out the problems - it required me to make a new version of the firmware to run on the 8051 processor embedded in the Cypress EZ-USB module on the ztex fpga board - one that implemented my two high speed ports for transfer between PC and FPGA, but also supported automatic load of a bitstream file in the fpga on power-up. Works now, so I am back in business debugging my interface.

First test involved loading the standalone disk cartridge initialization program (DCIP) into memory using the file on the PC of the memory image. My code flashed the lights loading up storage but I found during the verify pass that at least one of the words had a bit dropped.  I will look through my fpga code to ensure adequate setup and hold times for the addressing lines to the 1130, but also scan the Python program to be sure I am not inducing the problem here.

I will also figure out some instrumentation that I can watch on LEDs and scope, from the sixteen signals I can output for diagnostic purposes. Since my protocol returns the values that I received back to the Python program, which checks that the fpga got a request to store a specific value in memory and that the value matches what was sent, the issue is almost certain to lie in the fpga side logic.

I thought I found a race condition in the cycle steal fetch and store logic, which I removed by changing the FSM sequencing, although the odds of it happening were too low to account for this error. With that changed, I brought the PCs and new bitstream outside to do another test.

What suddenly occurred to me is that it never set bit 12 of the memory location - the location was always zero. This threw the spotlight of suspicion on the hardware itself - my driver for the Channel Data Out register bit 12 or a defect in the 1130 side receiving cards or a cabling/connector issue. The scope became my means of diagnosis - triggering on the output from the fpga to my driver chips, recording what happened on the output pin of the driver when I triggered its input.

The test showed me that I had an intermittent connection, which I found and repaired. The next test
showed a different garble pattern, which I began researching. Darned fragile connections on the board with the drivers! Now it was bit 6 that was awol but soon the machine was reliably loading whatever I wanted into memory and verifying the contents by using CS fetch to read it all later.

I expected to be able to run the DCIP utility at this point, getting output on the console typewriter, but it just looped. Not sure if I have the procedure wrong, but that is a separate and less important test. I will go on now to testing my virtual 2501 card reader logic, which is the next most important function for this interface box.

In scanning quickly at the operating instructions for DCIP, I noticed a comment that said that the typewriter is used if the printer is not ready, but I didn't have the 1132 cabled so it probably appeared ready. The program was probably looping trying to write on the printer. I gave it a try tonight, a quick test to see if I was right, but it still looped. I could be looking for a 1403 printer rather than the 1132 - I have no idea what this particular memory image does.