Tuesday, May 31, 2016

Fixed several issues with 1053 console printer


The first issue I tackled on the console printer was the lever handle which had snapped earlier. I found an identical part on an Itel word processor which was based on a Selectric mechanism, swapped it and had a working lever now.

Broken lever which had to be replaced
Swapped part from another Selectric mechanism now in place on 1053
Next I reattached the nylon tape that activates the red-black ribbon color shift. This hooks to a lever inside the carrier assembly, to change the leverage of a ribbon lift so that the ribbon lifts up to the full extent to allow the red ribbon to be struck by the typeball, or has less lift such that the upper black half of the ribbon is struck.

The way this works is that a set of magnets pull down or release a pulley on the bottom left of the typewriter, increasing or lessening tension on the tape. The tape is routed up from the magnet assembly and runs across the width of the typewriter. Its two ends anchor on the carrier.

magnet lever and pulley at lower left, tape redirected along carrier path
Tape goes inside on left to lever, anchors on stud to right side of carrier
An adjustable pulley on the right side is used to preset the tension properly so that the ribbon lifts to the red or black half as desired. It is currently loose as I need to adjust this with the 1053 under power and typing characters. It is too hot in the workshop to power up this afternoon.

tension adjustment pulley on right side of carrier path

Monday, May 30, 2016

1442 reads fine, cornering still not right; 1053 problems mitigated; starting on memory expansion


My challenges with the 1053 related to a few areas. First, the space button sometimes caused a tab. Second, the carrier return sometimes jammed past the left margin. Third, sometimes the tab movement didn't unlatch where it stopped. Fourth, line feed sometimes stuck on for a few cycles.

The carrier return problem was a real challenge. No settings or advice from the maintenance and theory of operations manuals gave a clue as to why this happened and how to stop it. Further, the illustrated parts catalog and the diagrams in the maintenance manual did not match the part on the carrier which engages with the margin, so I couldn't see how it should appear.

The resolution was to remove the part on the carrier and reason out how it would have to perform in order to work properly. That finally led me to realize that a slanted bar on the part was bent out of position. When I restored the bar to its reasonable position, the latch which allowed the carrier to pop over the left margin will not do an absolute stop.

Testing proved that the return will now work right, without wedging behind the left margin. I worked on the tab and space issues and determined that these were residual lubricant issues which will work out of the mechanism with more use.

Specifically, the tab levers on the carrier are meant to snap all the way back when the carrier reaches a tab stop, but the old oil keeps the part from pivoting smartly in some cases. When it doesn't pivot all the way, it remains with the tab movement unlocked, so even the use of the space button will trigger a tab movement. Once the tab movement locks, as it does most times, space causes just a single space movement of the carrier.

Line feed is similarly symptomatic of residual old lubricants still being moved out of place by new oil. The cure for all of these is use - more tabs, spaces, returns, line feeds and backspaces will eventually yield a correctly operating machine, with symptom occurrence rates asymptotically decreasing to zero over time.

I have to string the ribbon color shift tape onto the machine, repair one lever that selects single versus double spacing, and put the covers back on the typewriter. Once that is done, it can be lowered into place and will be considered finished. The color shift tape will take a bit of adjustment to get right, of course, and the process of replacing the covers is awkward to say the least.


I fired up the 1130 system and tried a Program Load of a boot card through the 1442 card reader. Success would be seeing all eighty columns transferred correctly and no error checks on the reader. I met that goal - I can boot various cards without error.

Beyond the ability to read a card without error, the cornering station and stacker adjustments need to be completed so that cards will reliably move all the way through the machine and out into a stacker. This still needs finessing. A bit more than half the time, the card is sent to the stackers, but otherwise it hangs up in the cornering station causing a check condition.

I also found that the mechanism to select stackers is a bit dodgy, so that sporadically I will get a card wedging up at the exit rollers on the far stacker. This damages the card as well as causing a check stop. I suspect that the cards are entering the stacker area on a slant, which cocks them various amounts. Rotated too much and the card edge will block on one of the two rollers and fold over.

This all comes down to adjustments of the cornering station and stacker. When that is right, I expect everything on the reader to be right (ignoring the broken punch unit).

pushrod wedged and cracking off ceramic on previously intact wheel

I began more detailed design work and determined that my connections to the board are via a pair of old-style .125" spacing edge connectors, double sided, 40 per side or 80 per connector. It is a holiday today but I can pick up the connectors tomorrow and start wiring them up for signal, control and power. The goal will be to use an FPGA to exercise and test the memory, also to prove out operation they way I intend it to work.

Sunday, May 29, 2016

Almost there with cornering station on 1442 reader


I put the broken punch unit back in place, a tedious and careful process due in large part to the wonky pushrods that will fall out if they are even looked at too sternly, clearing several pushrods and lots of other gears, belts and protuberances. With that done, I could hook it up and adjust the magnet assembly so that the punches are held from pushing down through any card in the punch station.

The punch unit serves its secondary role of holding and releasing cards on their way between the read station and the stackers, but is unable to punch holes and advance cards due to the missing row 9 punch and the damaged drive wheel. My goal at this time is to get the card reader working properly, ignoring the punch functionality entirely until some later time when I choose to take on a restoration.

I raised the plastic cover on the cornering station and now cards will reliably eject, but I have to tweak the two pushing arms that give the card its initial shove. They don't retract far enough to let the card drop in front of them always, so that the card sometimes sits on top of them. This might be due to the raising of the cover, so I will have to play with several adjustments in order that the cards begin to corner every time.

The results are good enough right now to consider the next step - attempting to read a card. I will set up tomorrow to try this, using both the Program Load (boot) mode and the card reader functional test program. Reading properly without a check will show that I have enough of the hardened old lubricant out of the clutches and bearings to eliminate the drag that these caused for reading. Too much drag, the card moves too slowly and the error checking circuits spot it and raise the alarm.

Saturday, May 28, 2016

1442 Card Reader/Punch is quite broken in the punch mechanism, but have hope for the reader side


I am quite hampered by the fact that the illustrated parts catalog for the 1442 does NOT show the type of punch on my machine, the part I am trying to replace/repair. There are three types of punch units, A, B and C and in the C there are individually replaceable and group replaceable punches. I have a type C with individual punches. The catalog shows punch type C but the wrong type of punches.

It appears as I attempted to fit the punch that the part I have is broken off, with the remainder of the punch down in the holder where I can't see it. The reasons I assume this:

  1. The punch, of which this piece is a partial example, extends down through the body and several guide bushings so that it can extend out into the card throat to push through the card stock. The part I have is not long enough by far
  2. The punches go down through a 'punch stop comb' under which there is some kind of spring to push the punch back up after the punching pressure is released. The parts catalog for the incorrect punch types shows this as a helical spring held down between the body and the punch stop comb. It would have to make contact somewhere on the punch itself to push it up, yet there is nothing on the part I have where the spring might make contact. 
