Small progress and ceasefire on the 1053 spring front, major coding and testing of the SAC Interface virtual and mirror devices

1053 CONSOLE PRINTER RESTORATION

After studiously ignoring the spring most of the day, I strode back into the valley of death for my day's ration of utter frustration. After only 30 minutes, I was able to get the errant spring completely out of the typewriter. Now, if I can get the spring attached first to the tab interposer, while dangling backwards, I theoretically can reach in with a spring hook and pull the rear of the spring back over its mounting tang.

I put in another 30 minutes - my quota for a session - but didn't succeed. I will keep coming back, but in frustration-limiting short bursts until I get an end on, then repeat for the other end as long as necessary.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I completed the Python (PC side) code for the virtual 2310 disk drive, allowing the user to open an IBM 1130 Simulator disk image file and allow the 1130 system to access it as if it were a physical cartridge sitting in a real disk drive (an IBM 2310 drive, number D).

I made some enhancements for more faithful error recovery and behavior. A helper thread now models the 1500 rpm rotational speed of the disk, cycling the sector number so each sector lasts 10ms. The read and write logic will wait until the helper thread's sector number matches the target before it begins the data movement. The seek logic will calculate the time a seek would consume on the physical 2310 drive and sleep until that has passed.

My experiments with the disk image files showed that I was correctly converting between those encodings and the 1130 words that I would read or write. All that remains is to do some testing - a safe copy of the file, load the DCIP utility into core, set the console switches for drive D and then do some IO to it.

In lieu of battling the typewriter spring, I worked on the Python program to fill out the remaining virtual or mirror drivers. Still to complete were:

• Mirror bit switches
• 1403 line printer

By the end of the evening, I had most of the bit switch coded, although the GUI display of the switch settings is not yet done. I also roughed out all the pseudo code for the 1403 printer function. In addition to finishing that worker thread for the 1403, I have to write the routine to select an output file when the user wants to start the 1403 printer. 

Spring 99999, me 0 but continued building out SAC Interface Box functionality

1053 CONSOLE PRINTER RESTORATION

I put in two hours with the fiber optic camera, rotating the typewriter every which way and attempting to find two paths:

1. a path for the camera head that would let me see the interposer tang and the unattached spring end beyond it
2. a path for tools to reach in, snag the end of the spring, pull it over the tang and release it there

I was not successful. I made a try again in the early evening when work was done. What I was trying to avoid is the need to disassemble everything once again (remove operational magnets, remove mainspring, unhook linkages for various functions like space and return) which would effectively set me back many weeks. 

I did manage to find a path with both visibility and tool access. It is up from directly under the typewriter, as long as I rotate one mechanism out of the way. Manipulating the spring to fit through the interposer hole was still a very fiddly and business, but after about thirty minutes, it popped off the spring hook and rotated somehow inside so I can't see it, find it or move it.

I rotated the typewriter once to move the spring back where I can see it, but as I barely touched it, the spring fell back into the Stygian depths. After a bit more time, I set the task aside AGAIN.

1442 CARD READER/PUNCH RESTORATION

I cleaned up some logic in the fpga for the virtual card reader/punch, which should allow me to begin testing it after I disable the built in 1442 adapter in the 1131 and I get the typewriter back in operation.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Besides testing the virtual, real and mirror device adapters I already have coded, there is more I can do to complete this circuitry. I have the switch over to the I2C breakout boards, replacing the medium speed SPI links, but also several additional device adapters need to be developed:

1. real adapters to connect to a pair of IBM 9 track tape drives, requiring a SCSI interface to speak to those two drives. They will appear as 2415 tape drives.
2. a virtual 2415 tape drive, allowing the PC to act as a tape drive with files acting as tape reels.
3. real adapters to connect three DEC RK-05 disk drives, emulating 2310 disk drives
4. a virtual 2310 disk drive allowing an IBM Simulator format disk file to be accessed from the PC. 
5. a real adapter for my Dura IO Selectric to act like a 2741 terminal for use with APL/1130
6. a virtual 2250 graphics terminal

Four of the six device adapters are going to be harder than the prior set, partly due to the more complex device management involved, but the virtual 2310 disk drive and real 2741 terminal support won't be that complex. The 2741 will look almost the same as the 1053 adapter logic, which is well documented in the ALDs of the 1130.

The only way that the virtual 2310 drive can work is to drop the goal of matching the real disk drive performance. Since the drive uses cycle steal to move the words being read or written, I can stretch out the IO to work over the USB link transactional system. I already have the scheme for the PC side worked out.

By the end of the evening, I had all four 2310 drives set up in the SAC box fpga - the first three are stubs that simply return a Disk Not Ready status DSW when addressed. The fourth is all the logic needed on the fpga side for the virtual 2310 disk drive.

Knowing the format of the IBM 1130 Simulator disk files, I could begin writing the code in Python for the PC side application. That process will take a day or two.

Getting camera visibility with the fiber optic camera, plus fpga touchup

1053 CONSOLE PRINTER RESTORATION

I didn't have much free time but I did get into the workshop and inserted the fiber optic camera into several vantage points wide enough for the head to clear. My goal was to get a view of the unattached spring and the hook on the back of the tab interposer where the spring needs to be connected. If I can see it, then I can probably maneuver a tool in, through another opening, and accomplish the deed.

I got a pretty good view for seeing the unattached end of the spring, but not quite the end of the tab interposer where it should hook. Once I find a route in, I will hook the end of the spring in preparation to pull it forward towards the interposer tang where it should be attached.

Loose end of spring, down inside mechanism, using endoscope to see it

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I completed the logic for the virtual 1442 adapter with its ability to ignore any IO directed at area code 2 unless it is ready (meaning active on the PC). This is important for when I leave the IBM built adapter inside the 1131 enabled, particularly if I want to use the real 1442 reader/punch.

Using fiber optic camera to work on 1053, plus continued SAC Interface enhancement work

1053 CONSOLE PRINTER RESTORATION

