Keypunch interface testing wrapped up, keypunch itself needs work

Our electrical utility, PGE, scheduled today to replace transformers serving my neighborhood, leaving us without power for a majority of the day. Got to work once I could, but progress limited as a result.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I rewrote the parsing of the punch line and am now pleased with the code. The earlier implementation was clunky, easily misunderstood and complex to maintain. Testing resumed once power was on.
Routine worked very well, thus could blast through the tests and finish up the remaining steps.

Interface under final test

The remaining two issues I found may be mechanical issues in the keypunch, they both have to do with the card in the read station registering and staying in column sync with the card moving through the punch station. A few times when I tested the _R read command I found some erratic initial movement, often generating one or two false columns before reading the rest of the card.

Verify mode suffered from the same defects, thus the card in the read station was a couple of columns behind the punch station card (and thus behind the logic of the interface which times everything to the punch station card column.

At this point, I will close up the interface box with its current software, since it is probably working correctly, and turn my attention to rehabilitating the keypunch.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I opened the cable connector, but there were no wires disconnected inside. I tried to clamp the connector on the thick vinyl outer cover of the cable but it was very difficult to accomplish since the internal wiring inside the connector exerts tremendous back pressure when I try to compress all the twisted pairs. When they are in their rest state, the clamp is about one half inch past the end of the vinyl and could instead compress twisted pairs if tightened.

Cable not secured by clamp on connector

I need at least four hands, two to push the cable into the connector, another to twist the connector to make the clamp screws accessible, and the last to operate the screwdriver. I will try to get someone to help tomorrow.

I see a couple of female pins pushed in on the socket, not as many as the peak of problems I saw on prior removals but still not good enough to complete all circuits. Once I fix the clamp on the cable, and push the errant female pins into position more firmly, I will try to reconnect the cable again.

Keypunch interface testing almost done, but SAC Interface connection still dead

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had one anomalous result in testing yesterday that I don't understand, so I instrumented the heck out of the interface program and will use the voluminous state output to show me where things are going wrong. I have the detailed test plan to finish up today.

I found and fixed several minor problems, as well as the one big issue which came down to a boneheaded programming move I made, reusing the same index in both an inner and an outer loop. Can't believe I didn't spot that in all the examining and refining.

The physical keypunch sticks in a clear cycle when I should reset once all cards are out of the card path. I suspect this is an oxidized contact on the cardlever relay, the one relay I didn't pull and clean up with the burnishing tool when I serviced all the others last week.

Really feeling good about condition of this interface. As soon as last step of test plan completed, this gets uploaded to a repository and shared, along with the interface design and wiring information. The python wrapper program to use this to punch decks or read decks from 1130 simulator files will be a good demonstration of flexible ways this can be used.

I decided to rewrite the parsing of the punch line to make the code a bit more straightforward, which pushes the completion of testing off until tomorrow.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I designed the logic to allow the PC to read and write blocks of core memory on the 1130, using the USB link to the SAC Interface box. Now I just need to finish fixing the problem with pins pushed out of the back of the 160 pin socket and get the USB link working again.

Well, I thought I had them all in but the interface remains inert, no sign of incoming signals and no recognition of my output signals. I did notice that the cable connector clamp had come off the cable, so perhaps some internal wires have come loose inside the connector. This is discouraging when I had gotten so far and was finally debugging and expanding the logic inside. 

Finding and fixing minor bugs in keypunch interface, problems crop up with SAC Interface

1053 CONSOLE PRINTER RESTORATION

I kept returning to the printer to search for the lost spring, but as of the end of the day I still haven't located it. As a backup, I crawled around on the floor extensively plus searched deep inside the 1130 just in case the spring took an odd hop outside of the typewriter mechanism.

The typewriter will sometimes fail to reset after a carrier return, attempting two or three before resetting the latch. I suspect that the lost spring is somewhere in the string of parts, levers and clutches that handle the CR, interfering with its proper operation, but even with that suspicion it is extremely hard to find.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I completed the detailed test plan last night and set out to work through it step by step today. I discovered a parsing error which I corrected before resuming the testing early in the afternoon.
Progress was steady as I worked through my plan, identified and corrected problems, then restarted any steps where my changes could have an effect.

As the daylight faded, I closed up the garage, took a breather from live testing on the keypunch in order to correct a few anomalies I discovered and improve one area of the code that I don't like.
I will also put together a quickie Python program that will use the keypunch interface to read a deck of cards into a hollerith format or an ascii file.

I will use that to read in some small decks that I want to transfer to other enthusiasts. Once my stacker, release and autofeed are working more reliably I can attack some larger decks but currently I will be hand feeding and nursing the cards through the keypunch.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Everything was ready for the next round of testing. When I removed the 160 pin connector to check the wiring to my interface boards, I discovered that a couple of female pins had been pushed into the socket openings, thus not making contact with the male pin on the cable. One of them was for B register bit 1, one of the signals that had been missing. I pushed them forward into place but given the high force used to seat the cable onto the socket, I have to hope that these are not pushed out of place again.

I found that even with a fresh day and load, I am unable to successfully read and write to the registers using the USB link. I don't know what is wrong yet. I rebooted my PC in case the drivers on the PC side or in the SDK had fouled up, but I suspect it is a more fundamental wedged state of the USB link. I have to understand the condition and build in a means of clearing it as part of the startup of my PC side program.

When I loaded the new logic configuration to the flash and brought up the 1130 with the SAC box, nothing worked. I didn't see any signals and my interrupt request wasn't detected. I leaned over to look at the back of the 160 pin socket and could immediately see several female pins pushed out of contact. Although every signal on the cable is a twisted pair, IBM didn't connect the ground wire on both sides of every signal. Instead, just one pin is used to link grounds.. If that pin is pushed back like several of the others, it would cause exactly this symptom.

My first task is to get all those pins back into position contacting the male pins of the cable. Given the thicket of wires emerging from the back of the 160 pin socket and limited maneuvering room as the box is assembled, this will take a bit of time. I didn't finish this by the end of the day today.

Steady progress on SAC interface box and new keypunch interface

NEW KEYPUNCH INTERFACE DEVELOPMENT

I had to partially disassemble the keypunch to clear a really bad jam, but once I did I could verify that the interface will correctly punch and read cards. The keypunch itself needs work so that it can register each card in the read station after it is released from the punch area, and to place the cards in the stacker at the end, and to autofeed blank cards from the hopper. That doesn't impact the interface testing and operation.

It is time to do a full and complete test of the code, validating its correct operation with all the features, functions, and conditions that will be encountered. I will spend some time tonight and tomorrow writing up a comprehensive test plan which I will execute.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I worked out the method for using the ISE toolchain Impact program to set up and load the flash on the FMC Carrier S6 board, allowing me to have the interface box come up automatically. I set it up this very cold morning in the bay area (cold for us, just a few degrees above freezing when I awoke).

My Python code is working well to display the incoming signals, looping every five seconds to display the B register, clock levels and status information. This was debugged using my spare Nexys2 board, but targeted for use with the board in the SAC interface.  I tested the ability of my code to open and access the registers of the FMC Carrier S6 board.

I was able to read for a couple of rounds then the python program began receiving address and data timeout errors, suggesting that my logic in the fpga was hung up somehow and not properly responding. Timeout recovery is missing from the fpga side logic, something I need to investigate and correct.

My initial testing showed me that I had improved the assignment of signals to lights but not totally correct. parts of the B register signals are offset or missing, and all the four interrupt level signals are the inverse of their expected state - when entering IL4, the light assigned to that state turns off, otherwise all four IL levels are lit when they should be extinguished. A simple matter to invert the IL signals, the rest takes some investigation and changes to the assignment spreadsheet.

I decided to pull the 1130 cables from my interface box and use a continuity checker to make sure I know what signals are handled by each circuit on each of the four interface boards. As well, I will check that the appropriate pin to the fpga stack is used for the circuits. With that done, I can create a fully accurate assignment spreadsheet, update the fpga logic and then be sure that I am looking at the appropriate LED when testing each signal.

Lack of a signal then indicates either a fault in my interface boards, in the cable, or in the 1131 itself. There should be very few such issues to manually trace, but I have to get the assignments correct before I have eliminated the most likely cause of any LED remaining dark.

I traced all the signals and came up with the definitive assignments of the cable signals to the interface board circuits. The sun had set so I went inside and began updating the spreadsheet and documentation. That took a couple of hours to carefully cross check everything. Once done with that, I turned to the VHDL and updated the logic to get the signals straight inside the fpga. It is now ready for the next round of testing tomorrow. 

Good progress on the SAC interface, clearing up assignments of incoming signals

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent some time in the morning working on two issues: getting the FMC Carrier S6 board flash programmed with the logic configuration, and figuring out how to access a string embedded in a structure using ctypes and Python.

Digilent just opened a forum for users to communicate with them and each other. I posted a query about the problem programming my FMC Carrier S6 board, hoping to hear back in a few days when the return from holiday shutdown.

I switched the system on and once again I had reliable behavior of the signals injected into the 1131. I began mapping the signals that correspond to the incoming state from the 1131, with a fair degree of success right away. The signals are all scrambled compared to what I think I am sensing but I could locate 14 of the 16 B register bits, all four of the T clock signals and the Phase A signal.

Two of the B bits didn't seem to change any of the LEDs, which must mean they are actually different signals into the FPGA than I think because of mismapping of connector, 1131 signal and fpga pin. If the pattern I detect from the 19 known signals is consistent, I can infer the remaining signals, correct all the assignments and test again.

I did find a pattern, although it has a few oddities. I will rearrange all the incoming signals to what makes sense based on the pattern, then do some testing. Updating the documentation is the really tedious task but has to be done if I am to have any chance of maintaining this interface in the future.

Changing all the documentation then updating the VHDL took all day, but it was finally done before I went to bed. Tomorrow I can validate the correctness of all the signals using the 1130. The basic method for validation is to:

• use Load mode to test the B register bits
• single step through the machine states and instructions to verify the T clocks and phase A
• execute an XIO instruction to validate XIOE1
• check interrupt level correspondence
• cause a parity error to validate parity stop
• verify clock out and meter out signals

Testing the cycle steal related incoming signals is more complex because the eight X clock steps can't be single stepped, they occur within a few hundred microseconds. I will change the use of a slide switch from triggering an interrupt level to commanding a cycle steal operation, which should show me the occurrence of the cycle steal L1 status signal as the machine loops continuously in cycle steal mode. 

On the flash programming front, I discovered that the Adept utility should recognize the FMC Carrier S6 board and present a Flash Programming tab. Since it doesn't know what board it is seeing, it doesn't give me the means to load the flash. I should be able to load the flash through Xilinx Impact in the toolchain, if I can figure out the proper settings and configurations for the tool. 

Limited time due to holidays but a bit of work on SAC Interface

Because of the holidays I didn't spend much time on the 1130, being busy with family. However, I did spend some time on the SAC interface and I bought myself an Intel Edison to play around with for some future aspect of the project.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I set up all the LED signal driving logic in the interface box, controlled by switch 0. When sw0 is off, the B register is displayed on the additional LED board. When sw0 is on, the additional LED board displays, from left to right:

• T0 cycle
• T2 cycle
• T4 cycle
• T6 cycle
• X0 cycle
• X2 cycle
• X4 cycle
• X6 cycle
• Clock Out (running)
• Phase A
• Parity Stop
• Reset
• XIO instruction E1 cycle
• Meter Out
• Cycle Steal Level 1
• Inhibit Cycle Steal Requests

The four user LEDs on the breakout board always display:

• Interrupt Level 2
• Interrupt Level 3
• Interrupt Level 4
• Interrupt Level 5

I worked with the spare fpga board (Nexys2) to ensure that the setup for reading and writing registers in the FPGA via the utility on the PC and a USB link were functioning properly. It worked fine, although the addresses and bits returned are reversed compared to the PC. I made a fix to swap the bits around end to end and got the results I expected. Based on that, I adjusted the SAC Interface board logic to ensure that I could access those registers via the SDK.

However, the erratic injection of interrupts was back, the on board LEDs didn't lite, and the LEDs emitted on the add-on LED board don't seem to correspond to anything useful. Something odd going on here, plus I don't yet know how to load the configuration into flash for automatic bootup.

I spent a bit of time working in Python to access the registers from a PC. This will be the heart of the virtual peripherals I will implement in the interface, but I have to get more familiar with the Adept SDK, the hardware system for USB communication, the ctypes mechanism in Python to call c libraries and other details in order to create solid code on the PC side. 

Keypunch interface problem fixed, more progress with SAC interface testing

1053 CONSOLE PRINTER RESTORATION

Another hour down - no sign of the spring. Moved on to other tasks where I could make progress.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I installed the interface and began testing. I had some odd behavior, which I traced to the relays whose contacts are still oxidized thus their connections are unreliable. I took each one out, hooked up the VOM to each contact and used my burnishing tool to clean off the oxide. It was fairly tedious with four sets of contacts on average per relay and quite a few relays, but I knew the keypunch would be more reliable once this was done.

When I was last working on the keypunch some weeks ago, I had a card jam and something is still wedged in the punch station so that the card won't advance. It could be a problem with the darned oxidation on the contacts for the escapement mechanism, but one way or the other I can get this fixed.

In spite of the problem, the keypunch itself and my interface believe it is actually moving and punching the card. That means I can still test to see if the interface resets before it completes punching 80 columns, the main problem I had before.

Success! I can rattle off a full card worth of punches and/or spaces with no problems. Further, I tried a read operation and it worked too. The data punched on the card I put into the read station were picked up perfectly.

No need to put in the zener diodes, so the modifications are done. I have some diagnostic print commands telling me the amount of free memory, which I will pull out.

This box will be ready for final testing once I clear up the mechanical issue blocking my keypunch from moving cards through the punch station. This failure occurs with or without the interface, when I punch on the keyboard or when I send data through the box, thus this is unlikely to be an issue with my device.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

After some cleanup, the box no longer generated any spurious signals to the 1131. I could put the 1130 in any mode including run and see it pop into the interrupt level when I flipped the switch on my box.

What is not working properly is the Adept mechanism that reads and writes to fpga 'registers' through the USB link. The Adept program is probably not working right, rather than my logic, because it lists the board with its proper descriptor but states 'unknown product'. I believe that the utility won't try to access the remote side unless it recognizes the board is capable of that function.

I will have to set up some Python code that uses the SDK to access the board function, displaying the values of the signals coming from the 1131. I need to see all of that in order to validate that I have the signals properly assigned and they all work properly.

I think I know why the Adept utility doesn't recognize my card - I have the breakout board added, with its own devices on the JTAG chain, thus not the same as a standalone FMC S6 card. While I can work on my SDK based Python code, I decided it might be faster to just add some LEDs to the box.

I have several connectors available on the breakout board I am not currently using, plus the board itself has four 'user' LEDs I can drive. Using two jumpers I am wiring in a quicky board with 16 LEDs. Using one of the slide switches on the main board, I can display 32 signals, 16 at a time, on the new board plus the four on the breakout card giving me access to all 36 inbound signals.

Quick LED board to display 16 signals at a time

I soldered up the quicky board with its LEDs and put the connector pins on the ends of the wires. However, I don't have the 6x2 sockets to insert the pins into - a trip to Frys is in the cards so I can finish this. I also have to define the 20 new signals for my LEDs in the UCF and VHDL files, route the signals to the LEDS including use of the slide switch, and then I can resume debugging my interface box.

Adding logic for my spare board to debug the register read/write function over USB

At night, when I am not working on the hardware, I am using a spare fpga board, although not the same type as in my interface box, in order to debug the Adept link and my python code.

Spare board I used to develop and debug the USB register read/write functionality

SAC Interface communicating both ways with 1130, debugging proceeds steadily

1053 CONSOLE PRINTER RESTORATION

I put in more time today hunting the elusive spring inside the mechanism, but still no sign of that rascal. I ran out of daylight, spare time and energy working on the SAC interface, so not too much time put in on the console printer or the keypunch interface.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I began installing the improved arc suppression design today, adding heavy duty ground lines to run back to the keypunch power supply. I haven't finished the zener diodes to clamp the input lines, nor have I hooked the ground wires into the main keypunch power supply, so no testing yet.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I triple checked the assignments of FPGA pin to signal, to connector pin, to interface board and so forth. I discovered that my spreadsheet that correlated the various pins on the breakout board to the 160 pin SAC cable to the logical signal to the fpga logical net name to the fpga chip pin was corrupted.

It took a while to carefully align everything for the driving circuits, but when I brought the box up after this adjustment, it reliably forced the processor into the chosen interrupt level (I used the two slide switches to request either IL4 or IL5; both worked properly).

I am adding a diagnostic mode where I can see the state of all the received signals quickly using the Adept register mode utility and some logic mode I added to the fpga. Otherwise, I had to make use of just two LEDs on the board to test out some 36 input signals, which would have been inordinately tedious to do with 18 recompiles of the logic and testing cycles.

I haven't yet figured out how to get my logic configuration into the flash ROM on the board so that it boots up correctly from ROM at power up. At the present, I have to jumper the AC relay to power up my box first, manually load the configuration into the FPGA, then power on the 1130. When I get the ROM boot working it will power itself up correctly with the current logic configuration.

SAC Interface box as it is tested, USB cable at top links to PC for configuration and test activities.

My box seems to work okay in a static environment, when the 1131 is paused at one of the T clock states (in SS mode), but in any other mode it quickly decides I am asking for all four interrupt levels and probably is sitting in a cycle steal loop. Likely this is a noise, induction or similar problem that I can diagnose with a logic analyzer or storage scope, once I get back to testing.

My diagnostic mode didn't work, but that was due to a flaw in my logic for that new functionality. I will correct it tonight in order that I have this information available for future testing.

Console printer restoration creeps along plusb testing progress on SAC interface box

1053 CONSOLE PRINTER RESTORATION

I continued the hunt for the errant spring, meanwhile re-installed the tab gang clear and tab overthrow stop plates which I had removed for better access to the escapement and tab mechanisms while I was fixing the tab issues.

The gang clear plate went on smoothly, but while I was maneuvering the tab stop plate into position, it slipped from my fingers and fell inside to disappear totally from view. With the relative large size of the plate and the openness of this area of the typewriter, I expected it to be easy to see and retrieve it.

However, it vanished as if it had fallen through a wormhole to some alternate dimension. I spent twenty minutes looking carefully and turning the machine, to no avail, before I decided I had to remove the motor. With the motor out, the entire area where the plate fell was accessible with no place to hide. Retrieving the plate, I put it into position on top of the carrier.

It was an opportunity to clean out accumulated oil and grease in the area, before re-installing the motor. It was fairly easy to put this back in place and get it adjusted for good smooth operation.

I then adjusted both of the plates to meet their specs. The gang clear plate has to be within a range of distances from the clear post of the current column on the tab rack. Too far and it won't clear the posts, too close and it will interfere with carrier movement. The tab stop plate must allow the tab mechanism to latch up reliably, but not move so far forward that it can interfere with the tab rack itself.

The adjustments done and the motor back in place, I can return to the carrier return and missing spring issues which are all that remain to address. I put in another thirty minutes of searching and FINALLY spotted the missing spring. It sat in a spot parallel to several other springs which are attached and functional, so challenging to notice it wasn't supposed to be there. All my prodding in the past didn't uncover that fact, as it was wedged in a way that made it seem attached.

Hurray, I thought, as I got my tools on it and lifted it most of the way out of the typewriter. That is when it happened - the spring popped loose and disappeared again into the bowels of the operational clutch area. Again. After five minutes of looking with no clear sign of the spring, I put this aside until the utter frustration dissipates. I wouldn't want to do any damage while under the sway of emotion.

I came back to the typewriter as daylight faded, since this is inside the garage and equally easily searched day or night. I devoted another fifteen minutes of hunting and peering, which of course included the spot that this spring had hidden last time around. No luck, but I will keep at it as much as I can stand each time and return to the Sisyphean hunt each time after the frustration has abated.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I pulled the interface box out of the keypunch and will insert some additional protective devices just in case we have induced voltages on the wiring that are forcing the Arduino to reset. I will put zener diodes on the inputs even though they should only be switching 5V power we emitted, and improve the arc suppression design for the outputs.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I got right to the repair attempt this morning, setting up the board, clamp, heat gun, replacement connector and other items on a table outside. After a few minutes prep-ing the board with flux paste and fresh solder on the pads, it appeared I might be able to solder this down with just my fine tip soldering iron and ordinary solder.

I gave it a shot and was fully successful! I hooked up to a PC, downloaded by test logic to the board and am ready to start testing of the interface box. Very pleased. The cause of all the problems is a malformed cable, the one sent to me along with the fpga board - it won't fit into any microUSB sockets but another cable I had in my supplies slid in easily to both the original and replacement sockets on the board.

The fpga board was put back inside the box on its mounts, the breakout board fitted onto the high density connector and screwed down, then the power and signal connectors were all put into place. A USB cable was the last connection, in order to test the board and update its hardware configuration.

Time for a bench test of each signal pair from the SAC cable connector, ensuring there are no shorts and that the resistance of each pair is an appropriate value for either a receiver or driver circuit. Once it had passed I could connect cables between this box and the 1130 and safely power up.

My initial test program is set up to inject appropriate (off or idle value) signal levels into the 1131, see that the existence of the box doesn't stop the 1130 from operating normally. In addition, it has a mode that will force an interrupt to be taken (on level 4) and show receipt of certain processor state.

I powered the box up in order to load the configuration file, but the loading software reported no valid devices found. It definitely sees the USB link and device, reporting the correct board type, but otherwise can't see the fpga for bit programming nor the flash devices to store configurations.

It worked fine with just the fpga board, but with the XM105 breakout board installed it is failing. That is the clue - something is wrong with the JTAG chain that is used to detect and program devices. I remember reading somewhere that if the chain is open, the signal won't wrap back to the sender which may be what is happening, if the fpga board opens the chain when the HPC connector is installed.

Without having logic set up by my program, the outputs are not driven to zero, instead defaulting to their 'on' condition. Thus, the 1130 reported interrupt requests on all four levels, but didn't show any signs of distress otherwise. Once I fix the program with the JTAG chain and can configure the logic of the interface, I should be able to test steadily.

I found that my fpga board checks a signal called FMC-Present which is one when the breakout board is installed. When on, it breaks the connection of the JTAG chain, allowing the user to insert additional devices on the breakout board. All I need to do is connect the JTAG signals TDI to TDO on the breakout board and this should work fine. Made up a jumper and installed it. Worked fine now.

I am able to receive and properly interpret all the signals arriving from the 1131 to the box, but my signals requesting interrupts are being ignored. I may have jumpered something in the 1130 to block these in my earlier restoration and debugging, or I may have a problem with the circuits that drive input to the 1131 from my box. I am going to monitor the voltages on one of the signals to see what is actually occurring on the cable.

The output voltage stayed high, although it should have been pulled down to near ground when I activated the request. I had an LED indicating the state of the signal I believed I was sending to that circuit and it faithfully matched what I set with the fpga board switch. I moved the voltmeter to the input of the circuit which should be driven by my fpga, yet I saw no change in voltage as the request changed between on and off.

Any number of problems could be causing this:

• mis-wired connector or confusion over which connector pin is emitting this signal
• problem with configuration of fpga resulting in invalid voltages driven into circuit
• my wiring of the SAC interface connector did not connect IntReq Lvl4 to this circuit
• unknown flaw in the circuit

I will be investigating as many as I can tonight, since daylight is fading rapidly, putting an end to my testing today. I am satisfied with the progress now that I have a working programming link to the fpga board. I have an idea of some additional debugging logic I can insert that will allow me to do some bulk verification of the correctness of the wiring of the inbound signals from the 1131. 

Futile hunt for spring lost inside mechanism of console printer, plus prep to repair FPGA board

1053 CONSOLE PRINTER RESTORATION

My first act was to hunt for the spot where the spring fell off, as that might be a cause of the failure to consistently release the margin rack when carrier return operations start. I discovered it belonged on the pivot that twists the tab torque bar, to keep the link from pulling on the torque bar when it is in its inactive state.

The spring is challenging to fit into place, as it is strong, has the ends bent into an almost complete circle requiring force to push over brackets, the bracket and lever are both thick, and the two holes are deep inside the machinery. I had to use forceps, spring hooks and other devices to try to attach it.

Boom - the spring snapped out of the forceps and flew to an unknown location. I wasn't even sure whether it stayed inside the typewriter or flew elsewhere in the garage. After a sanity break, I continued my search and discovered it deep inside.

However, retrieving it was not the piece of cake I expected (you would think I would know better and harbor deep pessimism, but no . . . ) and it lodged somewhere down inside the mechanism. I spent somewhere between three and four hours (yes, hours) patiently looking, probing and testing but as of mid afternoon I still don't have the spring.

For a diversion, I watched the carrier return mechanism, focusing specially on where the mechanism tilts the escapement torque bar and pulls the link that releases the margin rack to the right. The issue is that a part of the latch assembly is not restoring all the way to its rest position, most likely due to sludge but we shall see what actually causes this.

At some points the carrier return latch is not releasing so the cycle starts over and over - the errant spring is likely somewhere in the path of the clutch latch or release, but it could be a random coincidental new malfunction.

It is maddening to feel that, if I can only find and install that lost spring, I will be able to quickly finish the tweaks and put this printer back together. Depressing to think that I have two different peripherals suffering from a lost item in the mechanism, devilishly hard to locate, without which I can't put them back under power or finish their restorations.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My parts had not yet come and I can't do any testing until I repair the micro USB connector on the fpga board. I think I get everything on Monday at which point I can do the repair and start some testing.

Tonight, to my surprise, the micro USB connectors arrived and I put together the plate which I will use to hold the part in place while I solder it down. I intend to use the QuikChip solder, a special formula which liquifies at a very low temperature. By using my hot air rework gun to heat the connector with its paste underneath, I should get that new solder flowing without the rest of the parts on the board loosening. Tomorrow is the day I give it a try.

FPGA board with missing USB connector right edge mid height

Spare micro-USB SMT connectors

Jig to hold down part during soldering

Ruined disk heads removed from Diablo drive (external drive, not primary 1130 disk), console printer adjustments

1053 CONSOLE PRINTER RESTORATION

The main problem appears to be sticky behavior of the margin rack which should be popping to the right when a carrier return begins in order to be slammed left as the carrier reaches the left stop. I am also a bit uncertain of the adjustment for the linkage that will release the rack, as that might not be ensuring the release is made every time.

In hand cycling to test this, I saw the machine begin to operate poorly in another area I thought already resolved - tab movements. The tab mechanism on the rear of the carrier should be locking up until it is released by a set pin at some target column, but instead is not locking so the tab movement ends prematurely or is only a few spaces long.

This appears to be the sludgy old lubrication still causing problems, alas. I am working with 99% Isopropyl Alcohol to clean some of it out, everywhere I can get to in these mechanisms, and then replace the lubrication with an appropriate light oil (Mobil 1).

I removed the tab overthrow stop and gang clear plates from the rear of the carrier, which leaves the escapement, backspace and tab mechanisms clearly visible and accessible. I was able to carefully observe the operation of the mechanisms which led me to the likely cause of my erratic tab movement.

The tab torque bar is twisted by the cam and levers on the right rear of the machine when the tab operation is selected. The bar pushes the tab lever toward the rear, pulling the escapement and backspace pawls out of their racks to allow rightward movement of the carrier. The tab latch should set, keeping the pawls out of the way until the tip of the tab latch strikes a set pin on the tab rack, which pivots the latch, releasing it.

The latch is not setting - but if I push the linkage to rotate the tab torque bar myself I can make it reliably latch. Thus, I think that I can shorten the linkage, which has a turnbuckle for adjustments, to ensure that the tab latch is pushed far enough to reliably engage.

The failure of the margin rack to be released to the right when a carrier return operation begins is a similar situation - a lever pulls a linkage that releases a latch on the right of the margin rack. I will adjust that turnbuckle to make it shorter, thus moving the release arm further on the margin rack release mechanism.

After adjusting the tab torque linkage, the tab latch is setting reliably. Whenever a tab is commanded it latches and moves to the right, only resetting when it hits a set pin on the tab rack. Excellent behavior. One major problem resolved.

I shortened the linkage to release the margin rack but it isn't so reliable. It appears that the range of movement is too short for the lever that pulls on the linkage. I am going to dig further into the mechanism and adjustments to sort out why and what to do about this.

I did find that if I am doing a right tab and it runs into the right margin, it isn't releasing the tab latch. I need to see how this is supposed to occur before I can sort it out. It may be related to the problem with the rack release, or not.

I did find a spring under the mechanism, undoubtedly fell off the typewriter somewhere. I need to figure that out and replace it, needless to say. My first spots to check will be the carrier return and tab sections of the operational shaft, about where it fell, as these could be the cause of my two remaining problems.

After investigating the theory of operation manual, I realized that the tab latch will remain set when the carrier runs into the right margin stop. It is when the carrier return operation begins that this is resolved, because the escapement torque bar is turned by the carrier return mechanism in order to keep the escapement and backspace pawls out of the escapement.

If that didn't happen, the carrier would make a ratcheting sound as the escapement pawl skipped over all the teeth on the escapement rack. The twisting of the escapement torque bar also swings part of the tab latch mechanism out of the way, releasing the latch. Therefore, the right hand margin behavior is not a problem.

I reached the end of the evening without a clear diagnosis of the problem with the carrier return mechanism. I will study the theory, parts and adjustment information, plus review some video training on Selectrics, preparing to tackle this again tomorrow.

CHI INTERFACE AND DISK DRIVE

I removed the disk heads from the Diablo drive that came in the CHI rack - they show major damage from a head crash and are unusable as they are. They have crashed into the surface of a disk, ruining both the disk cartridge and the heads.

Head crash damage visible on the heads - scrapes on metal plate and magnetic oxide wedged in scratches

Rectangular slow beside upper holes, to side, with brown iron oxide coating from disk packed over ceramic head inside

You can see lots of scraping on the shiny metal surface of the head, caused by various particles which were embedded in the disk surface which rotated under the head. Also, you can see significant brown ferromagnetic coating material from the disk surface has been packed in the rectangular gap which exposes the ceramic part of the head and its metal poles that do the actual reading and writing.

First, the oxide material has to be cleaned out of the gap, then the condition of the underlying ceramic and electromagnet poles must be assessed to see if they can be saved or need rebuilding/replacement.

The metal plate has to be removed from the arm assembly and the internal ceramic, coil and pole magnet assembly which is the functional part of the head has to be removed from the plate and set aside.

Next, the metal plate would have to be polished to remove the scratches, perhaps with a new layer of the chrome-like surface added.

After removal of scratches, the metal surface must be returned to the curvature it needs to fly aerodynamically on an air cushion at a target height above the rotating disk surface, without wobble and certainly without oscillating vertically in a way that might bring it into contact with surface irregularities or the disk itself.

When all else is done, the ceramic/coil/pole part has to be put back onto the plate at the right alignment and depth, the plate affixed by microwelding to the arm in the proper orientation, before it could be put into the drive and used again.

As you can tell, rebuilding a head requires special equipment, skills and quite a bit of care. Years ago there were several services which did this processing, taking damaged heads like these and returning assemblies that were rebuilt to be as good as new. Once the arm and head began to be built into the disk drive itself, users no longer removed and replaced heads as a maintenance activity - without that process, the need for head rebuilding services evaporated.

If I am lucky I will find a service that still is able to do this. There may be a tiny market handling repairs to systems that must remain in service even though they are decades old and no longer have spare parts availability. Defense systems are just one example of situations where really old technology is still being used with the need for repair/rebuild services supporting an ecosystem. The cost of replacement of the technology with more modern tech is so high in these cases that is justifies high charges for service and rebuilding, even at the extraordinarily low volume of such activity.

If anyone knows of a service or person who can rebuild the heads, please let me know. If you know of someone who has replacement heads for the Diablo Series 30 disk drives or something compatible, also pass along the information.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I will try to solder on a replacement microUSB connector onto the fpga board. Digilent replied but does not do repairs. They offered to process a warranty claim but it is clear damage by me, not a defect, so that is off the table. I ordered the receptacle from Digikey and should have it in a couple of days, slight delays due to heavy holiday shipping volumes and of course a few actual holidays where packages stop moving.

Fighting the last problems with the printer

As I had mentioned, I spent time meeting friends from the 1401 Restoration Team at the Computer History Museum and then had my haircut in the afternoon, but did get into the garage for a few guilty stolen moments.

1053 CONSOLE PRINTER RESTORATION

Wrestled the C2 contacts into position to give the intended timing, breaking the circuit as the print cycle hits 20 degrees of rotation and making it again as we pass 120 degrees on the way to completion at 180. This timing is related to the realities of the selection mechanism, which has released the various latches before 120 degrees, at which point the type ball is rotated, tilted, locked in place and just about to strike the ribbon/paper.

If the print solenoids are activated at this point, they will lock in the next character but not interfere with the remainder of the current print that is in process. However, the cycle clutch latch won't stop the rotation, allowing the machine to continue smoothly into another print cycle based on those solenoids which were activated late in the prior cycle. This maximizes the print speed of the machine and reduces stop/start shock.

The device adapter logic in the 1130 is responsible for monitoring the circuit that goes through C2, holding off until the 120 degree point before commanding the next print operation. If electronic hardware were not so expensive at the time these systems were designed and built, a digital buffer inside the 1053 could have accepted the command for the next character and held it until it was time to activate the solenoids, simplifying the requirements for device adapter logic in systems like the 360 and 1130 that drive these printers. Instead. the 1131 directly drives each solenoid and must monitor mechanical state of peripherals in order to time activities correctly.

I have a selectric based mechanism in a Dura word processor that I will restore to act as a 2741 terminal on my 1130 system, but it does have a motor pulley of the same type as I need. I will 'borrow' this one and back-fill with a replacement part I can put back on the Dura. Installed now on the 1053 and working well. I still have some motor vibration, not sure why, but it is not the pulley slots anyway. Quieter and more gentle, so progress for sure.

The carrier return issue with zooming past the left margin stop is still here, at least under power. I need to do more research to figure this out and stop it, now that the printer is so close to operational again. By the end of the evening, I still didn't know why it was hit or miss. Time to step through the adjustments for the high speed carrier return starting at step 1.

CHI INTERFACE AND DISK DRIVE

I decided to pull the read/write heads from the Diablo disk drive in the CHI cabinet, in order to find someone who can restore them to working condition. There had been a number of businesses that did this with disk heads, back before the heads were permanently integrated into the drives and not worth rebuilding. If I can find any that still exist, I can get the Diablo drive back into operation.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Still looking for a way to get those four leads soldered onto the fpga board, particularly the three that are side by side and thus can't be individually attached (the soldering iron loosens adjacent wires). Ron Crane had some good ideas for how I can proceed, will try them out.

Console printer adjustments and restoration almost complete

Tomorrow I have obligations at both the Computer History and Digital Game museums, plus an appointment for a haircut, really constraining my available time with the 1130, but I should be back at the machine in earnest on Thursday.

1053 CONSOLE PRINTER RESTORATION

It dawned on me that my assumption for the restoration, that this was properly adjusted before it sat in storage, is not correct. I see the typeball triangle on the top plate, which should point directly at the platen when at rest, is rotated 5-8 degrees to the right instead. This is undoubtedly causing the issue where the detent bar can strike the tip of the tooth and not enter the proper notch on the typeball rim.

Incorrect home position of typeball, rotated a bit to the right

My early operation of the console, which yielded the correct characters for every position on the ball, lulled me into believing my assumption of correctness. Visually, however, I see it isn't so.

Print shaft gear with setscrews, adjust rod to proper position then tighten these up

The rotate arm should be directly vertical when the typebar is in the home position (at rest), but it is tilted so the top is a bit to the right of the pivot at the bottom, leading to the incorrect home positioning. The adjustment for the rest position is a turnbuckle on the rod that connects the mechanism selecting the rotate amount to the rotate arm.

I hate the idea that I might start adjusting the rotation position but have ignored some 'earlier' adjustment which may be off spec. I believe I have to at least do a quick validation of the adjustments starting at step zero, in sequence, since each adjustment builds off prior ones. Adds a bit more time to this particular restoration but ultimately worth it.

I also see the belt and motor oscillating, showing that the corroded slots on the motor pulley are not allowing the belt to fit into the slot. This raises the belt as the pulley rotates to put the bad slot at the furthest point from the main pulley, increasing tension on the belt, bending the motor forward on its shock mounts, and thus generating the oscillation. It has to be replaced by a good motor pulley - fortunately that replacement will not require any disassembly of other parts of the printer, only loosening of the motor mount screws.

Several hours of careful work gave me proper timing for tilt/rotate, print and filter shafts and everything else except for the C2 contacts that indicate when the mechanism is busy during a print cycle - it should break the connection at 20 degrees of rotation and restore it at 120 degrees.

Timing of C2 contacts

C2 contacts in situ, continuity tester connected by colorful alligator clips at bottom

Adjustment screws - oval slots but no positional adjusters, just hand movement

Another view of contacts

The contacts were a bit oxidized, only conducting sporadically. I used my burnishing tool to strip off the oxide layer, restoring proper operation. Adjusting the contacts to make and break at the proper degree positions was challenging. I could get one or the other point working, but the opposite state change would be too far off its target. I ran out of time today but will be attacking this further in the coming days.

Burnishing tool for oxidized contacts

I found the cause of the carrier return problems - I had dressed some wiring with a cable tie which interfered with a rod used to absorb the energy of the carrier hitting the left margin. This machine has a special feature called High Speed Return installed, rather than the usual mechanism and return speed. It works fine now.

I included pictures of some special tools used to work on Selectrics - the Hooverometer, a spring hook which is used to install and remove springs, a set of bristol wrenches and a circlip installing tool. It is easy to mistake the bristol wrench openings for allen wrench openings, but using the wrong tool rounds off the points rendering the screws useless.

Hooverometer to measure separations and heights

C-clip tool, spring hook and bristol wrench set

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I attempted to solder the teeny wires to the teeny pads on the fpga circuit board, but continued to have problems with each method I attempted to hold three wires simultaneously and rest them on their respective pads less than .01 inch apart.

I also contacted the maker of the board, based on comments in some of their documentation that suggests they can make repairs to the board, giving me a backup if I can't get this wired up myself. I found that the board I bought just 30 days ago is now discontinued, removing the option of tossing a few hundred dollars away on a replacement.

1053 Console Printer work

Some health problems have arisen with my father-in-law that took up some time today and likely will take me away from the 1130 restoration from time to time, but not continuously.

1053 CONSOLE PRINTER RESTORATION

I realized when I started on the 1053 this morning that I had two adjustments left to make, not just one. After I set the final print shaft timing, I need to set the contact switch that gives feedback to the adapter electronics about when the print operation is complete to the point where another character or operation can be requested.

Shift interlock cam on filter shaft 

Escapement cam - spaces after each character printed - on filter shaft

The print shaft timing involved setting the timing for when the detent first contacts the notches along the bottom of the type ball, so that it is safely inside the notch but on the side - this gives the detent a 'wiping action' as it moves to the center of the notch with continued rotation of the print shaft.

Gear train - print shaft on top (smaller black pulley)

Print shaft going into carrier at right, cycle clutch and drive belt visible below

Black detent bar entering notch in typeball, barely visible 2/3 of way to right along bottom of pic

The C-2 contacts ride on the cycle shaft gear body, ensuring that the timing of the cam climb point and slope is synchronized. However, the vertical position of the contacts determines exactly where the switch closes and opens relative to the rotation of the cycle shaft, as it moves up or down the slope.

Carrier from top while standing behind printer, sliding on print shaft and along escapement bar

The open and close points are easy to set by reference to the degree wheel affixed to the left end of the cycle clutch shaft - sits at 0 when at rest, then marked in single degrees for the 180 degrees of one cycle.

Degree wheel mounted to end of cycle clutch shaft

To adjust the print shaft timing, I put the Hooverometer in place to block the cycle clutch at the halfway point (half-cycling a character), selected a specific character by pushing the appropriate solenoid arms down, then rotated the hand crank wheel. The gear on the end of the print shaft is held in place by setscrews; loosening them allows the shaft to be turned to advance or retard it compared to the cycle shaft position.

With the machine stopped at the half-cycle point (registering 90 degrees on the degree wheel which matches the state of the clutch shaft), the print shaft is turned to spot the point where the detent bar engages the teeth of the typeball.

However, as I did this, I could see that the ball was not properly rotated. The notch of the teeth was offset so that the detent bar could land directly on the crest of the tooth or even snap into the wrong notch, depending on the rotational play of the typeball.

Now I have to go back and validate the rotation mechanism settings, before moving ahead. The current mis-positioning can cause breakage of the typeball teeth or damage to the typewriter mechanism.

Rotation of typehead controlled by movement of this vertical arm, thru the rotate tape on pulley

Tilt of the typeball controlled by this vertical arm, thru the horizontally mounted pulley for the tilt tape

Selection mechanism that converts various solenoid latches into movement of the tilt and rotate arms

Another anomaly I see occurring is sporadic failure of the left margin to stop the return of the carrier, which seems to be caused by sludge in the margin bar and sliding components attached to it. I exercised them a bit and seem to have a more reliable left stop now, but will keep my eye on it.

Under power, the motor still vibrates a bit which is caused by the corrosion on the motor pulley, such that the belt does not slide into the corroded slots as fully as the normal ones. I need to locate a good replacement and install it before the new belt also is damaged. I think I understand why the typewriter was modified with a power switch on the front panel - the vibration and miss-adjustment of the typewriter would be objectionable but turning off the motor removed the problem symptoms (but the console printer could not be used in this case).

SAC interface work and 1053 typewriter repair progress

1053 CONSOLE PRINTER RESTORATION

I found the part that must move to adjust the backlash and began adjustments. I can get it well engaged but the backlash of the print shaft to the idler gear is still more than the .001 to .005" that is recommended even with the idler stop as far as I can move it.

I will look at some other machines I have to check the backlash they experience - if it is consistent then I can move on to adjusting the cycle clutch latch holder height, otherwise back to fiddling with the idler gear position.

There are about seven more adjustments to make, some of which I know are quick and easy (e.g. the cycle clutch latch holder height). I continued with the work, getting the backlash into a good range. I then did the height of the cycle clutch holder, using the Hooverometer, a special tool to use with Selectrics.

Next up came a check of the cycle clutch spring and overshoot adjustments, which were within the proper range. As well, I verified the bite of the clutch latch lever was in tolerance.

The next two adjustments are the timing of the filter and print shafts relative to the cycle clutch mechanism. These must move in synchronization which is accomplished by the gear train, once their relative position is set properly.

I loosened setscrews in the gear at the end of the filter shaft and rotated the shaft while the cycle clutch was in its 'rest' position, putting the escapement and shift interlock cams at the proper rotational position.

Before I touched the print shaft, I decided to adjust the motor tension because the belt was skipping cogs on the motor pulley, producing a little 'jump' on each turn. The usual cause of this is that the belt is too loose, plus I thought that the spare belt still had a slight deformation from the way it was stored over the years which would ease out with use.

However, even tightening the belt (by loosening the mounting screws then  pulling the motor) didn't help. I removed the belt from the motor pulley and looked closely, finding a chunk of old belt rubber wedged into one of the slots of the pulley. That caused the slip on each rotation. I removed the pulley and scraped the old rubber out of the slot.

Rubber wedged in slots of the motor pulley

I could see that the bad slot and the two adjacent ones had some corrosion, so they didn't clean up as well as I wished even with a lot of scraping. In spite of having amassed several cubic feet of Selectric parts, for almost every model including Composers and other such rare ones, I had no spare pulley.

Corrosion of pulley after as much scraping and cleaning as possible

I reassembled it and tightened up the tension, happy to feel it rotating smoothly and without any hitches. I believe the wedged up slot and resultant skipping was what caused the failure of my previous replacement belt.

I will finish the adjustments tomorrow with the last step, the print shaft timing. I can then test the printer, reassemble the covers and put it back in place.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I found the pin-out for the wiring of the micro and standard USB connectors, allowing me to attempt to solder the cable from the front panel USB connector to the fpga board. As I typed this, I realized that I would be permanently tethering the FPGA board to the enclosure if I just soldered the connections directly, so I will look for a suitable set of connectors to put in the middle of the cable for disconnection when the board must be removed.

The pads are so small that I have to use 30 gauge wire wrap for the connection on the board then make a joint to larger, more durable wire for the connector I chose. I began soldering these onto the fpga board but the spacing is very close and I found that my soldering iron would release the adjacent wire when I tried to solder a wire on another pad. I need a method of securing all four wires at precisely the right separation, and a means of holding them in position, such that I can solder all of them simultaneously.  This is fussy work and will take some time to figure out a suitable set of jigs.

In the meantime I reinforced the connector plate for the power cable, as the steel is fairly thin and flexed too much with the heavy cable connected. I improved it quite a bit although the receptacle itself does some flexing which I can't avoid given the current thin plate to which it is secured.

SAC interface final wiring, power on test and adjustments of the 1053 console

Major jet lag so not making as much progress as I had hoped, but at least I am visiting the machine for a few hours at a time.

1053 CONSOLE PRINTER RESTORATION

I began the adjustment sequence for the IO Selectric mechanism for everything that was disturbed in order to partially remove the cycle clutch shaft during the installation of the new drive belt. The first adjustments are for the backlash of the gear train that couples the cycle clutch shaft to the filter shaft and print shaft. The bottom adjustment was easy, but the top adjustment is difficult to figure out.

Gear train, top two are too far apart

The print shaft gear is so loose on the idler gear that it doesn't get turned. I loosened all the screws that appeared to affect its position but nothing is changing the relative position of the idler and print shaft gears. I looked at the diagrams from the parts catalog but that didn't shed any illumination on the matter, nor does the maintenance manual.

I will go watch some online selectric repair training course videos on YouTube to see how this is done on a regular machine, then infer the changes for the IO Selectric model I am working with.
Once I get an idea of what is needed, I can go back to the typewriter mechanism and give it a go.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I hooked up the power connector on the box to hook up the power cable from the 1131 bringing the 24VAC control voltage that will power up this interface. In addition, I wired up the rear fan and tested the operation of fans and power supplies. The fpga board powered up, the fans came on, and the signal interface boards are receiving clean 3.3V and 3.0V power.

Final power wiring, remote control relay at top

Connector for power cable from 1131

Connector installed in enclosure

Connector with power cable attached for power-on test

Completed SAC Interface box ready to have signals cable from 1131 connected

The hardware is now ready for testing although there is one more connection I can wire up - hooking up the USB based serial port to the enclosure front panel USB connector, avoiding the need to snake a cable inside the box if a serial connection is used with any peripheral interface that may be implemented in the unit.

Front panel of enclosure with two USB connectors

I don't have initial plans for any device connections that would make use of this but the work to add the outside connector is minimal and the box becomes more generally usable as a result.

My first test had the fpga set up to assert no control signals to the 1130 (e.g. don't request cycle stealing or interrupts), and to monitor the CPU run and interrupt level 4 states on the two LEDs. That should show success with some minimal communication, particularly the ability to properly receive and interpret signals from the 1131. In addition, I set up a switch on the fpga board to request an interrupt on level 4.

As I attempted to hook up the microUSB cable into the connector, which was not sliding in, I had to attempt it several times and wiggle slightly to see if there was a slight misalignment which I could overcome. Unfortunately, the connector was held to the PCB with epoxy which didn't hold very well, as the connector tilted up and came free.

UART connector at top right, spot at lower left where main USB connector came off

Glob of epoxy on bottom of the connector that came off

Cable end at left and broken off connector at bottom - these two will NOT mate

I was able to verify with the separated connector and the cable that the two did not mate, no matter how I worked them together, nor did the cable mate with the other (UART) microUSB connector on the board. I have to assume it is a badly made cable end, although I will check it with other devices just to rule out problems with the board connectors.

However, this did force me to address the front panel USB connection change I had been pondering, now that the microUSB connector is broken off the board. I will carefully attach the leads of the enclosure cable to the pads on my fpga board, such that I can program and use it without opening the enclosure or touching the fpga board directly.

It won't be tonight, as there is almost no daylight left to do the fine soldering necessary, but I can take this on tomorrow. of course, the test is also postponed due to this unexpected issue.