I may be able to extract the broken off part, assuming it is in the body and that the helical spring has not gotten free and fallen out where I can't find it. However, that is a much more major disassembly than any in the maintenance manuals and likely will involve repair or creation of a replacement punch part, with quite a bit of delay.

Since I have a limited time to get the 1442 operational for use at VCF West when I am demonstrating the 1130, I have decided to forgo any punching. I will reassemble the punch, sans the row 9 punch part, and put it back into the 1442. That way, I can get card transport and reading operations working properly. At some later point I will take on the task of attempting a punch repair.

This afternoon, I reassembled the punch and began to install it into the 1442 chassis. All was going well until one of the pushrods got itself wedged very strangley, wouldn't come loose, then put enough pressure to crack the other ceramic wheel on the axle where I had just repaired one side. Yes, you read that right. The second ceramic wheel now has an arc cracked off about the same size as the original defect I spent weeks repairing.

Fortunately, the ceramic wheel only turns by means of the intermittent drive unit, which is only activated during punch operations. The punch has one broken/missing row punch and a broken drive wheel, so doubly inoperative. I have to say that I have developed an animus towards this particular mechanism which may delay any attempt to repair the punch for a loooong time.

At least I can get back to testing and repairing the card reader function of the 1442, deliberately leaving the punch side inoperative. I might even look at ways to block the logic from attempting a punch at all, to avoid having the mechanism move the wheels or drive the punches.

Friday, May 27, 2016

Jam removed from punch, discovered one of 12 punches had fallen out


The 1053 has three buttons across the front, which invoke space, tab and carrier return, in addition to the solenoids which command these three functions as well as line feed and backspace operations.

Two of the buttons trigger tab, although one of them should only be invoking a single space operation. I also have some remaining issues with the return skipping over the left margin stop and jamming. This may be more gunk from the residual bad lubricants used by IBM years ago, which do not age gracefully.


It is definitely the punch for row 0 that is stuck down in the die. I suspect that I will have to remove the funnel for the chips that fall, then remove the punch die in order to free this up. The goal will be to install it properly so that the punches slide smoothly in and out as they go down and up.

After removing the funnel and the bottom plate, I still had a serious blockage. I decided I had to remove the punch unit from the 1442 chassis in order to work on this. Second time around, removal was quicker.

Punch removed from 1442 chassis once again
Looking into the throat made it clear that I did have a major card jam, not just a stuck punch. It took me a couple of hours of careful prying and sawing and maneuvering with a keypunch card saw before I got the jam cleared. At that point, I noticed the reason that my original symptom was lacing with rows 4 to 8  but not row 9. The punch for row 9 is not descending.

Jammed card visible in throat above wheel
I suspect that this is the funny U shaped part I found. I am going to have to disassemble this much further in order to get to the punch and repair it. Worst case, I may have to manufacture a replacement part if some part of the punch has snapped off. The parts catalog and repair manual pictures are useless to determine what this U piece is or exactly what the punch parts look like.

Using the instructions for replacing an individual punch, I began removing parts from the punch unit to get to the row 9 punch. As soon as the last parts come off and gave me a direct view of the punches, I confirmed that the U piece is indeed a punch.

Punches visible, leftmost (row 9) is missing
The punch which fell out
The U piece, with its two legs much longer than the crosspiece, is how the machine punches holes. The two prongs cut the hole in the punched card, sliding down into the die. A spring pushes them up out of the die, but I don't yet see the springs to know how they attach.

The cross piece on top is what the interposer fits against - the interposer has a ledge that allows the crosspiece to sit against it and be pushed down as the interposer is pushed down. Above the interposers is a wide bar, the bail bar, which is spring loaded upward and forced down by the main punch cam roller when it is time to punch holes.

I think I have an intact punch and only need to fit it back into the die, but the angle is (of course) quite awkward for maneuvering a small piece into place. I chose to wait for another day when I am fresh before attempting the insertion of the row 9 punch, after which I can carefully reassemble the punch unit.

Once I am sure that all twelve punches descend properly, the punch can go back into the 1442 chassis. One of the dis-assembly steps before replacing an individual punch is to remove the solenoid assembly, so I need to readjust those once again.


I received more information on how a fellow enthusiast recreated the pen and solenoid assembly that was missing from his Calcomp plotter and which I am also missing. These show much more detail on how to machine the various parts. I am hopeful that this is enough to proceed. In addition, he has videos of all the steps which are available if I need them to resolve any questions during the process of manufacturing.

Still no word from the metalworker so time to find a plan B for building a replica of the bent drum.

Thursday, May 26, 2016

Adjusted punch of 1442, lacing disappeared, now working on cornering station ejection


Did some initial diagnostic work to zoom in on the problem of my 1442 punch allowing the punches for rows 4 to 8 to be activated on every rotation of the motor - thus randomly lacing cards passing through the punch station during an NPRO.

I tried with my SAC Interface box powered down - same results. This means it is not my logic injecting bits into the machine. I checked the secureness of the main signals cable where it attaches to the 1131 - looked fine. I did try to feel for a magnetic field during operation, using a screwdriver near the punch solenoids, but no luck with that.

I looked over the logic diagrams for the SLT cards inside the 1442, to see if there was a common card for just those five rows. That did not pan out. Next, I looked at my ALDs for the adapter logic inside the 1131, to see if there is a common card that might explain this symptom. Nothing fit the symptoms there either.

I moved on to the mechanical adjustments and checks. I soon came to realize that the magnet assembly mounting screws were loose and the assembly was skewed away from the bottom row punches. I tweaked this and tightened it down so that no punches were activated on NPRO cycles. I may have to play a bit with it to ensure that all desired holes do get punched, but for now it is good.

Next up, I have to face the puzzling symptoms - I only saw rows 4 to 8 punch but from the top I can see that the interposer is active for row 9 as well, but the cards didn't have that column punched. Right now, I have a small wedge of card that tore off in the punch station area which I have to clear before I can go back to my tests and adjustments, but I am moving forward nicely.

It appears that the wedge is not a piece of card, but a stuck punch - perhaps the row 0 - with the interposers and remaining mechanisms unactivated it is stuck down. I will have to figure out how to deal with this, hopefully without having to remove the punch unit and disassemble it.


I received my EMM 32K x 18bit core memory module today and immediately ordered the +15V, -15V and +5V power supplies needed to use it. I will set up a quickie FPGA design to drive and test the core memory in various ways - timing, bit retention, holding various patterns. In the interim I can plan out the way I would interface to this core from the 1130, design circuits, layout the implementation and the rest of what I need to make this work. 

Wednesday, May 25, 2016

Investigating possible causes of 1442 punch lacing during NPRO


The punch unit has three cams rotating in synchronization, moving mechanical parts. There is a main or punch cam, an interposer restoring cam, and a punch restoring cam. In addition, twelve solenoids will either pull an interposer back out of the punch path or let it pop out by spring pressure. The solenoid has a constant hold current which pulls the interposer back and another winding that neutralizes the pull of the hold current when an interposer is to be released into the punch path.