The fiber optic camera arrived today - may be a problem getting all the way into the small spots as it has an 8mm diameter (just under 1/3" for the metrically challenged). It also focuses 1" from the lens, which is a huge distance compared to my problem area, but we will probably get a better idea of what is going on inside, even if not perfect.

Fiber optic camera - inexpensive but quite useful

Looking with the camera in one of the few spaces it can fit, I did confirm that the problem is the rearward pulling spring that hooks to a bar at the back of the typewriter frame and with its front over a hook shape on the tab interposer. The spring is not hooked to the interposer.

So far, the camera does not give me a view of the critical area - the hook shape on the interposer and the far end of the spring - which is what I need to attempt a reconnection. I found a few other angles where I can insert the camera.

1442 CARD READER/PUNCH RESTORATION

I worked further on the PC side code, to allow the reader files to be opened, a 'blank deck' file to be created for punching, and to have the system convert between the 1130 word format and the file format. Before I can fire up this version of the SAC Interface Box, I need to have either:

1. The logic for the virtual 1442 disabled so that it doesn't react to the area code for the device                                                            OR
2. The device adapter circuits in the 1131 disabled by tying the area code 2 signal to ground

Ideally I can set up a logical switch, set by the PC program, such that the SAC Box ignores area code 2 unless I have set the DSW to ready. I will work on that circuitry in the fpga next.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I think I might change from the current medium speed link - an SPI protocol to link to Arduino controllers - and instead make use of a shared I2C bus to several IO concentrator boards. These boards control 16 IO pins (plus more) and can be strung together on the 400KHz I2C bus to handle all the slow speed signals for devices like the 1134/1055 paper tape units, the 1627 plotter and so forth.

I have ordered some boards which I should have in a week, so I need some design work to take advantage of these. I can always hang Arduinos or similar microcontrollers to deal with transient signals and other timing that might be too slow for the I2C link delays.  The board I bought.

I2C 16 pin IO breakout board

Not much free time, but accomplished a bit

1053 CONSOLE PRINTER RESTORATION

I spent my lunch hour attempting to liberate the spring causing the problems with my tab interposer. No luck. I need to get a fiber optic camera to see what is happening and guide what miniscule tool access I have.

1442 CARD READER/PUNCH RESTORATION

I coded the Python side completely and worked on the fpga logic for the virtual 1442 card reader/punch functionality.

Hunting errant spring in 1053, building out device support in SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

The tab interposer has its rear spring in place, but there is another spring hanging in the space blocking the movement. I have to pull it out and figure out what is might be. I thought it might be the spring that holds the operational latch forward toward the interposer and out of the way of the bar that activates the machine function. However, I am not sure.

This is the most blocked and inaccessible area in the entire machine. I can only catch glimpses of part of the spring, I can't see the ends where it does or should attach. There are two possibilities - the spring is one that I lost deep in the machinery months ago, and thus superfluous, or it has partially detached and is needed for the tab interposer to work properly.

I put in another 45 minutes trying to sort out the spring issue, to no avail. Perhaps tomorrow.

1442 CARD READER/PUNCH RESTORATION

Worked out the scheme for the virtual 1442 card reader/punch, soon will finalize the fpga logic and start on the Python program for the PC side of the USB link. The PC side was all blocked out in pseudo code by the early evening.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I have no idea how fast or slow the Python program will deal with multiple peripheral devices simultaneously. There are various ways I can improve the performance, from the interactive workbench which only uses on PC processor through to versions will exploit all cores, then to a rewrite in C if that becomes necessary.

Each virtual or mirror device is a separate Python thread and if allowed to be dispatched across multiple cores on the PC, should handle a lot of the scaling required to support simultaneous peripheral operation. The bottleneck is the single USB link and simple transaction I am using to communicate. If this saturates it could keep the PC side from checking device conditions often enough to see all the activity. This is something to worry about later,not now.

The fpga itself is fully parallel, of course, and can support as devices as I wish without impact on the others. Ultimately, the bottleneck will be the 3.6 microsecond memory cycle of the 1130 and the interrupt intensive nature of some of the IO devices used with the system. If each instruction requires, on average 15 to 20 microseconds, then the code paths through the interrupt routines as well as the XIO instructions themselves will be a major limiter on system bandwidth.

The cycle stealing peak rate might be 277K words per second, but real life activity is going to be down in the thousands to tens of thousands of words per second. If we do an IO every 100 instructions, that is one word per 1.5 to 2 milliseconds, thus less than a thousand words per sec. As long as my PC program and the USB link can do at least 5000 transactions per second, it should be able to keep up with the IO activity. 

Console Printer (1053) improved again, working on SAC Box functionality

1053 CONSOLE PRINTER RESTORATION

I made an adjustment for the index operational magnet pull link and then fired up the diagnostics again. Things are much better today. The index (line feed) works well and the episodes of missing blocks of text are gone as well. Here is what remains to resolve:

• Tab doesn't reliably fire by push button on the front of the printer
• Tab doesn't fire by program command
• Escapement is still slightly erratic - sometimes skips an extra space
• Carrier Return force not yet validated
• Red/Black ribbon color nylon tape not repaired or installed
• Cover not installed and typewriter not returned to its normal spot on 1131

Never any miss-selection of characters, so that entire part of the machine is flawless. I suspect residual lubricant is causing the escapement defects - this will improve with more operational time. The tab issue appears to be a missing rear spring on the tab interposer (again). CR is likely an adjustment although it is fairly close and almost always works properly now. 

1442 CARD READER/PUNCH RESTORATION

I am investigating the possibility that I can re-install the punch unit with the broken wheel, on the hope that if I don't punch on the reader it will not try to rotate the wheel. If it leaves the wheel where I position it, with an unbroken arc of the wheel touching the cards, then I should be able to operate this as a 1442 reader.

Another possibility I am investigating is whether this can be used in conjunction with my virtual 1442 adapter logic. It would be necessary to switch the 1442 adapter on and off - through a toggle switch I could install - so that my interface box can respond to area code 2. I also need a means of switching my SAC box off so it ignores area code 2 while the 1442 itself is being used. This way, I could virtually punch as well as read cards on the PC, but also read real decks on the 1442.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I completed (but have not yet tested) the 1053 mirroring device support on both sides of the SAC box, so that I can create and fill a file on the PC with the characters as typed by the console printer. I am now developing the mirror 1132 printer code on the PC to allow it to create and fill a file on the PC with the lines as they are printing on my real 1132 printer.

This evening I finished up the 1132 mirror code on the PC and made a few tweaks on the fpga side to suite the way it will work. Later I began on the 1442 fpga logic for a virtual 1442 reader and punch, for when I switch off the real device's adapter hardware in the 1131. I have to work out a way to control when my box responds to area code 2 and when the 1131 will handle the device. 

Major work SAC Interface Box device support, plus working on 1053 console printer

1053 CONSOLE PRINTER RESTORATION

I went out first thing this morning and fired up the typewriter/keyboard diagnostics again. The occurrence of drop-out intervals, where the solenoids fire but the print cycle doesn't trigger, are fewer today. This appears to be more dried lubricant working its way out from inside pivots and other spots I can't easily clean or flush.

As of this morning, what isn't working properly:

• tab no longer triggers under program control
• index doesn't trigger under program control
• carrier return sluggish, sporadically doesn't unlatch fully
• once in a blue moon, CR will skip past left margin
• ribbon color nylon tape still not repaired/installed

I will go adjust the tab and index operational magnet trip links to fix the top two problems. I still haven't measured the force of the CR operation but that and corresponding adjustments are upcoming. Since some of the symptoms are still indicative of lingering lubricant issues, they may go away completely after substantial further exercising of the mechanism.

The nylon tape that shifts ribbon color tore off its right hand hook - unfortunately the hook is lost as well. Once I find a suitable replacement hook, I will use an adhesive to replace the hook on the end of the tape and install it once again. I put in a half hour scouring the workshop for signs of the missing hook end - but alternatively for a shorter tape I received in error that should still have good hooks on the ends! Of course, I couldn't find either during my lunch hour so maybe this evening I will get lucky. 

The hunt was finally successful tonight. It did prompt me to do a bit of cleanup while searching. I now have the intact tape that is too short for this typewriter and my correct length with the broken end. Having the proper parts, now I just need to use the right adhesive to remake a loop into which the hook will fit. The original process looks like it might have been a heat fusing process, based on the dimple I see, but that could also be pressure during the adhesive setting time.

Good end of my tape on right and good spare on left

My tape on right has torn loop and lost the hook, which you can see on good spare to left

I am playing with the adjustment for the index operational magnet pull link - in order to get the index (line feed) working well. I found that the damned spring popped off the back of the tab interposer, which is why tab is not working any more. I will find a better spring and fit it onto the interposer - sigh - in another tedious task with insanely limited access.

I can see evidence of old lube coming out of the mechanism, so there is hope that I can keep exercising this until it becomes rock solid.

Lubricant coming out as machine is used

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I removed the jumpers on my power-up relay in the SAC Interface Box. This relay is engaged when main 1130 system power is on, through a low voltage AC line coming over the cables, and in turn powers on my circuitry in the box.

The fpga auto-loads its bitstream and initializes when power is turned on. I found that the timing is a bit slow, so that the 1131 comes out of its power-on reset with quite a few interrupts triggered spuriously. I can deal with that by powering up in SS mode, then doing a Reset before switching the processor to normal Run mode.

My changes to mirror the 1053 console printer, the 1131 keyboard, the 1131 console bit switches and the 1132 printer are now included in the SAC box. I have to whip up the appropriate code on the PC side so that whenever I open a file as a mirror of the device, the code polls and extracts the data and status information it needs to faithfully recreate in the file what the operator sees on the real device.

I am still thinking about how to deal with the 1442 reader/punch that I have. If I can't get it operational in the near term, I could create a virtual 1442 device in the SAC box. The only unique requirement is that I need to find and block the area code or XIO signals getting to the IO adapter logic in the 1131. If the adapter doesn't see the XIOs or doesn't see its address, it will not respond and I can safely do so with my box.

I did some investigation of the logic pages to see what is the cleanest way I might disable the 1442 adapter logic to allow my box to take over. There is one source, gate A compartment C1 card F3 pin D06, which I can jumper to ground (pin D08 of the same card). This will cause the IO adapter to ignore any XIO targeting its area code of 2 and therefore it will be disabled.

A virtual 1442 reader should look similar to the virtual 2501, although the punch side will add some complexity. On the other hand, the 1442 does not use cycle steal, instead interrupting the processor for each column which requires the software to issue 80 separate reads or writes. I have to plan out the fpga side of the virtual 1442 reader and punch logic. This will take a few days.

Meanwhile, I began to write the first mirror code in Python for the PC side. This will mirror what is typed on the 1053 Console Printer. At this time, I am ignoring what is typed on the keyboard, looking only for XIO Write commands which are the codes to drive the selectric mechanism. I built a dictionary of all the valid codes for the printer and the corresponding ascii character that would be typed.

There is no cent sign or 'not' symbol on the PC, without going to unicode or other complex encoding, so I simply substituted '^' and '~' for them. The control codes for new line, form feed, tab, and backspace are translated to their ASCII equivalents /n, /f, /t, and /b while the space is obvious. Two control commands, shift to red ribbon and shift to black ribbon, will instead stick a null in the file. I need a better substitution. 

Worked on 1053 a bit, mostly extended logic in SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

Another ultra hot day, even with the air conditioner unit trying its best. I adjusted a linkage that trips the cycle clutch and saw one part that should snap back by spring action but seemed to stick. That part got flushed with fresh oil and exercised. Once it is cool enough to power up, I will try things once again.

By 8PM it had dropped to 75F and with a bit of AC I could do some testing. Having made a slight adjustment to the trip link and relubricated the one part I saw sticking, I was curious to see how it will have affected the typewriters's behavior.

I ran the diagnostic on several tests - upper case side, lower case side, then some worst case patterns for tilt or rotate selections - and was pretty pleased. There are still intervals where I can see the solenoid levers dancing but the cycle clutch doesn't cause a print cycle - as before, these are fairly long sequences where it fails to type, not interspersed individual failures amid good strikes. My work so far has created quite an improvement, with fewer dropout intervals.

1053 output on sheet at left, reference strings in book on right

You can see the page where the the 1053 was typing tests, with the reference output from the diagnostics MDM next to it for comparison. You will see long sequences where every character is typed, no mis-selection and it is running flat out at full 15+ characters per second typing rate. You can also see points where it stopped typing for a while and then picked up at another place. Thus, it is still alternating between long sequences of typing and other shorter sequences of missed print cycles.

I used my flashlight to look to see if anything was noticeable during the non-print intervals, but I didn't see anything clear. Tomorrow I will work on the trip link length a bit more and see if that resolves the issues.


SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent time overnight building up a mirror version of the 1132, such that the fpga will mirror everything that occurs on the printer. If the PC program wants to copy this into a file, it can issue poll commands, see the printer activity and build up a file that represents the printed output. I will also build a mirror version of the 1053 console, keyboard and console bit switches, all useful for logging what happens during a session.

In writing the logic, I realized that I didn't need new versions of most of the modules for handling XIO, because they could shadow the state of the real IO adapter with no harm. It is only for the cases where the real IO adapter is outputting new data - for example in an XIO Read, where I have the special version that sees what the real adapter writes into core as it appears in the B register late in the E3 stage of the instruction.

Sense DSW is the other function that needs a special mirror version to snapshot the B register after the real adapter has emitted its status word. This works because I will see the status word reflected in the B register, even though the machine is not taking a storage cycle reading and then rewriting memory. The data is still gated into B from the IO adapter.

The cycle steal fetch and store must be changed as they cannot actually request a cycle steal, nor should they be setting the memory address or inbound data. Instead, they should snag the contents of the B register at the appropriate time when it contains whatever the device has written or read during the steal.

XIO Init Read, XIO Init Write, XIO Sense ILSW and XIO Control don't write into memory, instead the processor does all the fetches and simply presents them on the B register for the adapter to grab them. Thus, I can use the same logic to grab the appropriate values for mirroring.

For the printer, I need to save the emitter data (character coming up to print), the last XIO, the sense bits, and track the state to know when to watch cycle steals and other status. It appears that I will need new transaction types where the PC program can fetch the extracted eight words of the printer scan field in order to virtually fire the hammers and see other mirrored status.

I also have to determine why my 2501 code keeps updating the DSW status when it is not ready. Once I figure out what would work properly, I can reactivate the remainder of the virtual card reader logic.

1131 repaired, SAC Interface box working, testing 1053 console printer

It is forecast to soar to almost 100 F today and is already reaching temps in the workspace where I want to limit the duration of power to the 1130 system. Just when I fixed the processor problem and am ready to dive into SAC Interface Box testing and typewriter verification, the environmental conditions block me from the work.

I found a special at Frys on a 14000 BTU portable AC, bought it and will figure out installation into my workshop so that I can begin cooling this afternoon and resume work. Once again I run into a situation of extremely limited inconvenient access just to get the dryer exhaust hose on its fitting now that it is taped to the AC exhaust line. Once done, I fired it up along with the other 8000 BTU portable and had them begin cooling down the workspace. It got tolerable inside with an outside temp of 95F, although when I fire up the 1130 the temps begin to climb back up from its 4500 BTU heat output.

1053 CONSOLE PRINTER RESTORATION

I fired up the diagnostic and could see that the times when the typewriter is not actually typing characters, the solenoids are visibly firing away with tilt and rotate codes. This means that my problem is in the triggering of a print cycle, an adjustment I should be able to make.

I looked into the adjustments necessary to get a good trigger of a print cycle - these involve the latch trigger and trip lever assembly that should release the clutch latch for every activation of the selection magnets. Before I adjust these, though, I need to monitor the feedback signal from the typewriter back to the IO adapter logic in the 1131.

If the adapter is firing the print solenoids far too early in a cycle, the clutch isn't yet ready to be released. However, this would be very early indeed since the design of the typewriter is to allow to take another rotation of the cycle if the next character was requested, not having to wait for the cycle clutch latch to stop first.

This makes the more likely issue something in the cycle clutch mechanism or the adjustment of the trip lever. If I have sludgy lubricant here, that may cause the periods of missed cycles I am observing. It is not evenly spaced among characters, which you might expect if the trip lever was borderline. Instead, it will fire off a string of characters and then sit while another string selects but doesn't take print cycles. The problem has to be something that sticks the machine in a 'no print cycle' mode for bursts of time.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

In thinking about the task of tracking the lines being printed on the 1132 printer, I was faced with the challenge that I couldn't tell what address a cycle steal operation is requesting, nor the device making the request. With either of those facts I could sort out what the eight printer hammer firing words are for each character, but it was ambiguous otherwise.

What I will see is an interrupt on level 1, followed by an XIO Read whose data word is the next character on the print wheel. The software takes that, figures out what columns of the print line should have that character printed, and sets up eight words beginning at location 0x0100. The printer will fetch the eight words, set up the hammer circuitry and then fire as the wheel reaches the proper point.

If there was no disk drive, the eight cycle steal operations would be for locations 0x0100, 0x0101 etc and I could just watch as the printer picked up its list of hammers to fire. I can tell for sure that we are in a cycle steal operation because the X0 clock goes on at the start and I can tell it is not for me because CS Level 1, assigned to the SAC Interface, is not active. However, it could be either CS Level 0 or CS Level 2.

Further, if neither Interrupt Level 0 nor Interrupt Level 1 is activated, then I can tell that we are in a CS Level 2 which is for the 1132 printer. The problem arises because the way I tell CS Level 2 is active also raises in IL0 or IL1 is active. Thus, if a disk sector is ready to send or receive words for an IO operation right at the time that IL0 or IL1 is active, I will be blind to which device is doing the cycle steal.

I could fetch the eight words as soon as I saw eight fetches by another device - if it was the printer, I will get the hammer order words and can mimic the print line results. If disk access is underway at this time, I will be fooled and pick up invalid hammer order words. Without a new signal line from the 1131 to the SAC box, carrying the state of CS Level 2, I can't definitively snoop on cycle steal fetches.

Rather than string a new twisted pair from the 1130, I could find a way to check the address of the cycle steal. Assuming I can snoop on the address bus from my interface box side, I could watch for the eight special addresses 0x0100 through 0x0107 and raise a signal for a match in that range. Any address in that range during a cycle steal is certain to be for CS Level 2 and the 1132 printer.

This is predicated on the exact circuitry used for the Channel Address In lines from SAC box to 1131. If these are simple wired-or junctions as is common in the machine, then I could watch the level of my open collector driver outputs and see if they drop to zero, meaning another device has put up an address for cycle steal. If there is a buffer in the way, it will block my visibility of the other drivers of the Channel Address In bus.

After reviewing the ALDs, I found my proposed method won't work. The input bits for the channel address are gated with a Chan Add Write signal in an AND gate before they contribute to the wired-OR memory address bus. Any logic to spot addresses from 0x0100 to 0x0107 would need to be done locally inside the 1131 and still requires that a signal line be added to the cabling.

Another idea I am evaluating is the possibility that I just assume the disk is not causing the cycle steals - that I trigger on the XIO read for a character from the printer emitter wheel and then snag the next eight cycle steal results while Inh CS Req is on, under the assumption that it is the proper words.

The result of picking off the wrong words as hammer firing bits is that my copy of the print line will be mangled on any print line in which a disk sector is read or written during IL0 or IL1 processing and at the time I am looking for the printer CS accesses. This should be infrequent enough to be tolerable, with the PC file containing a good copy of the printout other than rare lines with garbage characters in the line. Thus, I will NOT be adding the CS Level 2 signal or the CS address match logic as of yet.

Something is wrong with my updated Python program, resulting in a hang on the USB link. I did some debugging once the workshop got cool enough. There is something awry in how I moved the virtual 2501 card reader logic over to the new threaded parallel approach, but I could bypass it for now. I found another problem with the threads stepping on each other and fixed that.

The box loaded memory just fine in its new parallel process, which I used to run the 1053 diagnostic.
I will continue with development of mirror devices, testing of the virtual 2501, creation of the virtual 1403 printer and other items I plan for the interface box.

1131 PROCESSOR REPAIR

Yesterday I was working on the assumption that continuity was broken due to my resistor panel wiring, since one of the lamps (Disk Unlock) on the left side of the main panel was lit. Most of the lamps were wired to the +12V supply which also provided power for the console buttons and switches.

However, it turns out that this one lamp is powered separately from the disk drive circuitry and using a different voltage. Checking voltage to the lamps and switches quickly showed that +12V was missing. When I looked at the power supply, its fuse was blown. A quick trip to Frys netted me the replacement fuse which I installed. The processor now works properly. 

Developing 'mirror' devices for the SAC Interface box; figuring out problem in the 1131 resistor panel

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I realized that I could support a third kind of peripheral on the box - mirror devices - in addition to virtual devices on a PC or real devices that use this box for their adapter logic. A shadow device creates a PC file that should mirror the input or output of a real device whose adapter is inside the 1131. That means I could mirror the 1053 console typewriter, the keyboard, the console data entry switches, the 1442 card reader, the 1442 card punch and the 1132 line printer.

The idea behind the mirror device is that I would pick off key data from the IO operations while the SLT device adapter in the 1131 does the real handling of the peripheral. I worked out a way to mirror sufficiently to copy the stream as the peripheral would produce it - the character typed on a keyboard or the line printed by a printer or whatever makes sense for the peripheral.

For example, when software types a character on the console printer, it issues an XIO Write instruction. I will see the XIO instructions and the area codes (device addresses) and can follow along with what the real adapter is doing. At the time the processor gets to the E3, time T4, of the XIO Write, the character to be emitted is present on the B register which I can see.

The obviously easy tracking situations are writing a character with XIO Write, because the memory word sent to the device is avialable on the B register, XIO Control operations for similar reasons, and the XIO Init Read/Init Write commands which present the WCA data address in the E3 stage.

More challenging are XIO Read, cycle stealing by the device, and XIO Sense DSW, because the device adapter presents the bits on the incoming data register, which I can't sense, I can only drive them. For XIO Read, I will see the new value in the B register late in the E3 stage, after the inbound data is gated in. For cycle stealing, I can watch CS accesses and capture the B register late in the cycle after it has been updated by a read or as it was fetched for a write. For XIO Sense DSW, I can see the updated B register late in the E3 cycle.

Remaining is the problem of discovering what device is using the cycle steal - the device adapter requests a cycle, provides a memory address and then either snags the resultant core location or provides the replacement data word. Since I can't see the memory address just the replacement data word, this is a hard problem.

If only one peripheral using cycle steal were active at a time, I would know that any cycle steal could only be on behalf of the mirrored peripheral. Unfortunately, my system has two peripherals whose adapters in the 1131 use cycle steal - the internal disk drive and the 1132 printer.

The disk drive transfers data words to or from disk using cycle steal. I simply need to save the WCA from the XIO Init read/write command then capture the data coming in from the cycle steal operations. I could force cycle steal reads of the WCA to retrieve the data being read or written, after the device has done its cycle steals to move the data from disk.

The 1132 printer fetches data words beginning at address 0x0100 and uses them to fire hammers based on which bits are set to 1 in the words. This happens after the printer interrupts on IL0, the software issues an XIO Read to get the particular character which is ready for printing across the 120 print wheels, then the software sets up the words starting at 0x0100 with bits for each column where this particular character should be printed. I could capture the data words as they are retrieved by the printer in order to populate the print line columns with this character.

The challenge comes for the case where both the printer and the disk are currently active - the printer started with an XIO to start printing via the interrupts for each ready character, and the disk drive started with an XIO Initiate Read/Write operation. Depending up on mechanical movement factors, the two devices could request their cycle steals independently of the other and perhaps interleaved. The SAC Interface has no indication for which device is making the cycle steal request.

The disk uses CS level 0, my box uses CS level 1  and the printer uses CS level 2. I can see if we are in CS Level 1, the one I requested. I can see if we are in clock states X0 - X6, which indicates a cycle steal operation, thus if this happens when we are not in CS Level 1 then it is a steal for level 0 or 2. I have no available signal telling me if those other states are active.

However, I do have a hint - a signal called Inhibit CS Request - which tells me if any of the following are true:

• the 1442 is presenting an interrupt request on Int Level 0
• the 1132 is presenting an interrupt request on Int Level 1
• we are currently running in Int Level 0
• we are currently running in Int Level 1
• a request exists for a cycle steal on CS level 2 (printer)
• a request exists for a cycle steal on CS level 3 (unused on my machine)

Based on the hints from Inh CS Req and other signals, it is barely possible to figure out which cycle steal is underway. I know the following:

• If the 1132 is presenting a request on IL1, it is to report the next character value ready for printing. Thus, when this is active, the printer would not be fetching words to fire hammers. 
• If IL0 is requested for the 1442, which doesn't use cycle steal, then I should see IL0 go active at the end of the current instruction since it is the highest level other than cycle stealing
• If a CS request for levels 2 or 3 occurs, they will get a cs cycle at the end of the current instruction unless levels 0 or 1 are active.
• If we see the X clock at any step other than X7, we are currently in a cycle steal 
• if we requested a CS on level 1 and separately, if it is active
• if we are in CS level 0 and the printer wants cycles, it will have Inh CS Req active
• if we enter a CS request cycle, but Inh CS Req is not active and we are not asking for level 1, then it is a CS level 0 activity
• if we are asking for or actively operating in interrupt levels 0 or 1, then CS Inh Req is active whether or not CS level 2 request is active
• If neither IL0 nor IL1 go active at the end of an instruction while CS Inh Req is active, then it was caused by CS Level 2 req (printer cycle steal). 

This means I have ambiguity during the times that IL0 or IL1 are active - I could not track who commanded the current cycle steal operation in that case because my view of the CS level 2 request was hidden by the interrupt stuff. This becomes a problem when I have an XIO Init outstanding for the internal disk and also have the 1132 actively printing a line. 

Unless I figure out something iron-clad, there is no way I can mirror the 1132 or the internal disk drive unless I add some lines from the machine that let me know definitively when a cycle steal operation is underway and what level is active. I have tight limits on fpga IO pins, so this I am not sure I will do this. 

It isn't likely I would want to mirror the internal disk, but I can see the value in mirroring the line printer to keep a PC copy of what was printed. I can't do this reliably unless I can differentiate between CS Level 2 cycle steal operations and steals by the disk drive. Perhaps I can take one of the existing IO pins of the fpga and repurpose it to sense the CS Level 2 state. 

A good candidate is the Meter Out signal, which is part of the standard SAC Interface, but is only important if you want usage meters to roll only while the system is active. Since I am not billing anyone by usage, that is unnecessary. I can take over the fpga pin and use it for the new level, but I still need to sort out how to add the wiring between the interface box and the 1131. 

1131 PROCESSOR REPAIR

The system is current staying in reset mode and when it wasn't, had difficulties loading the IAR or memory from the console data switches and perhaps was having an issue with peripheral operation. This has to be diagnosed and repaired before I can continue with the 1053 or most SAC Interface Box work.

Everything looked good down under, but something is wrong. I decided to remove the plate in front of the resistor panel allowing me to enter from the front, a much easier task than the narrow tunnel I had to use before. The resistor panel wiring looked fine.

I moved on to checking the power on the terminals while the machine was on. What I found was that the common line to all the buttons and switches, which should be energized with +12V power, was floating near ground. That would definitely cause the symptoms I saw. It is still 86F at 7PM tonight, which means I am not going to do much powering of the system. The most I can do tonight is check wiring harnesses and connections, as well as circuit breakers, to see if there are obvious errors.

The +12V comes from the power supply to the lamps on the left side of the main console plate, then over to the common leads of the buttons and switches on the right, by way of the CE switch panel hidden under the top cover near the usage meter. I see continuity among all the devices and one of the lamps along the left side is lit, so we have +12V on the line.

However, I don't see the +12V coming in from any of the switches. Something is wrong in the wiring down by the resistor panel. The wires coming in from the switches where I have the vampire taps is the area I need to check. If a tap isn't working, then the switch can deliver the +12V signal but it never makes it up to my relays and back out to the 1131.

It is very difficult to get the screws loosened that hold the resistor panel in its inconvenient place, but if I can get them loose I can rotate the plate, see what I am doing and get good testing of all the connections. Tomorrow, I will get this done and figure out what is wrong. 

Improved PC side program for SAC Interface box, 1130 not working

1053 CONSOLE PRINTER RESTORATION

I have to figure out why the keyboard/console printer diagnostic, when mirroring keyboard presses, does not cause a line feed when I push the 0-8-2 key (shifted or numeric version of T). My analysis of the wiring indicates that the character must be read properly, thus this is a problem in the diagnostic program or typewriter.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

The Python program on the PC side of the SAC link needs improvement to allow it to handle multiple virtual peripherals simultaneously. My design for this is to use multithreading - one thread per virtual device handler, plus a thread that manages communications on the USB link.

Any thread can request a transaction, which gets the lock to add its work to a queue and then waits on a semaphore. When the USB link thread has completed the interaction, it releases the semaphore to permit the device handler thread to continue executing. A queue entry has the request bytes, the address to store the response bytes, and the semaphore address for when it completes.

In addition to the virtual device handler threads, there is a machine status thread that periodically requests the state of various registers in the 1130 in order to display them for the user of the Python app. Too, I have to accommodate the thread that loads core from a file, because this also talks over the USB link.

With all the code changed and preliminary tests, the box is ready for more comprehensive testing. When I used it to monitor the 1130 status lines, I verified that the machine will not come out of reset, which matches the symptoms I was experiencing. I am expecting it is the fragile wiring deep inside the 1130 where the logic gates swung in close to the resistor panel. I pulled them out to inspect.

No issue I can see, but the machine is still stuck in reset. I will need to troubleshoot this issue, which might be a coincidental failure of a component in the 1130 but is more likely to be a problem I caused by manipulating the resistor panel.

KEYBOARD RESTORATION

If the 0-8-2 key (shifted T) is not working, you can deduce the contact(s) that are likely oxidized and not working. For example, the T key prints but in numeric mode, the 0-8-2 didn't cause a line feed. My deductions for this symptom are as follows:

• The output of the keystem for row 0 is produced by bail 14 regardless of the state of the shift (numeric) key. Since the T is recognized, that works. 
• Bail 5 emits row 3 only when shift is not activated and that works since T prints. 
• Bail 8 generates row 8 when the shift is active, doing so for many characters which work well so bail 8 is fine. 
• The remaining contact, latch 20, causes row 2 to be emitted when shift is active, but only for this keystem. Thus, if there is a problem, this would be the cause as this is unique to 0-8-2
• If row 2 were dropped, the key stem would produce 0-8 while in numeric mode, a value Y character but that didn't print. Lack of a printed Y says that latch 20 is not bad
• I have to conclude that 0-8-2 is being read properly by the diagnostic but not triggering the index operation (line feed), which is not a keyboard problem

Progress on 1053, keyboard and SAC Interface box, albeit measurable in microinches not normal strides

1053 CONSOLE PRINTER RESTORATION

With the diagnostics back in the machine and running, I put the machine through its paces. I found that the carrier return interposer would sometimes fail to relatch - the same goop that was impacting the relatch of the index interposer yesterday. Many of these things work out okay with repeated operation of the mechanism.

Most operations and all the typeball characters were working well, but I had some challenges with the diagnostic program - I am still not fully in control of how to work its many options - so I am not positive yet. The sections of tests it printed seemed to be okay, but between extra skipping with the CR issue and shaky control over the diagnostics, not everything was working. It seemed that some sequences of typing were ending prematurely, as if spurious signals were confusing the IO adapter.

When I got back out at the end of my lunch hour, I fired it up to set it to specific routines - one tests with tab and CR sequences, another tests with backspace and index sequences, the registration test will type O and * using space and backspace so that each location should have the same circle with a star inside. It would identify any failure to smoothly space and backspace.

Alas, somehow the machine won't honor the Load IAR button, so I can't start the machine at the appropriate location even though core is properly loaded. This problem cropped up out of the blue. Until I sort out what is wrong with the 1131, no point trying to run diagnostics to work on the 1053 or keyboard.

I was able to load into location 0 and 1 a branch to the starting address 0220 and run the diagnostic. The load IAR button works when the B register contents are non-zero, although it forces the IAR to the B reg contents plus bit 5 for some reason. I suspect a hot bit from the interface box, since the console printer is typing some but not all characters it should. That is, it sits idle then resumes with another portion of the string, almost as if something is stepping on its operation.

I confirmed that the index operation (line feed without carrier return) is working under program control. Hopefully I will get a full thumbs up from the diagnostics when I clear up my basic machine problems.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Crawled back under and inside the 1131 to continue fighting the wiring at the resistor panel - one pin to insert in the panel and one vampire tap to repair. Sounds simple, but extremely limited and awkward access make this harder than it would seem.

By lunchtime I had things sorted out down under and working properly - although I still had to test the virtual Program Load to make sure all connections are right. I was able to load core memory and run things in the machine, which was good enough for now.

Later in the afternoon, I went out and ran through the virtual Prog Load function a few times - it works just fine. Once I can figure out what is plaguing the system, stopping Load IAR from the console bit switches and probably interfering with the typewriter data flow, I can continue.

I happened to put a VOM on the VCC pins of the driver chips and found one of the two boards at 3.3V - not 5V as they both should be. These are 74LS06N chips and should have the higher supply voltage. I am aghast. This certainly could explain the erratic behavior I saw occasionally. I replaced the supply with the proper voltage.

I also chose to swing the two logic gates (A and B) closed and shut the machine, thinking that I was done with the hell of the resistor panel, but apparently something went wrong from the tiny movement of the wires while closing. The machine sits in permanent reset state. Either the Reset wire pin popped out of the resistor panel or the vampire tape for Reset came loose.

KEYBOARD RESTORATION

My burnishing has helped quite a bit. I was able to validate that most of the malfunctioning keys are now sensed correctly. S and most special characters that were failing now come up correctly. Alas, the cent sign is still not working, which might be oxidation on the latch on its keystem. Also, the 0-8-2 key should trigger a line feed but doesn't seem to work. I will need to do more checking to see what is happening here.

With a bit more usage, the cent sign (shifted R key) is registering properly. Only the 0-8-2 key stubbornly refuses to be read as a request for a line feed from the diagnostic. Time to study the keyboard wiring diagram to figure out what latch and bail contacts are involved in this - then of course any bails that work properly for other keys can be excluded. What remains, probably the latch under the key (0-8-2 is shifted T) is the culprit. It works fine except for that one character. 

Still fighting wiring on resistor panel, fixed keyboard/console switch, tuned up 1053 console printer

1053 CONSOLE PRINTER RESTORATION

With the Keyboard/Console switch resistor soldered back to its pin underneath on the resistor panel, I will be able to run the typewriter/console printer diagnostic and get past the portion where I enter characters to check that they are detected properly. To stop that first part of the test, the Keyboard/Console switch has to be switched to console mode.

I have had cases where the index function sticks on and performs multiple cycles. I traced this down to goo on the front latch that holds an interposer forward after it is restored. The end of a cycle pushes the interposer forward (restores it), where a spring loaded latch on the front end pivots and locks the interposer forward. The goo was keeping the latch from springing crisply into position. I worked it free and cleared up the problem with multiple line feed (index) cycles from one activation.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I crawled down into the frame, twisted on my back and sides, to solder on a length of stranded wire with an attached pin to the solid wires that keep snapping off at the pin. I remain under the black cloud that breaks one thing for each accomplishment - as I repaired the Imm Stop and Reset pins, one of the two Prog Start pins broke off.

Once the three had the stranded wire attached pins hooked up, I began inserting the pins. Imm Stop - worked well. Prog Start - the damned stranded wire broke right off as I was maneuvering the pin into position to push it into the resistor panel.

I left the Reset pin dangling along with the broken off standed wire and walked away for a while. I only have limited time today to work on the system and had been anticipating completion of these new pins before the workday started, but that won't happen now. Maybe in the early evening.

This evening I went back under and began to install entirely new pins with stranded wire, soldering them to the existing lines. I have three of the four pins inserted and their wires soldered. I was having great difficulty getting the Imm Stop pin (P1D) pushed into place. As well, yet another random setback - a wire connection from one of the vampire taps came suddenly loose. I tried to solder the wire directly to the old pin but that also failed. I had to walk away again.

KEYBOARD RESTORATION

The oxidized contacts I suspected are now cleaned and appear to work okay. The issues were:

• S/> key in alpha mode registered as a 0 due to latch 9 blocking the '2' row signal
• cent sign registering as : due to bail 12 blocking the '12' row signal
• + sign registering as = due to bail 12 blocking '12' row signal
• ( registering as '  due to bail 12 blocking '12' row signal
• | registering as " due to bail 12 blocking '12' row signal
• 0-8-2 key not registering, likely due to latch 27 blocking signals

Once I can fire up the system with the typewriter/keyboard diagnostic program, I will try all keys including my six incorrect cases from above. Tomorrow will tell. 

SAC Interface Box fits and starts; 1053 console printer and keyboard progress

1053 CONSOLE PRINTER AND KEYBOARD RESTORATION

I sawed off a very short segment of the 1/4" OD hollow tubing and tested it as the pivot rest for the typewriter pivot arm. It looks as if it will work out well, with some washers as spacers to keep the pivot arm (nearly) restricted to swinging in one plane.

1/4" OD tubing as pivot bearing surface, fitting into hole on pivot arm

I attached the pivot arm with my makeshift pivot screw assembly and checked its motion compared to the other intact pivot arm. All was good, about the same wobble out of plane as the other one, and about the same resistance to movement. I put on the spring to hold it into position and consider that task complete. It appears to be working exactly as it should.

I took some time to fine-tune the operational magnet linkages to ensure a good crisp engagement when the solenoid is activated. I ran the keyboard/typewriter diagnostics partially - I still have issues with the main Keyboard/Console switch as well as bail 12 and latch 9 oxides blocking correct recognition of certain keystrokes.

When I investigated, I found that the resistor from the keyboard/console switch had broken off its peg on the resistor panel, therefore the machine was always in Keyboard mode. I will have to solder it back on - while on my back deep inside the frame once again.

Keyboard/Console switch at upper right

That was done but as I replaced it, I found the red wire for my Imm Stop button connection had broken off the pin. I soldered the wire onto the pin, but as I was trying to push in that pin, I found that the Reset button wire snapped off its pin. Grrr.

This definitely needs stranded wire in the pins, as solid wire is too prone to break off. On the other end, where it has to fit into connectors on the relay board, stranded wire would be a pain to insert and prone to having stray wisps shorting. The story of my life - wires that need to be stranded on one end and solid on the other. Time to solder a stranded end on the solid wires, then put the pins on the stranded ends. I will get to this tomorrow or Thursday.

I was able to confirm backspace, space, tab and carrier return operation under program control. I tried to reload the diagnostics to try out the index (line feed) operation, but found that chip 3 of the driver board was inexplicably hot at all times - bits 6 - 11 set on because the chip was pulling those six lines down to zero. I will need to fix this before running the processor again.

I took the keyboard off its mount and began to work on bail 12 and latch 9 with the burnisher, cross checking the connection with a continuity tester. Since the 0-8-2 key isn't firing off a line feed, it is possible that latch 20 is also bad and I burnished it also while working on the keyboard. The keyboard and panel is reassembled, pending testing once I get the wires to the resistor panel shipshape.

Back of a set of bails

Side view of the bails with the contacts visible down the middle

Looking down at back of keyboard from the top - bail bars across bottom close bail contacts on sides

Underside of keyboard with one latch per keystem across the middle of the picture

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I checked continuity from pin C12 - for Interrupt Request Level 4 - and from B27 which outputs an additional copy of the signal value. Both were good. I have a voltmeter across B27 which should go high when Int L4 is requested.

B27 does not change, nor does C12. That would definitely seem to be an FPGA problem and the likely place would be in my logic, but I just can't see it. IL4 requests are exactly parallel to request for the other interrupt levels and should work properly if the others do.

These sorts of errors are frustrating and often inordinately difficult to resolve. I will be scrutinizing the reports from the synthesis, which are a challenge to review because of huge numbers of essentially irrelevant or benign errors that can't be excluded or isolate, thus hiding the wheat among the chaff or more appropriately, the needle in the haystack, assuming there is any wheat or needle there at all.

After sifting through everything, there are no messages at all that would explain why C12 and B27 are both stuck at level 0. I will temporarily reroute the signal to multiple free pins such as B29 and test for a good value there - if that works, but B27 and C12 don't, then I have bad IOs on the fpga and will relocate the int request line to a good pin.

Unfortunately, none of the new pins go hot when I request IL4, so the flaw is definitely inside the fpga instantiation of my logic. After staring for quite a while, I finally got it. IL4 requests are set if any of the twenty UCW entries (devices) have the corresponding bit set. My program on the PC was setting the bits as part of a transaction, but then when idle the fpga was overriding that with the logical state for the four implemented devices on IL4.

That is, the virtual 2501 reader, the paper tape reader/punch, the 1627 plotter and the virtual 1403 printer are UCW numbers 1 to 4 and their IL4 value is only set if the device adapter logic is requesting the interrupt. My PC transaction sets the bit and then it is reset a few dozen nanoseconds later to the state of the device adapter (off).

I changed my PC program to set the interrupts in UCW 10 - not currently implemented - which is not overriden by any device adapter logic. With that, I tested the interface and IL 4 triggered exactly as I wished. It is apparently impossible to move forward one step without a new problem arising to replace any resolved issue - now IL2 won't trigger.

During testing of the 1053, when trying to do another load of core with the diagnostics, I found that chip 3 of the driver board was inexplicably hot at all times - bits 6 - 11 set on because the chip was pulling those six lines down to zero. I will look to see if there is a failure mode in my PC program or fpga logic that could cause this, but the clean boundaries around driver chip 3 argues for a different issue, perhaps an intermittent ground connection to the chip.

SAC Interface Box still one signal failing, plus console printer and console switch issues

1053 CONSOLE PRINTER RESTORATION

I ran the KB/Console Printer diagnostics although I am not sure exactly how to control them. They start off in the keyboard mode, but it never switches out even though the documentation claims that it should end with the console/keyboard switch moved to console.

I did do work on the resistor panel when wiring in the emulation engine board and was very close to PR1A which is the connection for the console/keyboard switch to indicate it is in Console mode rather then Keyboard mode. If this is not working, it could cause the difficulty I am having with the diagnostic getting past the keyboard entry routine.

In the keyboard echo mode, I found a few keys that aren't producing the correct typed character, which is an issue with the microswitch contacts inside. S, +, (, the cent sign and the vertical bar are the few in error. The common failure with +, (, vertical bar and cent sign is that these are a combination of the 12 row plus other rows, but the 12 row is dropped. S on the other hand is a 0 and 2 row, but is dropping the 2 row.

Through examining the switching matrix in the keyboard, which consists of latches that are unique to each key stem plus bails that some number of key stems can activate when depressed, I figured out what two contacts are oxidized and not contacting reliably. Bail 12 is tasked with emitting a row 12 for any shifted (numeric side) character that requires it. That matches all the failed characters except for the problem with S. The key stem for S activates latch 9 which is only used to emit row 2 when the key is pressed in alpha mode. I will use my burnishing tool on them later.

I ran diagnostics a few more times and did discover that the console/keyboard switch is not operative, so that the machine believes it is always in keyboard mode. This blocks the diagnostic from moving on to other tests especially of the console printer. Task - repair this switch.

Since I still have the defect in the pivot arm for carrier return and index operations, I really need to attend to that before trying to run too many more diagnostics on the console printer. The 1/4" OD hollow tubing arrived, from which I will cut the bushing which the pivot arm will rotate around. Task - repair pivot arm.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I pulled the connectors dealing with the four interrupt requests off from the driver board and the fpga board, tested continuity and verified correct wiring, resistance and polarity for the outgoing lines. Everything looks good, so another power on test is in order, although I didn't actually change anything.

I have continuity from the fpga pin out to the chip input, but the value never goes on even when I request an interrupt on IL4. This may well be an fpga board issue, either a blown output pin or some error in the synthesis tool.

I will make a few changes to the logic and rebuild, so that if this is a random error it will move around. Otherwise, I have to consider pin D12 of the board to be unusable and copy the line over to another of the precious few IO pins left, B27.

I finally realized my documentation was out of date and pin D12 was feeding Int Req Level 5, working just fine. Int Req Level 4 is on pin C12, whose continuity I had not explicitly checked. Still, when I put a voltmeter on the wire to pin B27, it didn't rise to logic level 1 and this is a copy of my level 4 interrupt request so it should rise even if C12 does not.

I shut down for the night, but know what testing I need to do next - diagnose and repair the interrupt level 4 issue.

SAC Interface Box new driver connectors debugging, 2 signals left to resolve

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I traced signal wires to the fpga board and cross checked against my rewiring notes to see why I have the few swapped/misplaced signals. I did find a swap in one of the two connectors on chip 4 and replaced it.

I put together a core memory load file to test out the address lines from the SAC box - for each address bit, I used an address with only that bit on, and stored the same value in the core location. When I displayed what was loaded, most were correct but I found that two address bits, A11 and A12, were swapped. At location 0x0010 I found 0x0008 and correspondingly at location 0x0008 the box had stored 0x0010.

I can as easily swap the assignments in the fpga rather than rewire the connector for the two address lines, so that doesn't need any change. The remaining two issues I found were a problem with data bit 5 and with interrupt request for level 4. The problem could be on either side of the driver board - the lines from the fpga or the twisted pairs that run to the 1131.

After some tracing, I discovered that I had swapped a couple of ribbon cable lines in top connector for chip 2. I repaired it which should restore B5 to correct operation. I swapped the sense of the two address lines for address bits 11 and 12. Loading core worked properly, allowing me to load up the standalone disk utility program DCIP and have its startup message type out on the console printer.

I still have something wrong with interrupt level 4, the remaining issue as far as I can tell. I monitored the fpga input pin for the IL4 request and see it steadily at logic level 0 even when I believe I am requesting the interrupt. This tells me I have a problem in the wiring. When I looked closer at the chip 5 bottom connector, I saw the problem.

I rewired the connector but even with good conductivity to the input for IL4 on the chip, I wasn't getting the level to trigger. Too, level 2 now no longer triggers. There is still a connectivity challenge here, even though the memory loading is now solid as a rock. I swapped the IC just in case there was a problem with the component, but no change. More on this tomorrow.

Finished the new connectors for SAC Interface Box, tested and have a few minor issues to clean up

1053 CONSOLE PRINTER RESTORATION

xxx




SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I got out before breakfast and did a bit more work on the connections. There were three of the seven pairs still to solder in when I left the workshop. Later, after the morning meal, I did another pair, taking the usual 30 minutes, until my back spasmed up again from hunching over the box. At this point, I would need to steal another hour to finish up the final two pairs, before I could do any testing.

Before lunch I managed to wrest 30 minutes from my party preparations and as a result there is only one pair of connectors left to build. For each pair, there are 12 twisted pairs that run to the main SAC cable connector and six single wires from the fpga. These must be cut off the old board, stripped, have heat shrink tubing placed over one end, and be carefully soldered to the ribbon cable on the new connectors. The heat gun shrinking the tubing is the last step in the process.

Final pair soldered on just before lunch and the old board removed. Next up was soldering in the power and ground lines to the new boards, then plugging in all the connectors in their proper locations. With that it was ready to power up.

I had updated the fpga logic in the SAC box, which now inverts the interrupt level 0 and 1 request lines, so I had to install the inverter board inside the 1131 before I powered the system on. I was able to add it to the bracket that held the original driver daughter card then wire it in place.

As a power on test, I loaded core memory from a PC file to verify that things still worked properly - that checks out quite a few of the driver signals. Three driven signals are of no importance at this time - block channel advance, advance IO entry, and meter in - and there are interrupt requests for levels 2, 3, 4, and 5. I modified the Python program to cycle through the interrupt levels so that I could verify them.

I found that somehow I reversed the wiring of a few lines, or have bad connections. Bit 15 is always hot as a 1. Interrupt level 2 is always triggered. When I trigger what i think is IL2, it triggers level 3 instead. Level 4 trigger does nothing.

These symptoms mean that not much is wrong - I got 15 of the 16 data lines correct, cycle steal and channel write works, and the address lines are good for address of the form 0x01?? because I only looked at location 0x0100 and a couple dozen words afterwards but those locations were correct.

I could have up to seven channel address lines swapped, up to three interrupt request lines swapped, and of course my low order bit 15 for data is hot. Since chip 5 on one side has the low order bit (15), int req for L2 and int req for L3, I am almost certain to have a wiring issue in this connector that is causing some problems, but what is wrong isn't immediately obvious.

The lack of int req L4 hints at the connector for chip 4, which also has address bit 0 and IL5. Since IL5 works, I may have swapped the positions of IL4 and Address bit 0. This is not certain, because I can't see the result of A0 - it isn't really implemented as this machine is a 32K configuration.

This will require tracing fpga pins back to my chip inputs on the driver board, as well as verifying the color codes and sequencing from my working notes while I was moving wires around.

I ran out of time due to the party, so that ends my work for today.

Substituting new driver boards in SAC Interface Box to improve connection reliability

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I continued wiring up the new boards (30 circuit driver, 12 circuit driver, and inverter daughter card) during breaks and at lunchtime. By the end of my lunch time, the boards were out in the workshop and I was ready to begin detaching wires from the current driver board and hooking them to the new connectors. Once that is done, I can move the ICs over to the new boards, plug in the connectors, hook the board to power and be ready to rock and roll.

Larger of two new driver boards

Inverter daughter card 

The process of rewiring is more tedious than I expected. After 30 minutes, I had one set out of seven connector pairs wired. It is over 90F and hotter than that in the workshop. I turned on a portable air conditioner and might have it down to the low eighties, a bit warm but bearable.

At the end of the workday, I went out and began with the second pair. It was no faster, even with experience gained from the first one. At this rate, it will take more than three full hours to complete the transition to the new boards.

New driver board with connectors - much more reliable

After dinner, I had completed the third of seven sets and am sure I won't get this finished and the system powered up tonight. Tomorrow I am hosting a large party for my daughter and son-in-law on their first wedding anniversary, which will consume most of my time. I might sneak in a bit of work early in the day. 

SAC enhancement to push 1130 buttons working, reworking SAC driver board to eliminate the unreliable wire connections

1053 CONSOLE PRINTER RESTORATION

Once my button wiring modifications to the 1130 were working properly, I was ready to load the typewriter diagnostics and test out the 1053. Alas, the damned bit 12 went missing again, due to the ratty quality of the connections on my driver board. Fortunately, my new connectors arrived today, thus I swung into action updating the SAC box to use these new more reliable connections. I don't ever want to be stopped by erratic wire contacts again.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I spent a bit of time in the workshop in the early morning while it was cool, trying to sort out the wiring issue with the Prog Start key relays. The pair of relays are wired so they will flip or reverse the connections of the N/C and N/O connections from the Prog Start button. However, I have an open connection somewhere, either in one of the two vampire taps or in the pin insertion onto the resistor panel.

Relay circuit for the Prog Start button

I validated that my vampire taps are working for the two Prog Start lines, although when I measure the lines they have a 1K resistance in series with the +12V, unlike what I see in the machine schematic. Since there had been a local modification by the prior owner to wire additional Prog Start buttons on the peripherals right across the common and NC of the button, I may have to figure out what wiring really exists here before I continue.

An additional issue arose after I ensured I had solid connections to the two vampire taps - the machine is now in permanent Reset mode, which might be a poor tap on the third line. I will do some tracing of this at the same time as I sort out what is going on with the Prog Start button wiring. To do this, I will have to open and tilt up the keyboard/main control plate that holds the various buttons.

The wiring of the Prog Start button appears normal, thus I must have some other issue causing the problems I am facing. Sadly, the temperature is already up over 90 at lunchtime, meaning no more power-on work until late tonight. After it cooled, I came out and got everything straightened out.

I put the processor in a one instruction loop, then requested the Program Load function from the PC program. I watched the processor stop, reset, wait long enough for me to have stuffed in eighty words of instructions into core, then started executing at 0x0000.

I decided to add another daughter card with a hex inverter chip, since the current design will trigger interrupts on levels 0 and 1 if the SAC Interface box is disconnected or unpowered. With inverted logic for those inputs, the behavior will be more appropriate. I began wiring that up with quick trips into the workshop-oven.

I also decided after looking at the existing driver board in the SAC Interface Box, that I wanted to build a new board with the solid connectors, rather than wrestle desoldering and cleaning up the existing board. The connectors I chose will give me 30 driven signals per board, so I need a second but smaller board to support another 12 - I get six signals per chip and comfortable room for just five chips on a board using the new connectors.

Since I used IC sockets, I won't have to repurchase the seven DIP chips, just move them over once I solder up the new sockets and connectors on the new board. When the board is done, I need to relocate all the input and output wires from the old board to the ribbon cables hung off the new female connectors. These can then plug into the males on the new board I just built.

I think it will take me into the weekend before this replacement is done, when I can get back to the 1053 debugging with its diagnostics, then run the 1132 printer diagnostics, and return to the virtual or real devices such as the 2501 card reader and paper tape reader/punch devices. 

Debugging the 1130 button activation by SAC Interface Box enhancement

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I had to finish wiring in my changes to the resistor panel deep inside the 1131 to allow my relay board to 'push' the three buttons on the 1130 console, in order to power up and use the system. I anticipated one final 20 minute session on my back inside the frame. In fact, it took a tad less than the allotted time, in part because it is cool this early in the morning.

Relay board wired in place

I powered up the system to verify that the console buttons work as they should, but believe I have some problems with one of my vampire taps. The Reset button works as it should, which is good because my wiring was inserted in series with the switch so loss of continuity would keep the machine in perpetual reset mode.

However, the Prog Start button is not working. Since that is how I will start some code executing, I also couldn't test the Imm Stop button, since I need the machine running in order to verify that it stops. A few minutes after I shut down, I thought of a test I could do that would put the machine into a loop right after it comes out of reset. With my SAC box powered down, interrupt levels 0 and 1 are hot, allowing me to set the interrupt vectors for those instructions to a dummy routine that loops to itself.

I couldn't use the Load mode to set up the interrupt vectors, since this depends on the Prog Start button. I might have been able to load core through the SAC interface box, but it was time to head over to the Computer History Museum for lunch with the 1401 restoration team.

Given the high temperatures today, I wouldn't be able to power up the system for testing until late in the evening. I did a bit of work checking the wiring of the buttons just using a VOM and continuity tests.

Finished all wiring for SAC Interface Box enhancement, ran console printer diagnostics fully

1053 CONSOLE PRINTER RESTORATION

Testing of the printer had to wait for my SAC Interface box to be able to load core memory correctly with the diagnostic and for the temperatures in my workspace to drop to a reasonable level. It was nowhere near cool enough at 7PM, but I held out a slim hope that it would cool quickly allowing me to test tonight.

I finally gave up, deferring the testing until another day.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I put the VOM on the driver chip and it appeared that the data bit 12 signal was varying, which should have latched it into core properly. I can't find any short or open inside the SAC box, thus I will have to cast my net wider.

I did a continuity test to the pin where the bit 12 signal arrives in the 1131, out to the pin on the driver board in my box. If no continuity was found, I would have a break in the cabling somehow, perhaps at the huge connector for the SAC Interface cable. Fortunately, I did have a good connection and found a teeny wisp that was shorting the signal (I think).

It soared to 98 degrees F, thus I won't apply power to the system until the cooler evening time. Until then power on test, I wouldn't be certain whether the fix works and that I have bit 12 properly being set. In the meantime, I can finish the task of wiring up the SAC enhancement to the 1130 console buttons for Imm Stop, Reset and Prog Start, which I push by program control to simulate a Program Load operation.

I made up a cable after carefully planning the connection means and approach. I put on four pins which fit into the resistor panel underneath and inside the machine, for four wires going up to the relay board. In addition, I have three wires that will be vampire tapped onto the existing wires with pins that fit into the panel.

bundle of wires for button relay, four pins for insertion and three 'vampire taps'

By vampire tapping, I mean I will remove a bit of insulation on the wire up a bit from the pin, wrap my new wire around the conductor, solder, and insulate with heat shrink tubing. As well, I will cover the pins of those tapped wires with heat shrink tubing, since those pins will hang loose, unconnected except by my tapped wires to the relay board.

By the end of my lunch hour, I had the cable made up, the pins installed and it attached to the relay board. Due to heat, I had to take a break before pulling and inserting pins, making vampire taps and securing the heat shrink tubing with a hot air gun.

A task like pulling and installing pins would be dead easy if the panel were directly in front of me, not wedged up in a dark corner of the 1130 frame with blocked visibility and access. I have to contort on the floor, with my body partially inside the frame, just to make the attempt. Also, the wire covering on the existing wires is quite strong and not easily stripped loose for the vampire tap.

I managed to pull the first two pins for vampire taps, those for the Prog Start button, melted access and soldered on the tap to the first of them, before the heat got to be too much. At this rate, it will take about four more 20 minutes bursts of contortion and baking before I finish up the wiring task at the resistor panel. Nice long breaks to cool down in between, of course.

The time estimates are holding up - second 20 minute interval spent, two soldered vampire taps, two pins inserted, another tap and two more pins to go plus the insulation. In my third 20 minute roasting, at 6:45PM, with the conditions still 92F outdoors and 88F in the workshop, I got more done. Remaining for the last time in the over is insertion of one new pin, the last vampire tap, plus insulation of everything with heat shrink tubing and the dreaded heat gun. .