The punch cam pushes down on 12 spring loaded rods, one per row of the card. If a spring loaded interposer has moved out into the path of that downward rod, then the rod pushes the interposer down which pushes on the spring loaded punch itself. This pushes the punch down through the card and into a punch-shaped die below.

The punch restoring cam will push all the punches back up, pulling them out of the die and through the card to reach their original raised position. Thus, the punch restoring cam is timed to push up after the punch cam itself has finished pushing down. The final cam is the interposer restoring cam which pulls the interposer back against its spring load, so that the hold current in its solenoid can keep it retracted. Thus it stays until it is next selected by the neutralizing counterwound current.

This means that when power is off to the 1442, all twelve interposers are pushed into the path of the punch rods and all twelve punches will push down through a card and into the dies. When power is on, all twelve should have only hold current applied and thus all twelve interposers are kept out of the punch path. No punch should descend with hold current on.

The only way a punch should descend when power is on is when the counterwound coil current is also applied, allowing interposers to spring out into the punch path.  Since the punch unit and its three cams are constantly turning whenever the 1442 motor is turned on, it is only by way of the hold coil current and absence of counterwound coil current that the punches do not descend.

My first power up test had punches for rows 4 through 8 descending on every rotation of the punch cam, which should be caused by one of three cases assuming no mechanical failures:

  1. The hold coils are not energized for those five rows
  2. Hold is energized but so is the counterwound selection coil
  3. I have assembled the punch incorrectly which is blocking those interposers from retracting

I think that the hold coils are all wired in parallel, with one source of energizing power. Unless the coil is defective, all should be energized and either all twelve punch or all twelve don't. I can test for magnetic attraction on the ends of the twelve solenoids using a metal rod or screwdriver.

The counterwound coil is driven by an amplifier/driver card in the punch based on signals coming over the cable from the 1131 adapter logic cards. I could have a bad card in either location or the cable might not be fully engaged. I will check all these conditions when I get to the machine tomorrow. Today, I am working on the 729 tape drives on the 1401 computers at the Computer History Museum.


Waiting for the metalworker to respond to my specs and request for an estimate. By the weekend without a response, I will go find another metalworker.

Waiting for the hard drive recovery service to complete its attempt and tell me whether my files are recovered. They would be delivered by FTP so once they respond and if I pay, I can be accessing them immediately.

Tuesday, May 24, 2016

1442 back together, testing now, plus rebuilding laptop


I have installed one of the linkages and was working on the second one by lunchtime. I also located the place for most of the remaining parts in the bin, which are part of the punch eject roller and its belt drive. However, there are just a few mystery parts which worry me, particularly two of them. A circlip which suggests a roller somewhere that is not properly secured on its post, and a U shaped pin which might be from deep inside the punch unit.

Hand operating the punch unit, I see it drive all 12 punches through their dies and advance everything suitably, but until I have this under power I won't know if the interposers work to block punching each of the 12 rows.

It was quite challenging to handle each of the remaining tasks, given their nearly inaccessible locations, lack of enough room to use any of my tools and the challenge of stretching the rubber drive belts over the edges of the pulleys. I improvised with a tiny socket held with itty bitty vice-grips, and similar improvisations.

By mid afternoon, I had the linkage on, the punch eject roller parts assembled, belts in place and everything ready to button up for testing. I had dropped the circlip down into the machinery somewhere while trying to fit it somewhere it didn't belong. I also lost a lockwasher for the bolt that holds the punch eject pulley on.

Remaining mystery parts are a small nut, a medium size washer and the small U shaped thing. I hope I never discover where those parts go, since that would be discovered when some part of the machine malfunctioned.

I fired up the system, loaded cards (push Start button to get one card to feed into the pre-read station), and did Non-Process Runout (NPRO) to clear cards. Cards that exit the punch station still get stuck in the cornering station, where cards stop after exiting the punch and them are picked up by the stackers which begins moving the card at right angles to the original travel direction.

More seriously, while doing an NPRO, the punch unit laced the card in rows 4, 5, 6, 7 and 8 although this was a real punch operation. When punching, the card sits in the punch station and is moved column by column through the operation of the incremental drive, timed between each punch cycle. In this case, while the punches were pushing down the card was trying to fly through the punch station, using the punch eject roller and not the incremental drive.

This might be an interaction between my virtual 1442 logic sitting in the fpga and the IBM supplied adapter logic in the 1130. I removed the jumper that disables the IBM adapter from reacting to XIO instructions, which was in place while I tested the virtual 1442 functions. Now, both FPGA and 1130 logic are active which might introduce problems. Still, punching randomly while cards are cleared with an NPRO is not good.


My first two actions on the new laptop image were applying all the windows updates and setting up a Crashplan subscription to make sure I never again lose all my work. I am waiting to see if the recovery lab can retrieve my data, but my drive arrived in the afternoon Friday of a three day weekend (Victoria day in Canada) so that my drive was just opened and logged today.  I am hopeful but not wildly optimistic; I should know in a week or two.

Next up I started installing software I use, such as the Python environment and the wxPython GUI code. The longest was the download and install of the Xilinx Vivado toolchain for the fpgas, requiring downloads of more than 3GB of data.

Monday, May 23, 2016

punch unit assembled and partly installed in 1442 card reader/punch


I worked all morning on the reassembly of the punch unit and its incremental drive. I think I have everything done correctly, but it is hard to tell for sure when there are a number of parts in the bin that are used for the installation into the 1442 chassis and for connection to other units.

Punch unit with incremental drive on front
The incremental drive has two strong springs that had to be compressed quite a bit in order to install them. I was having the dickens of a time attempting it until I noticed the order of removal of parts listed in one of the maintenance manuals.

Side view of punch unit, incremental drive on right
It mentioned removing the solenoids that engage each side of the drive before removing the springs. I foolishly had ignored this because I had plenty of room to access them for removal. While removal didn't matter when taking out the springs, the solenoids need to be out when the springs are reinstalled (reverse order of disassembly, per the manual). Without solenoids, the spring holddown arms swung open, letting me put in a spring and pivot the arm to compress it. Easy as pie.

The punch unit and incremental drive are complex mechanisms with many gears, cams, pushrods, springs, detents, solenoids, pulleys, belts and so forth. The incremental drive will move a punched card one column forward, in between the actual punching of the holes for that column. Thus, timing is important so that the card is still during the entire time the punch die is extended through the card, but that movement completes before the punches start moving for the next column.

Before I install the punch unit, I will read the service and adjustment manuals very carefully to determine whether there are any adjustments I should make with the unit out of the machine. With so much of it disassembled during the long process of removing gunked up old lubricants and many parts loosened or removed, I may have to make quite a few adjustments before I attempt to read and punch cards.

Parts bin during assembly
I found that there are several adjustments to be made for the incremental drive and all of them are done with the unit out of the machine - glad I didn't install it yet. Worked through the adjustments this afternoon.

The adjustments for the remainder of the punch unit are done while it is mounted in the 1442 chassis, so I proceeded to install everything. By the time I stopped for the day, I had the punch in place, some belts replaced, the electrical connector attached, but still had to install a few things. Remaining to do are:

  • Install two pushrod linkages from the main cycle camshaft
  • tighten the main allen screws holding the punch to chassis
  • reinstall the idler pulley I had to remove
  • get belts in position and tensioned properly
  • replace various covers and panels

Punch unit mostly installed in 1442 chassis
Front of punch unit where belts are attached

Still no word from the metalworker on the replacement cylinder manufacturing. I will wait until next week, then find another shop if I haven't heard back from this one.


I received the replacement hard drive from the seller of my laptop and will keep that as a protected master. I put it into my external disk cloner and cloned it onto my 960GB SSD which is what I will actually mount into the laptop for use. The cloning took several hours but soon I had a vanilla Windows laptop where I can begin installing software.

Sunday, May 22, 2016

Wheel finished and beginning reassembly in 1442 Card Reader/Punch


I received the grit and did a test slurry. I discovered several things from the test. First, medium grit (1/4 millimeter) is way too coarse to match the original ceramic grit, but fine grit, about a tenth of a millimeter diameter, is a great match. Second, mixing the grit with the glue first produces unsatisfactory results.

My second try was much more successful. I used fine grit, put a thin layer of adhesive on the wheel and poured the grit atop it. I tamped it down slightly with my finger and then cured the adhesive with UV light. I have a couple of small sections that are too bare, but most of the wheel surface is already good. Later I will try to fill in the sections without raising the surface too much.

repair in process - bottom wheel, left side original, right is repair
I also have a high spot near the join with the original ceramic. I will carefully grind it down and if too much grit is lost, dig it even lower and add adhesive plus grit to relevel. I feel good about this process and should be able to finesse this into suitable condition.

Wheel damage before I filled and began restoration
Sunday morning saw the completion of the wheel. I smoothed and filled in the top surface, have enough grit to ensure a great grip on the punched card stock as it is moved through the punch station. I decided to add some grit to the sides of the wheel, since cosmetically the clear adhesive in the repaired section was noticeable. I didn't fuss with exact fit or appearance, so that the sides are a bit more patchy, but overall the wheel is ready for re-installation, once I flow off any remaining lost grit especially near bearings and turning surfaces.

Wheel ready for final cleaning and then installation
The part is cleaned and reassembly is starting as of Sunday night. I have a table set up with the parts and relevant parts and maint manuals, so that I can fit it all together. Monday's the day.

Saturday, May 21, 2016

Memory increase to 32K using EMM core card - design investigation complete


The 1/4 millimeter diameter grit won't arrive until tonight, thus nothing was one on the reader today.


I began digging through the ALDs and the inventory of what is installed on my machine to see how feasible it would be to make use of this 32K word by 18 bit card to bring my 1130 up to full memory configuration - 32768 words - from its current 16384 size.

MB301 Final assembly of memory address bits 1 and 2 (16K and 32K)
The logic for the "expanded storage" feature which supported machine sizes bigger than 8K has all the gates and signals installed for a full 32K, so this one is fine as is. I then had to dig into all the sources for these signals to be sure that every incoming signal had a valid source.

For example, on this page there is a note about a jumper which is installed if the machine has expanded storage. It allows bit 2 of an address from the built in disk drive to be gated to memory when the drive is using cycle steal to fetch and store words. Oddly, no jumper is required for bit 1, which is always driven by the disk adapter logic sourced from logic page XF231 same as bit 2.

Sources to the page MB301 that must be checked include the I and A registers, file (disk drive), and the SAC. This page is the M register for the high two bits (1 and 2). This feeds the MB311 page which assembled the final storage addresses going to core storage.

The page does have signals for Card Reader bits 1 and 2, but no card as a source. These represent the signals that would be used if a 2501 were configured, since the IBM 2501 uses cycle steal to fetch and store words.

So, you might ask, why no signals from the 1132 printer, 1442 card reader/punch, 1053 console printer, keyboard or console entry switches? Because none of these use cycle stealing. All the data they need to fetch or store is handled by the XIO instructions themselves, which make use of the A register feed during their execution.

MB311 which has drivers for the memory address lines bit 1 and 2
Here is the companion MB311 which drives the signals over the long flat cables from the center of the machine holding the main logic cards over to the left 'blister' side, which has the two 8K core memory modules. MB321 is not shown because it has the drivers for memory address bits 3 to 15.

MB101 assembles CPU address bits 3 to 15
MB101 takes the M register bits 3 to 15, gates them by the inhibit signal used when the processor is jamming in special addresses such as 1 2 or 3 for the index register, and forms the CPU address bits that are used below in MB111.

MB111 - assembles sources for memory address bits 3 to 15
MB111 simply assembles the bit contents for memory addresses 3 to 15 from the various devices which drive it. Just as with the high address bits, it uses the file (disk) address lines, the SAC address lines, and the empty 2501 card reader address lines. It takes the CPU address bits 3 to 15 from the prior page and mixes them to produce the storage address bits 3 to 15.

Notice that some of the bits have inputs from the printer and the special index register address circuits. When the CPU wants to address an index register, it blocks the M register (CPU addresses) using inhibit and then feeds in a 1 on bit 14, 15 or both depending on whether register 1 2 or 3 is needed. The 1132 printer does a fetch of locations 0x00020 to 0x027 for the bits to control firing the 120 hammers, so it needs to inject 1 bits into address bit locations 10, 12, 13, 14 and 15.

MB201 allowsprinter and file (disk) addresses only during cycle steal
MB201 allows 1 bits from the printer addressing the scan field or the file (disk) when those devices are doing a cycle steal. All the bits are wire-or connected together so that gating like this is needed to block any signals when they should not pass through to the memory address logic.

The sharp eyed reader will see that the storage address bits 1 and 2, generated in MB301, do not get signals from the M register, don't have a CPU address generated as is done for the lower bits in MB101, but instead create a shadow version of the M reg bits 1 and 2. Looking at the M reg itself on RB111 and RB121, the M reg flipflop is not connected to memory addressing at all, while bits from RB131 (bit 3) and lower use the M reg to build CPU address.

The effective value, the 'shadow' of what is in M reg bit 1 and 2, is held in the flipflops in MB301 and generated independently. It looks at the value of the I and A register for those bit positions, control signals which are active when the M register is loaded from I or A in the RBxxx logic pages, and a special generated signal to load SAR bits 1 and 2. This is logic that is parallel to and different from how the other bits are handled. Odd, since the M register does have bits 1 and 2 present, but the output is only used to display the lamps on the main panel.

Terminators for storage address signals for bits 3 to 15
Here is an oddity. The terminator ALD page shows the resistor terminators on the address lines going over the flat cable and entering the memory modules in the blister. The resistor packs terminate signals for bits 3 to 15, but not bit 1 or 2. Since this is a 16K machine, bit 2 is used and seems oddly missing. It may be that the terminator resistor is just missing due to oversight on the ALD page or it may be shown in the memory schematics themselves, being handled parallel to but different from bits 3 to 15.

Cabling between gates of 1131
The cabling diagram AE000 shows the flat cables which run to memory from the CPU gate B, compartment C1 which lies under the console printer in the center of the 1131. The memory is installed in the blister (left hand side of the 1131) on swing out gates D and E. Each of those two gates holds two compartments and each compartment would have an 8K storage module installed.

For a machine with only 4K or 8K of memory, thus without the expanded storage feature, all memory is placed on CPU gate B in compartment C1. No blister is installed, resulting in the short version of the 1130 system.

Three cables are run - with the pair that hook to the T1 and T4 positions in a wired-or configuration so that any of the core modules can introduce data to the common bus. The other cable runs through each module, coming from the CPU to T2 of the first module, out of T3 on that first module and into T2 of the second module, and so forth. The final module's T3 will have terminators wired up.

My machine has gate D with both compartments filled - yielding a 16K total memory configuration. It is missing gate E. If a machine had 24 or 32 K of memory, it would have gate E installed also and use one or two compartments depending on storage size. I will put my interface logic, power supply and the 32K storage card in the empty area in the blister where gate E would have been installed.

AD001 lists various jumper wire, cabling and terminator requirements
The page above details the changes that must be made when changing the memory size of an 1130. Basically, these involve the placement of the terminators at the end of the memory address and data cables - on the last core module on the bus. Then, jumpers are configured on each memory compartment to customize its addressing.

If I increase memory from 16K to 32K, I need to add some jumpers on the existing core modules on gate D. These jumpers will deliver 'not bit 1' to the modules, so they are inactivated if bit 1 of a memory address is 1 but active otherwise. My new circuitry would only work when bit 1 was on, so that the new card handles addresses from 16384 to 32767 while the gate D compartments handle 0 to 16383.

The jumper is not on the machine as it sits, because it will allow memory addresses above 16383 to roll over and use the existing memory. What I mean by that is that all addresses are treated modulo 16384. Thus, 0 and 16384 are the same core location. 1 and 16385 are a common location. This is now the 1130 architecture is arranged.

The jumper is added to block that behavior. With the 'not bit 1' added into the selection logic, when an address increases past 16383 it is no longer modulo 16384. It becomes modulo 32768 when I add the new memory card and make use of address bit 1. Address bit 0 does not exist, so address 32768 becomes the same as 0, etc.

This leads to the interesting possibility that a machine could be increased to 64K but with quite a bit of work. Circuitry equivalent to the MB301 card would be needed to produce address bit 0. The SAC logic and disk (file) adapter logic would need to be changed in a few places to include the extra address bit. The existing SAC cable does not carry bit 0, it would need an additional signal line.

The flat cables to the memory do not carry bit 0, so signal lines would have to be added to carry the wider address. Finally, the select logic for the memory compartments would have to take into account bit 0 as well as 1 and 2. There may be other subtle factors, but a few cards worth of logic and some additional cabling would do the trick.

AD000 Jumper and timing settings for configuration changes
Page AD000 shows various jumpers that are installed or removed to control different configuration changes. Only five jumpers involved in memory configurations. One is used for any machine above 8K, to connect the file (disk) bit 2 into the address logic. Two are used if the 2.2us storage is installed, while the other two are used if the machine comes with the 3.6us type.

Based on this, I need no change to jumpers when increasing memory to 32K, but would have to swap the two sets of jumpers if changing to act like 2.2us memory. In that case, the oscillator card has to be adjusted to 3.64MHz (might need a different crystal) from the 2.25Mhz rate it has now. I would have to disable all of the existing core, since it is too slow, and use the entire 32K word new card as memory to operate as a 2.2us model.

The bottom line of all this investigation is that adding in my additional 16K of core should be quite easy, requiring only a few jumpers on the existing memory to look at 'not bit 1', adding cabling to my new interface logic and moving the terminators there. The 0.95us memory of the new card will readily work fast enough.

One complication inside my circuitry when using a much faster memory is that the data to modify a word for the write part of the cycle is not produced by the 1130 until halfway through the 3.6 or 2.2 us cycle, so I have to control how the new card does its rewrite half so it is delayed from 450ns to the 1.1 or 1.8 us point.

Fortunately for me, the EMM card has a mode - split mode - where it does the read half of an operation based on a read trigger pulse (RP) and waits for the user to initiate a write trigger pulse (WP) to trigger the rewrite. Thus, I can control the timing so that I send RP, it does a read in 450ns, waits until I trigger WP at 1100 or 1800 ns, then completes the rewrite by 1550 or 2250 ns.

The data out signals are wire-or connected to the B (storage data) register and will set bits on as soon as nonzero data from the core arrives. Normally this is from the sense amps as the IBM core is read, but I have to be sure that the data is blocked until it is safe for it to appear and that it goes away when necessary. This may work with no such blocking, but it is a need that I have to anticipate.

The rewrite which is done from the B register contents in the 1130 does not care if the data is not ready exactly at the halfway point of a memory cycle, as long as it is present and stable at the time the 2.2 or 3.6us memory is ready to flip cores on or off. The new card will complete the write much faster, so I may need to delay the WP pulse until the point when I am sure the 1130 has the B register value present and stable. This delay is pretty likely to be required.

As far as signal and power requirements, the new card uses TTL signaling levels, although inverted sense so +5V represents a zero logic state, and the memory needs +5, +15 and -15V supplies. The +15 and +5 rails can draw up to 3.8A, while the -15 needs no more than 1.2A. The board needs less than 100W of power and there are many low cost supplies I can buy to provide the power.

I need to provide for SLT to TTL level shifting - with the SLT operating with 0 to 3V signal levels while TTL is 0 to 5. I have already addressed this with my SAC Interface box and simply need to modify that design a bit to snoop on the 15 address bits and 16 'data out' bits coming from the CPU to memory. Then, I need open collector ICs to activate the 'data in' bits when my core is emitting sense bits in to the 1130 for a read. I have to snoop a few storage timing and inhibit lines as well, but that is the same problem as with the 31 data & address bits.

What also must be designed is inhibit logic if I need to control when my 'sense amp outputs' are presented to the CPU bus and to control when I fire the RP and WP pulses into the new memory card. This is the new portion of this design, all the rest being variations on previously solved and proven approaches.

Friday, May 20, 2016

Continuing 1442 card punch restoration of punch wheel, picking up core memory for upgrade of 1130 to 32K configuration


I took a bit of plastic off the restored section of the punch wheel, so that when I coat it with a slurry of course tumbling grit it should end up at the target diameter. I picked up some 1/4 millimeter sized silicon carbide grit which will give the wheel the same quality of 'grab' on punched card stock as the original ceramic material on the undamaged portion of the wheel.

My grit will arrive on Saturday evening and by Sunday I expect to have the wheel completed, ready for reinstallation. Since it has been so long since I disassembled the punch, I will have to work carefully from exploded parts diagrams, maintenance manual pictures and some interpolation in order to get the unit back together properly.


I came across a nice looking core memory card on ebay and purchased it. A 32K by 18 bit core that operations at up to 950ns read-modify-rewrite cycle time. The 1130 is a 16 bit word with two parity bits - thus 18 bits is a perfect fit.

An 1130 can address a max of 32768 words of memory and my machine has 16384 words installed. This one card can provide the entire memory needs of the 1130 and I can use half of it to expand out my system to max configuration.

The 1130 operates with one of two memory speeds - 3.6us or 2.2us - and the one I have is the slower 3.6us version. Using a 0.95us memory will easily fit in the much longer cycle time of the 1130.

There are two levels of complication in adding in this memory, assuming I worked out the interface electronics, power and mechanical details. The first challenges arise when I increase the machine to a 32K 3.6us configuration. The additional challenges will arise if I tried to use this module to convert the machine to a 32K 2.2us configuration, disabling the original core memory in favor of this card.

In either case, I would need to add circuitry to support the additional addressing - addressing registers were built with only 14 bits of address, output lines from adders and other registers that might receive addresses were set up with only 14 bits, and there may be other places were IBM omitted the signal traces, flipflops and gates needed for 15 bit addresses. The motherboard as well as SLT cards might be different in a 64K system, to provide for the extra address bit.

Spare gates and flipflops might be on the installed cards, the appropriate signal traces may be on the backplane and everything I need could be present so that all I need is the address decoding for the extra bit and the interface logic to interpose the new memory in the current system. However, seeing how different the ALDs are for different 1130 instances, I doubt it would be this clean and easy.

Detailed investigation would be needed to assess the addressing state of the machine as it sits, the operational state of the extra bit for any that are already in the machine, and then create a plan to address any gaps. Might be addition of wirewrap signals on the backplane, but it could be as complex as building an entire shadow register or logical unit in order to generate and deliver the needed high order address bit.

The second case involves timing sensitive changes that were made on 2.2us machines to work properly with the faster memory. I don't have those circuits and might need to do some significant rework, add in some circuitry of my own, and potentially debug timing issues because of the Frankenstein nature of this approach.

I will investigate the first case, expanding to a 32K word 3.6us configuration, but have decided against the much higher risk alternative of a 2.2us system. I could, however, add in some extensions to the architecture, bank switching memory under control of currently unassigned op codes. That would be fun but requires quite a bit of change to both the 1130 and the disk monitor system software. Next year, if ever.


Still nothing from the metalworker and nothing from the designer of the replacement pen assembly.

Thursday, May 19, 2016

Nearly done restoring the broken grit wheel for the punch unit in the 1442 reader/punch, while waiting for plotter restoration answers


I worked with my Dremel tool to shape the UV hardened plastic I am using on the broken wheel. I sanded it down on the sides and evened the top, but decided I had to make the diameter of my new section slightly higher so I could sand it down to the exact size I wanted.

This afternoon I got it closer to round. It rolls nicely on a flat surface other than one high spot, but doesn't yet have the grit applied that will ensure it grips and pulls the card one column at a time during punching. In my next session, I will drop the high point and get it very close to perfect before I mix up some grit in the glue and carefully hand apply it to the surface.

By early evening, the wheel was within 1/128" of the diameter of the rest of the wheel. Since this wheel meets a spring loaded rubber roller (with a card pinched in between), I should have less than 2% variation in column spacing at worst case which should be within the margin of any card reader.

The remaining step is to select an appropriate grit which I can mix with the UV curing resin to form a slurry. If I can apply it very thinly and carefully along the replaced arc on the wheel, hardening as I go, it should restore the wheel to usable condition.

Then I have to reassemble the punch unit with this wheel, put the punch unit back and reassemble the rest of the 1442, then continue to clean up bad lubricants and adjust operation until it is reading and punching properly. That will take a few weeks of work, I suspect.


I am still waiting to hear back from the metalworker on whether they can built the replacement cylinder and a ballpark cost. I suppose I should be looking for a backup craftsman in case I don't here from them or they aren't interested in a small but exacting project.

I am also waiting to receive some more detailed drawings that another hobbyist produced to manufacture his own pen assemblies for the plotter. It has been a while, but he may still be searching for them. If not, I have to complete the design and make all the drawings to allow a shop to build this to my spec.

If I design my own, I think I will start with an existing solenoid coil that closely matches the specs of the original Calcomp part. It has to have a hollow center at least large enough for a reasonable pen holding 'slug', ideally the same as the Calcomp barrel diameter. Then, knowing the exact size, I can design the holder and other parts to fit. If I proceed from the Calcomp or hobbyist recreation sizes, then I need to locate a solenoid to fit the outer diameter and length of the original.

Wednesday, May 18, 2016



I shipped my failed hard drive to a recovery company, Datacent, who are going to open and evaluate the drive in a clean room. Based on what conditions they see, I can allow them to make whatever repairs are needed and extract as much data as they can from the drive.

If they are successful and I agree, I will pay a steep but prearranged ransom to get the data back but my costs are limited in the worst case to what I spent for shipping. In other words, I haven't decided firmly yet and will make the call later once I have more information.

Meanwhile, I wait for the replacement pre-imaged drive which I will clone over to my SSD for use in the laptop, once it arrives. In the interim, I will try to focus on aspects of the project that don't require a computer - working on the broken wheel inside the 1442 card reader/punch, for example.


I replaced brush blocks on the IBM 729 tape drives which are connected to our twin 1401 systems. While the actual replacement and testing effort takes about three hours per drive, we don't have enough spare blocks so that each set of removed blocks have to be reworked to put in our substitute graphite brushes. This involves some careful dis-assembly, soldering work and reassembly.

Generally I drop at least one screw during the work on a drive, requiring some hunting inside the drive or on the floor, so that adds about 15 minutes to the task time. We have completed five of the seven drives to date and one more will be straightforward. The last drive is a beast because it has the twin brush blocks for the feed reel side installed from a nearly inaccessible spot, instead of along the outside frame like most of the other drives.

Tuesday, May 17, 2016

Recent work almost certainly lost, but soldiering on


The Windows System Repair (which insisted it could not be cancelled) ran 30-40 hours before ceasing all disk activity and sitting helplessly inert. When I power cycled the laptop, I received a SMART error message to expect imminent disk failure. However, that occured before I could access the disk to remove anything.

Disk diagnostics on the laptop returned "Unusual Error" and immediately aborted. My standalone disk cloning box couldn't read it. I connected it to another PC and ran a good disk recovery utility. The drive takes a full set of recovery actions on each and every IO - I think 256 times is the magic number. That is why the system repair ran so long.

When I mount the disk to my other PC, it does its continual error recovery cycling amid each IO, but it did show up eventually. The disk recovery utility (Seagate) found the partitions and I selected the one with my data on it. The detailed scan ran excruciatingly slow - after four hours, I had found 232 directory entries and no files yet, with a projected completion time of over 10 years.

It does eventually get the data, but so slow as to be impractical. It does appear the data is intact and can eventually be read, although I am not sure how completely since it was just starting into the drive when I bailed out.

I could use a hard disk recovery service - they will swap electronics, replace heads if necessary and then extract as much data as possible. The downside is price - a minimum of $600 and some quoted up to $2400. While it is painful to have lost about a month of coding and some fpga logic, plus the huge annoyance of reinstalling applications and toolchains, it is also hard to justify spending that much money given the risk that key files might still not be fully recovered.

I did buy a 960GB SSD to use in the laptop and will receive a replacement hard disk drive with Windows and drivers installed, as the seller of the laptop considers this an in-warranty event.

All this pain because I didn't verify that I had a correctly operating backup in place on the laptop - assuming I was safe until it was too late.


I sent very detailed specs to the metalworker to get a quote for the cylinder, with holes predrilled for the pin feed but it is up to me to find/create them. I have received several good suggestions from readers of the blog, all of which I am considering carefully.


I will have to recreate everything I had built for the new GUI - screens, restructured logic in the model-controller-view pattern, and test it all again. At least I should be able to take a workable approach straight away, rather than fighting to learn what works as I did in past weeks. I also need to find and download all the images I was using for the interface. All achievable, once I put in the time.

I have adjusted or refined parts of the fpga logic, as well as having converted it to work successfully on the Vivado toolchain for the new fpga board. All that will have to be redone and I hope I can figure out what changes I had to make. Here, I can imagine burning debugging hours in the future only to spot a problem that I realize had been fixed but lost in the great crash of May 2016.

Sunday, May 15, 2016

Laptop disk crisis, setback on plotter restoration and progress on SAC program (possibly lost however)

Possible serious setback - I awoke to find my laptop with the Windows Startup Repair screen displayed, claiming to be repairing disk problems. It has been six hours minimum, perhaps many more depending on when the laptop attempted a reboot and started the repair. It can't be more than 15 hours since I saw a normal display on the laptop before I retired last night.

I have read posts where this process took multiple days to complete, after which I discover exactly how little or much of the disk contents are still accessible. I will buy a new disk and cloning gear, but I will have some challenges with software, keys and the like if I have to reinstall Windows and applications. More seriously, the work of the past couple of weeks might be completely obliterated.


Disappointing news from the metalworker who I hoped could remove the dent in the plotter drum. He believes that the aluminum is too stretched to get good results working it. The only solution would be to fabricate a replacement cylinder, but that would depend on my finding a source for the pin feed conical shaped rivets that are on the two ends.

This was one of the possible routes to repair - a substitute aluminum cylinder - but the pin feed rivets are the real fly in the ointment. A replacement cylinder would need the rivets to act as pin feed pulling paper on the drum. If the shape isn't correct, the paper could slip as the plotter moves the drum up and down or it could cause the paper to bulge up off the surface.

Pin  rivets that act as tractor feed for continous paper rolls
It does not appear that there is any need for tractor feed (pin feed) paper handling and nobody makes rivets for that role. My rivet heads are cone shaped, 1/8" at the base and spaced at 3/8" intervals around the drum circumference. I can find round head rivets, but not that close a match. The style that comes closest is called 'high button' head but I can't find any source for those either.

There are some alternate courses of action I could take. One would be to build a replacement cylinder but without the tractor feed pins (rivets). It won't be a faithful restoration because of this, but it will allow me to tape sheets of paper to the drum and run some plotting.

A very unlikely solution would be to remove the existing rivets as carefully as I can and find someone who can weld extensions to the bottom to allow them to be affixed to a replacement cylinder or otherwise find a way to attach them.

Backside of the pin rivets
As you can see, I either have to work the rolled over rivets to bend the metal up and into a hollow tube, allowing removal from the old drum and installation on the new, or I have to grind off this side, weld a new rivet rod to the removed rivet, and attach the new rod somehow inside the replacement drum.


Restructuring the GUI

I finished testing the PC side of the virtual 2501 card reader. It handles hopper empty conditions properly and will set or reset the last card status when the fpga signals operation complete.

Using what I learned, I then worked on other device drivers to have them behave properly although purely from a PC only standpoint as I am not yet testing with the fpga and the 1130 system in the loop. Next up for careful study and testing was the virtual 1403 printer function. In the course of testing, I decided to drop the Carriage Restore button and function from the GUI.

From here, I finished the PC only testing for the real 1627 plotter and real 1134/1055 paper tape devices. These serve only to activate and deactivate the fpga which controls the real devices. The 2310 device took a bit more time to accomplish.

Next up was the code to communicate over the USB link. I restructured this so that my Queueing object will instantiate the USB handling module and keep it encapsulated entirely inside. This allows me to change the USB functions independently and allows the queueing module to control how it communicates, potentially even entirely replacing the USB link with something else. Good OO structure now and tested as far as possible without hooking up to the FPGA.

Once I felt comfortable with the logic for queuing transactions, having them pulled and communicated over a USB link and responses posted back to the caller, I could start up the background process that regularly updates the main screen with 1130 status. This too took some time to straighten out.

I had some hangs and stalls, since the main screen involves three cooperating threads, but I eventually got it all straightened out. I was attempting to pass an argument to one of the GUI threads that handle the main window status signals, which caused odd problems when I naively adding the argument to the threading command. I finally figured out a method to accomplish what I wanted without the argument.

Another enhancement I made was to add in logging window support, where status and error messages can accumulate, using the wxPython logging capability. This gives me a nice window with timestamps, support for saving the log to a file and/or clearing it out, and a new Action menu choice to Show or Hide the log window. This does require that I walk through all the code, replacing the diagnostic, status and warning 'print' commands with logging calls, a tedious but straightforward process. Fortunately, logging is thread safe and works well with my many-threaded design.

Wednesday, May 11, 2016

Debugging started on 2501 function as GUI change nears completion

Many interruptions today - getting a filling over the recent root canal, volunteering at CHM where I installed 12 new brushes in one of the 729 tape drives, and dealing with the transition to Medicare (senior citizen) health care which involved two agencies and the health care provider. Still, I did get some work done on the 1130 project.


Restructuring the GUI

A friend asked why I didn't just reproduce the appearance of the various device control panels, and of the 1130's main display panel. It was something I considered, but decided against because the 'signal to noise ratio' would be too low.

Take, for example, the control panel for the 1442 card reader/punch. There are four active buttons, four lamps and a dummy button on the right side, and a set of seven lights in a flat black square on the left. The only lamp that is useful on my GUI is the Ready lamp and the only button that is useful is the NPRO one.

That leaves 3 live and 1 unused buttons cluttering up the screen, plus 10 of the 11 lights unused. Then, I need to show the state of the hopper, display the file names for both input hopper and output stackers, indicate the number of cards remaining in the hopper, and offer a Prog Load button which is on the main 1130 keyboard rather than the card reader.

The 1132 printer has 18 positions filled with buttons, lamps or a switch, but only a couple are useful. Displaying the paper and carriage control tape files does not have an analog on the real 1132. Once again, most of the panel would be non-functional but distracting.

The same was true of the main 1130 display panel, since I can only display the state of the Storage Data register, not the other five registers. Of the eight T clock levels, I only display four. Some information such as reset, X0, X2 and X4 clock states are not displayed at all on the real 1130. Other information, such as the Parity Stop, exist on the keyboard panel not the display panel.

I chose instead to be evocative of the 1130 but not a close match. I organized the control panels on the GUI to present the needed information and guide the user on the available operations they can request.

I walked through my 2501 reader code and realized that under the new model-view-controller, there is a flaw in how I handle the last card condition. I need to add a transaction that the code sends to the fpga to arm it for the last card status when it handles the very next XIO Init Read.

In a real 2501, when the hopper becomes empty, the reader goes out of ready. If the Start button is pressed without putting new cards in the hopper, the reader becomes ready but adds the last card bit in the DSW when the card is read. Otherwise, more cards are added to the hopper and Start makes the device ready again. Subsequent reads in that case do NOT have the last card bit set.

Monday, May 9, 2016

Building mirror interfaces for console entry switches and 1053 console printer


Restructuring the GUI

I built the code for the mirror Console Entry Switch device and cleaned up the mirror 1132 code, over the course of the afternoon. Plenty of opportunity to clean up and refactor code - one routine to build switches rather than repeating commands for all 16 of the console bit switches.  The switch ends will flip up or down to reflect the value that was read with an XIO Read from the physical CES on the 1131.

mirror Console Entry Switch panel
For the typewriter (console printer), I set up a nice window that appears to be a form emerging from a picture of the 1053 - clicking the paper either opens an output file or closes an existing file.

mirror 1053 Console Printer (typewriter) panel

Sunday, May 8, 2016

Great progress rebuilding GUI for SAC Interface Box


Restructuring the GUI

After working with the more complex 2501 functionality, I have a more solid approach to building the view, controller and model objects for each device. I am also clear on how to make updates across threads, since parts of each device run in their own threads but GUI actions must all occur in the main thread.

The updated window for the 2501 now displays the count of cards sitting in the virtual card hopper. It added an NPRO button (non-process runout is how you empty a card reader) to clear out the hopper and set the device not ready.

When the user clicks buttons or icons on the graphic window for a device, those actions are handled by the view module. It runs in the main thread. It may present dialogs to select files as part of the process - for example when clicking the card deck icon to load more cards in the 2501 hopper. The card images and updated card count are updated by a call to the model module, which maintains the state of the device. Checking modes like binary cards or last card will also call the model module to update state. The view module can be triggered by an event if the controller, in another thread, wants the view to update.

The controller module runs the main processing for the device in a separate thread. This module is what sticks requests on the queue to be issued to the fpga board. The controller module must check the state of the device as well as ask for card images from the model module. While this is a cross thread operation, it does not need any locking. If the controller module sees it has updated the state of the device which should be reflected on the GUI, it sticks a custom event in the queue which is processed by the view module under the main thread.

Thus, the view and controller modules each communicate only with the model module. The controller can trigger a custom event that is processed by the view module, but it is not calling directly thus the event switches threads.

Both 2310 and 2501 devices active with files loaded
After the screen image I saved above, I changed the icon of the punched card to a obvious deck of card picture. I think I have the 2310, 1627, 1134 and 2501 code ready to test, the 1403 printer code mostly completed, and am starting in on the 1442 restructuring. Still to be worked on are the mirror 1132 printer, mirror 1053 printer, mirror console entry switches, and the core memory loading function.

Control panel for 1403 printer function
New version of 2501 panel with card deck icon
I did take some time to refactor some code, although often that involves a dive into fine points of how Python works that chews up some time. This involves building strings that will become pointers or function objects, making use of the functions like getattr, setattr and delattr that manipulate name spaces.
Control panel for 1442 - note files for input hopper and output stackers

Friday, May 6, 2016

Completing 2310 and 2501 device implementations


Restructuring the GUI

The 2310 function is converted and ready for testing. The virtual disk drive pops up a window with a picture of a disk cartridge to its right, the name of the PC file that is mounted on the virtual drive. Two lamp blocks are in the window, Disk Unlock and File Ready, which harken to the two lamp blocks on the keyboard panel of the 1130.

When it starts, the file name is **empty**, Disk Unlock is 'lit' and File Ready is dimmed out. Clicking on the 2315 cartridge icon brings up a file open dialog where the user selects a suitable file. The file is opened, validated, the file name is displayed, the Disk Unlock lamp is dimmed out and the File Ready lamp is 'lit'.

I then worked on completing the 2501 card reader function, building a window that pops up when the device is activated. It has an icon of a punched card and the name of the PC file to its right (or **hopper empty** when no file is open). A button, Prog Load and a lamp block, Ready, are on the next row. Finally, three checkboxes run across the bottom row - one to set up the last card status and two to choose between 029 and binary file modes.

The 2501 device is more complex, with more state information in the model and more fpga interactions. I also must decide whether to expose some of the state as output on the GUI window - such as card deck size and current card being processed.

I have icons for the other PC file types to open for the remaining device types - punch cards, a sheet of printout and core memory - which will be placed in the windows for those device types.

Wednesday, May 4, 2016

Restoration work on 1442, plotter and more development of new GUI


I did some filing down on the UV curable plastic I bonded on the punch drive wheel to replace the cracked segment. I was pleased to find that it could be worked as promised. Next step is to be sure it is built up higher than the target diameter, so that my machining will all be subtractive to yield the intended surface.

I need to build a jig that will keep the outer face of the wheel, the perimeter that will contact cards, at the right distance to a rotary grinding tool. Then, I can slowly rotate the wheel to move the built-up sections along the repaired arc, grinding them down at the right diameter. The final step will be to coat some grit balls with the UV resin, place them on the repaired arc and cure them in place with UV.

The original wheel is a ceramic that has big grit balls embedded on the outer face. These grit 'balls' are the gripping mechanism to pull the card along. As long as I have the replacement section so its initial diameter is the same as the original's diameter in between grit balls, and make the balls the same size, it should all work.


Restructuring the GUI

Worked on the logic to fire up a device handler when the Device menu is selected, or to stop it when the user wants it deactivated. Each handler puts up a control panel window which will contain buttons and status displays. As a test of the concept, I built up the 2310 disk drive panel and am still tweaking it.

Now I am splitting the logic for all my devices into the model, controller and view portions - laborious but the heart of the restructuring. Models hold the device state, controllers communicate with the fpga and views control the on screen GUI elements.


My connector arrived last night and looks perfect! It fits the connector on the rear of the plotter, although I want to clean up the contacts and pins a bit to make sure it is solid. I am still waiting for a quote from the metalworker for the task of removing the dent in the plotter drum.

New connector tested for fit