Week ending October 6 - typewriter almost done

TYPEWRITER

I began recoding the Arduino to use the 1130 typeball codes, as the position on the typeball is different for BCD type elements such as this one. Although I had believed that the 1130 codes were the inverse of the desired tilt and rotate magnet activations, I was wrong. It is a direct map of all codes with one systematic difference.

Stripped down typewriter mechanism with interface board, during testing

The Memory Typewriter 50 selects the home position of the typeball with R1, R2, and R2A activated but the 1130's mechanism (an IO Selectric) uses just R5 for this position. Thus, the 1130 issues rotate values 0001 for the characters 0, |, -, ?, &, >, @, and % yet I need to issue them as the inverse pattern 1110 just for these eight characters. I have updated the adapter logic to make this swap.

Before I take the wires off the Arduino and move them to the fpga adapter logic, I tested out my ideas for how to remove and disable the other buttons on the typewriter, running a test program to print some output with none of the original buttons on the typewriter connected to the planar.

When that worked properly, I then tested the behavior of the system with the connector #1 on the planar disconnected - this connects the internal tape drive signals. That however did not work out well. The red system light blinks, showing that the planar board is not seeing what it expects from the tape drive, keeping the unit from working as a typewriter.

I am going to have to relocate the tape drive under the printer, even though I am not going to be using it, simply to keep the planar happy.

Power Supply to rear, tape drive in front, detached and ready to relocate under typewriter

I did a run on the machine with these new typeball encodings and was satisfied that everything came out correctly. I was also able to detach the tape drive from the cover and relocate it without any negative effect on the typewriter. I will try moving the power supply and then the planar on Tuesday.

I discovered that if I don't do an explicit shift of the ball between upper and lower case before typing letters from that side of the element, the machine throws in a hidden shift cycle. This adds enough delay that my timing routines were commanding the next character to print before the prior one had finished, resulting in loss of the intended character.

Fortunately, the 1130 adapter logic built by IBM for the 1052 console does this - it shadows the state of the typeball and creates a separate shift cycle whenever the ball has to flip to the other side. That way, it is a separate cycle whose timing matches with the logic, instead of an unpredictable delay in the timing of a regular character print operation.

The last testing I wanted to do using the Arduino as a test driver was to use the feedback signal to see if I can issue a followup character request without timed delays and without loss of any keystrokes. Right now I have to set a fixed delay which is long enough to work if there is no hidden shift cycle. If I can drive the next character as soon as feedback goes back to 1, I could be comfortable that I have the timing control locked in.

The test worked superbly. The only aspect I didn't yet test was using the Interlock signal to hold off for those long movements like carrier return, index and tab operations - I retain the delays to cover these long operations and will test the interlock logic later.

The conclusion of this testing means that I can remove the physical buttons, wire up the default states for those that are not driven by my circuit board and neatly route the wiring as the printer is now usable by the 1130. I had to remove the various buttons surrounding the keyboard, wire their desired 'state' onto the removed connectors, strip off the tape storage unit and rotary track selector unit.

The power supply and planar board had to be relocated to sit beneath the typewriter, not to the rear and right of the mechanism, in order to fit within the enclosure size of the 1052 printer. So far I have moved the tape drive and power supply off the cover but not yet relocated the wiring that would allow them to sit below the typewriter.

The next step was to disconnect the planar assembly (logic board) from the rear of the typewriter so that it could be moved downward to sit below the back of the mechanism rather than behind it (hidden inside my frame). The planar assembly has many cables hooking into it, but the length of all connectors were verified to be long enough to support the desired positioning within the 1130 frame.

Planar (logic board) detached and sitting to rear of mechanism

I had to put together a stand that would hold the typewriter mechanism up in the air above the relocated parts - I slapped together a quick stand with some wood in my shop. At each step in physically changing the typewriter, I re-ran the Arduino test program and verified that nothing was inadvertently broken or disconnected.

The keyboard itself and its linkage to the motor and wiring harnesses had to be removed from the front of the mechanism, in order to fit in the space of a 1052 enclosure. The bell and its magnet also have to be relocated to the underneath; they are currently attached to the keyboard mechanism I will be removing.

After starting in on the keyboard removal, which is absolutely mandatory in order to fit in the 1130 enclosure and dimensions, I came to the conclusion that my original aim, to be able to restore the typewriter at some future time to its original working condition using all original parts, was not feasible. There are just too many connections and adjustments involved. I have shifted to plan B, which is to create an effective console printer by permanently removing or disconnecting unneeded parts.

This simplifies the connection of sensor wires to various reed switches, as I can cut and solder the wires leading to the switches as a way of tapping into the signals. I rerouted the power supply cables from the right side, currently they are stretching out of the rear but soon I will move them downward to connect to the power supply sitting underneath the working typewriter mechanism.

Disassembly of the keyboard was very difficult - the parts manual diagrams are not designed to show how to assemble or disassemble parts of the machine, only how to order a particular part by its number. I have reached the point where I have two small hinge pins that are all that holds the keyboard extension to the rest of the machine.

I kept removing components both from the inside and outside to get closer and closer to the point where I can take off the two end plates. I now have a pile of many hundreds of parts, some very small, but finally completed the removal. I have one cap to reattach, which holds the pivot bar for selecting the character to type, and have to properly adjust a bar that runs just under the front of the carrier across the width of the typewriter, since I had to loosen one screw to remove the keyboard mechanism.

Left side view of typewriter mechanism after removal of keyboard. Solenoids at lower right.

Left side view of typewriter mechanism, front plate of enclosure will sit above the solenoids

I also found that I needed a firm anchor for the spring that holds the margin bar in position but allows it to rotate for margin release. I improvised an anchor point by putting together a few of the removed components with judicious reshaping. Similarly, I was able to secure the cap on the pivot bar and to lock the front bar in place. The machine appears to be mechanically ready for operation, once I move it to its new frame..

The front 'feet' that the typewriter sits upon in its cover, as well as on my wood frame, may be attached to the sides of the now-removed keyboard. I am working on alternate mounting methods to hold up the front of the typewriter. Once done, I can do a test with the Arduino to prove out the soundness of the mechanism before I move on.

The power supply is not developing full power - the 24V lines are at 15V and the logic signals are down are 2V. I will be debugging the power supply - the diagnostic manual mentions that the power supply can drop into low voltage mode as a protective strategy and will reset itself after a power-down.

The power supply did reset and develop full voltage. The typewriter was not operating, however, which turned out to be a lose connection to my Arduino tester. It is working perfectly in its fully stripped down mode and ready to move on to the next stage of its conversion to an 1130 console printer.

I removed the link to the low velocity magnet to cause the typewriter to strike every character with equal force. The BCD style typeball I am using places characters at different positions than they are on ordinary (correspondence) balls, yet the typewriter is varying force based on what letter it 'thinks' is being typed due to the correspondence layout.

After pulling the link, I ran the Arduino test but learned that the low velocity magnet is apparently also involved in the no-print cycles, since now I saw a 0 typed for every dummy cycle to launch a tab or return movement. I need to study the behavior of these two magnets a bit more, then make a more suitable rewiring that gives me the constant strike force typing but blocks print in dummy cycles.

Nothing in the documentation makes clear how these two magnets - low velocity and no-print - are actuated for the three states of a normal strike, low velocity strike or no-print cycle. I will have to throw together a couple of voltage dividers (to get the voltage down to 3.3V from 24) and monitor the lines with my logic analyzer to understand how each of the three types work.

The logic analyzer shows that low velocity characters are selected by firing the low velocity magnet alone, but that no-print or dummy cycles require that both the no-print and low-velocity magnets fire. This adds a complication. If I pull the control line off the low-velocity magnet, then dummy cycles will type spurious characters onto the paper. I would need to fire both magnets when the no-print control line is activated but do nothing for the low-velocity control line operating by itself.

If I were to naively bridge the control line from the no-print magnet to also drive the low-velocity magnet, then the effective resistance would be half and the current draw would double for that control line. I am not confident that it is able to safely handle that load and won't take the risk of damaging my planar (logic board) by a test.

Instead, I must design a small driver circuit that will drive both magnets safely when it sees the no-print control line activate. Activation of the control line means that the line will sink 24V through it, with the magnets hooked to 24V on one side and the control line on the other. Thus, grounding the control line causes the 24V supply to drive 100ma through the magnet coil. My circuit will have to sink 100ma per coil with both operating simultaneously, activated by the grounding of the no-print control line.

The deactivation of dual-velocity behavior is a nicety, not an essential interfacing task, thus I will proceed with my other work on the typewriter and come back later to hook in this new circuit. I shot a video of the typewriter printing some text at full speed and posted that on YouTube. The link to watch:  Youtube video of typewriter mechanism during testing and you will see this typing with the Arduino driving it, using the BCD type element layout and the type ball I found that almost perfectly matches the 1130 printer.

I also improved the Arduino code, allowing the timing of the next character to be controlled totally by my instantiated interlock and feedback signals. It is now running full throttle for typing, shifting, returns, index, space and tab operations. You see that in the video above. This all works flawlessly, but the more critical test will be operating with the IBM typewriter adapter logic, because that is timing dependent too with some very specific assumptions built into the design.

Underside of mechanism plus temporary connections to my interface board

It was time to shorten and clean up the wiring, make it more permanent and dress the wiring away from moving parts. Having done the work, I gave the system a try to validate that everything was still working properly. Alas, the machine hung up after executing the first carrier return.

The cause is the failure of the overbank switch to activate when the carrier reaches the left margin. I have to investigate the cause - it isn't immediately apparent why it is no longer working, but may be the consequence of my cable ties or the new permanent wiring to that switch.

I found the root cause - the ground lugs that attached to the right hand set of keyboard buttons - functions like Auto Playback and Skip to Next Line - appeared to be both connected to ground, but one of the two was a wire that only connected to the overbank switch to provide ground to that board. The keyboard buttons provided the link between this wire and the other, true, ground wires. By removing the buttons I broke the ground circuit.

It was a simple matter to hook up a new line to provide ground to the overbank switch, after which the test code in the Arduino drove the typewriter to another flawless performance. I have a bit more dressing of cables and other tweaks but basically this is now ready for me to set up the permanent new 'feet' for the front and then to design and build the '1053' enclosure that will house the typewriter. 

DISPLAY PEDESTAL CONSTRUCTION

The plexiglass panel for the front of the display pedestal had been mounted using plastic tabs epoxied onto the back, but since the epoxy was actually onto a layer of paint, I was living on borrowed time. The luck ran out about a month ago and one of the tabs ripped off, removing a nice roughly circular patch of paint along with it. The panel had a clear circular defect that was very visible. 

Since this panel has taken hundreds of hours of work to get to the point it had reached, and considering that almost any change I made recently ended up introducing a new problem or perhaps worsening the overall quality, I was loathe to move too quickly. I set it aside for a 'cooling off period' while I processed the panel situation subconsciously. I was waiting for inspiration on how to achieve the mounting without those troublesome epoxied tabs as well as a way to repair the panel without inducing more damage.

I finally was ready to act. I have just finished spraying a new coat of black paint over the section that was ripped off. I was very fortunate that the damaged area was away from all the lighted lettering, else repair would have been ten times harder. I still have the risk of bubbling paint or other malfunctions from the new coat, but at least the ultimate goal is simply to make the are opaque. 

The good news is no bubbling is occurring; the bad news is that the paint layer wasn't heavy enough to darken the opening more than about 25% opaqueness. I am hoping that if I put some black material behind it to block light and reflections, it will be only marginally noticeable. Once again, overall quality of the panel sags a bit. It is getting hard to believe that any fix I can apply won't bring its own further drop in net quality. I am leaning to stopping now and accepting the shoddiness (to me). I know it will be hard to feel much pride in the look of that portion of the machine, but I just couldn't bear spending months and hundreds of hours to redo this from the ground up. 

I am drawing up several options for mounting the panel onto the pedestal, will consider their practicality and the degree to which I can execute on the plan, then move ahead once I decide. The torn tab occurred as I was closing up the rear of the pedestal, believing it to be ready for a full scale test and then mounting onto the frame. Everything is on hold, though, until I sort out the plexiglass panel and its attachment.

QUICK RESEARCH FOR A FRIEND

I was asked to visit the Computer History Museum to get some pictures of the 360/30 system on display there. A friend is building a scale replica of the physical machine to run his fgpa based implementation. He wanted to look more closely at some details of the corners and attachments. In addition, another person building a replica needed to know the height of the table attached to the front of a 360/65 system. It only took 20 minutes to take plenty of pictures and take the measurement, not counting the ten minute drive from my home.

LIMITED ACCESS TO MACHINE FOR NEXT ELEVEN DAYS

I will be away on a business trip beginning Sunday October 6, only able to work on soft aspects of the machine such as design and VHDL coding, but nothing that requires access to the physical parts of the project. I will most likely not post anything further until Sunday October 20th. 

Week ending Oct 20, 2013 - short week

CONSOLE PRINTER (TYPEWRITER) INTERFACE TESTING

I used the logic analyzer to verify the reasonableness of the feedback signals I will be generating in my fpga logic to pass to the IBM provided printer adapter logic. It is time to move on to driving the typewriter with the actual fpga rather than my Arduino based test exerciser. The pins on the cable that connected to the Arduino will plug into an fpga extender board I own, allowing me to test with the fpga board before wiring the cables permanently into the 1130 replica.

After carefully sorting out the connections, including a passthrough of the derived feedback signals to allow them to be monitored by the logic analyzer, I was ready for some testing.

A friend made some spare parts available to let me replace the ad-hoc cover and reed switch with original equipment components. I swapped these in and verified their operation. I did some basic testing with the fpga adapter, using a short diagnostic routine from IBM that drives the typewriter in flexible ways. I uncovered some defects in my adapter logic and corrected them, a few at a time.

Once the initial code defects were cleaned up, I had a few anomalies to troubleshoot but most of the functionality appeared solid. The three obvious problems encountered were:
    - Tab didn't work, but all other movement commands were fine
    - Alternating between upper and lower case on each pair of characters when both are identical
    - End of Line status was always set

I discovered I had mistyped the code for Tab, that the shift status feedback from the MT50 mechanism was the inverse of what I expected, and that I had a subtle flaw in my end of line routine. With all that corrected, everything appeared to work perfectly except for a hangup when it did an automatic new line - typing past the right margin setting.  This is going to take some debugging as the situation isn't obvious.

I did verify all the characters, movement operations like tab and return and backspace, and subject it to a fairly stringent testing. Outside of the automatic new line, all is good. That said, I still haven't tested the buttons for 'tab set', 'tab clear', 'set right margin' and button alternatives for space, return and tab. I only need to wire up buttons and configure the signals into the fpga to accomplish that testing and the functions look pretty straightforward, but the job isn't done until these are all tested (and my automatic line return works).

I suspect this is caused by an unwanted interaction between the IBM adapter logic and my adapter logic. I will be studying the IBM logic to see if I can spot where its expectations and assumptions are different from my actions in my adapter. If that doesn't work, I will need to spend some time instrumenting the right signals to the logic analyzer and try to capture the point at which things go awry.

I was still running analyzer traces by the end of the weekend, getting closer but still not seeing exactly where things are going awry. I think I can now trigger on the conditions that will capture the incriminating signal sequences in my buffer, but ran out of time. It will have to wait until some time during the week.

REPAIR OF TYPEWRITER POWER SUPPLIES FOR FRIEND

I received the two malfunctioning power supplies for IBM Memory Typewriters, sent to me by a friend who repairs and collects these systems. A wizard with mechanical issues, which is 99% of the work dealing with the typewriters, he is less equipped to deal with electronic issues. IBM does not provide any schematics of the power supplies or circuit boards, treating those entire units as the field replaceable unit. If it isn't working, toss the entire power supply out and replace it.

I had offered to look inside and see if I could get them working again. The first of the two, whose symptom was that the 24V power line only delivered 12V, was pretty straightforward to debug. One of the two diode was bad; these collectively convert the 24V AC output of the transformer to 24V DC. If one is open, the DC voltage will be 12V (and with more 'noise'). I borrowed a diode from the second power supply, installed it, and tested the power supply. It ran perfectly, delivering the rated voltages on the connector. Further, I hooked it to my memory 50 typewriter mechanism and ran my test printing successfully.

These power supplies are 'world trade' versions, set to run on 240V/50Hz power, but with easy switching of the input voltage. This saved me from having to wire up 240V to the supply. I was able to switch it to 120V for my testing, which with US voltage levels delivered the same 12V incorrect output before repair and operated exactly on spec after the repair. The difference in frequency, 50Hz versus 60Hz, has a very slight effect on the efficiency of the transformer but not enough to matter while I tested it with 120V. My last act after the testing was to reset the switch to 240V for its next use back in Switzerland.

I ordered a handful of superior diodes to use on power supply #2, handling higher reverse voltage, more power, faster response as voltage swings from reverse to forward, lower voltage drop, ROHS certified and lower leakage. These are still inexpensive, a handful of coins apiece, but will ensure that the power supply works reliably for many years to come.

The diodes arrived Saturday, earlier than expected, and were put into the power supply that evening. Initial testing shows that the supply is delivering the right voltage on all but one pin of the power connector. The -12V supply on pin 3 is reading just under -8V. I will have to do some more troubleshooting and look closer at the section of the supply that is responsible for -12V, to uncover the failing or misadjusted parts.

This supply had never worked properly, according to Lukas, but the fact that it is already working properly for five of the six voltages makes me a bit optimistic that whatever is wrong is localized, simple and could be corrected with available parts. There is even an alternative to consider if the -12V portion is damaged in one of the custom ICs for which I have no replacement. I could put together a small daughterboard circuit to regulate -12V, fed from the supply on the power supply's board, mount that somehow and make the supply fully operational even if no longer IBM standard.

When I began inspecting it more closely, I found that a transistor had been unsoldered and removed from the power supply at some time in the past, probably before my friend owned it, since it was never functional for him. By comparing to the repaired and working power supply, I know the part is an IBM 205 transistor. IBM labeled their transistors with their own numbers, unrelated to any standard numbering by other manufacturers. That was even true for transistors made by other companies on behalf of IBM, such as this one produced by Motorola.

Using some cross reference documents uncovered by the 1401 restoration team, I found that the IBM transistor is the equivalent of a 2N2904 transistor, thus I could order a replacement. When it arrives, I will install it into the power supply and test it again to see if the -12V portion is now working properly. If not, I will do more diagnosis.

Once successful, I can mail the two back to my friend Lukas, who has been a great help in dealing with both of my typewriters, the Electronic Typewriter Model 50 and the Memory Typewriter, plus having rare spare parts when I needed them. I feel good that I can reciprocate for the help he gave to me (and to many others on the Golfball Typewriter forum who he has helped).

COMPUTER HISTORY MUSEUM PAPER TAPE READER AND PUNCH INTERFACE

I have the documentation for a virtual tape drive emulator that was built as part of the 1401 restoration project. I will leverage this to stream data to and from the paper tape units, which will appear to be a pair of tape drives to the 1401. It maps BCD characters on the 1401 to ASCII, as I do with the data on the paper tape. Once I synchronize my mapping of BCD to ASCII, so that a 1401 character such as group mark will be turned into an ASCII character by my interface and then recognized by the virtual tape emulator to produce the group mark going into the 1401.

The only complication is that the emulator is accessed using a web browser to connect to a PC web server that is part of the emulator unit. This runs a Java based graphical interface to select ASCII files to upload from browser to the virtual tape drive (or vice versa to fetch data from 1401 into an ASCII file on the machine running the web browser). This introduces some human intervention to read paper tape files or to punch output files, clicking on the graphical interface and selecting files with an 'open' or 'save' dialog box from the browser. If I could drive it programmatically, removing the human intervention, it would be preferable. I need more detail before I can determine if that is reasonable to do.

Apparently there is another option, an interface using RS232 (serial link) to the console typewriter of the 1401, which is much simpler to link to. I am discussing ways to use this with one of the team members who helped build this. I will make a decision on the method to use over the next week, then code up my paper tape interface machinery appropriately.

DISPLAY PEDESTAL WORK

I sprayed some additional layers on the back of the plexiglass panel, to cover up the ripped open circular defect that has marred the appearance. I suspect it will always be slightly visible, but if I can minimize the contrast with the undamaged layers, it won't be grossly evident when looking at the system.

I have some careful work to do, drilling holes in the panel and in the flange of the pedestal box, gluing some sections of acrylic rod to the panel back and mounting it with this new method. The two side metal panels could also use a better attachment. As well, I want to redo the mounting of the light blocks inside the pedestal box. Finally, I need to bolster the rectangular stands for the box, to ensure it will be sufficiently rigid.

ASSIST OF BINGHAMTON COMPUTER HISTORY MUSEUM IN ACQUIRING KEYPUNCH

A co-worker who lives near Akron, Ohio where the keypunch is being offered has very kindly agreed to pick it up and store it for a couple of weeks while the museum works out crating and shipment, since the seller requires it to be picked up by Monday, an impossibly short deadline otherwise. My friend will take it in a pickup truck and put it into his garage, then meet the shippers to hand it off later.

All this was contingent on the museum acquiring this. There are 13 other 'watchers' of this auction on ebay, which might mean one or more other potential buyers could be dropping in last second bids. In the end, however, they did make the purchase and we are now arranging the details for my friend to take possession on Monday morning then hand it off in a couple of weeks to the shippers for the museum to bring it to Binghamton, NY where it will be restored and used as part of their restored and operation IBM 1460 mainframe.

The seller and the museum engaged in some discussions for an alternative that wouldn't require my buddies help, with the seller bringing the keypunch on a moving truck to his new apartment in NYC and the museum retrieving it from the truck. It appears the logistics of that plan were too complex to pull off, so the keypunch will be moved from the sellers location to a garage nearby in Ohio for a couple of weeks.

week ending Oct 27, 2013 - progress report

CONSOLE TYPEWRITER DEBUGGING AND CONSTRUCTION

After battling my way through the failure of the automatic new line function, where the logic hung up after the return, I finally got to the root of the problem. Ugh. When I switched from the Electronic 50 typewriter to the Memory typewriter mechanism, I reused the input-output pins of the fpga for the new signals. I carefully changed them to the new signal names, but forgot to look closely at some parameters I had on there.

Specifically, some of the switches and sensors on the ET50 needed the port to be set with a pullup resistor, so that it floated to level 1 unless the switch was grounded. The Memory 50 interface,on the other hand, is driven by its logic board and will drive to either 1 or 0 by itself. Leaving the pullup activated kept the fpga from getting a reliable switch to 0 when the solenoids fired, because the pullup interacted with my incoming signal. The result was that my logic was not seeing many of the solenoids I believed I was watching. Since the carrier return and escapement solenoids were two that had this flaw, they were never detected.

That was why my adapter didn't work correctly. Once I saw the problem and removed the pullup directive, the automatic new line worked flawlessly. When I set the IBM diagnostics to continually type letters, it would type until the right margin, return automatically and continue typing from where it left off, all without a hitch.

Days wasted, but in the end it is working quite well. The testing of the tab set, tab clear, right margin setting and typewriter command buttons began Monday night. Setting the right margin was easy to test - I spaced over about half the normal distance, pressed the button to set the margin, then did a return. When I ran the
diagnostics to type away, the automatic new line occured exactly as expected.

The only challenge I see is that once the margin is set to some point, it is not possible to space or type beyond that point to set the new longer margin. I will have to add a circuit to block the recognition of the bell, for when I need a 'margin release' for the right margin, perhaps tied to the physical margin release I will have rigged up to release the left margin.

I added some logic to run at startup time to force the typewriter to the lower case state and put it at the left margin, to sync with the expectations of the 1130 typewriter adapter logic. I am still testing this, as initially I didn't fire the strobe to activate the two requests. The tab set and tab clear aren't working, which I suspect is a matter of timing. I am only 'holding down' the button for 10 milliseconds, which the logic board might be blocking with it debouncing. I have increased the pushdown time to almost half a second, which should be enough.

The final test of the typewriter interface and my adapter logic exercised the set right margin , tab set, and tab clear buttons plus the typewriter mounted space, return and backspace buttons, then finally the correct startup time behavior. The test showed the adapter logic is working as intended and reliably. Nothing more has to be done to the adapter logic. I ran the IBM written typewriter diagnostics first and worked it at maximum speed to verify all functions. I then executed a short 1130 program I hand coded and entered into the system - it exercised the programmatic interface for starting IO, handling status and interrupts while it wrote some text to the console printer at maximum speed. Once again, this worked perfectly.

Quick video of a program running in the 1130 writing a short message to the console printer Video demonstration

Printer mechanism during video recording of a test

What remains are hardware tasks - making a modification to the typewriter so that it uses a single uniform strike velocity for all characters, building a 1053 style housing and mounting it on the 1130 system frame. As well, the escapement mechanism is slightly out of adjustment, showing up on the tab test of the diagnostics and once in a while when printing many lines of identical text where slight misalignment is most visible, so I will fix this up.

I have designed a modification to convert the mechanism to monovelocity rather than the built-in low and high velocity force assigned to characters. These assignments are based on typewriter (correspondence) format typeballs but are inappropriate to use with my 1130 layout typeball. My circuit will fire both the low-velocity and no-print solenoids whenever the logic board attempts to fire the no-print solenoid line, while I ignore the line activating the low-velocity solenoid.

The typewriter activates the low-velocity solenoid by itself to print with low velocity, but activate BOTH low and no-print solenoids to block printing. Any time the no-print solenoid line is activated by the logic board, it means it is also activating the low-velocity line, but the low-velocity is sometimes activated by itself for characters it wants to strike lightly. I fire both anytime the no-print line comes on, which implements a non-printing cycle, but unhook the low velocity signal wire from the logic board. My circuit drives both solenoids from the single logic line activation.This will disable the dual-velocity feature, giving me the monovelocity behavior of the 1053 printer used on the 1130 system.

I have breadboarded the circuit, am adjusting component values to fine-tune its operation at this time, then will build a mini-board with the circuit and hook it into the typewriter mechanism for testing. The completed miniboard is ready for testing next week.

Minicircuit to disable low velocity mode on typewriter mechanism

I have a temporary frame on the typewriter allowing it to be free standing while I measure and plan the enclosure to turn it into a visual replica of a 1053 printer.

TYPEWRITER POWER SUPPLY REPAIR FOR A FRIEND

The replacement transistor arrived on Wednesday, I soldered it into place and the power supply is now working perfectly. Both are repaired and ready to mail back to my friend Lukas in Switzerland. Very happy I could help him out like this and without taking much time at all.

I repacking them in a sturdy box with solid padding and mailed it back to him on Thursday. Should arrive in a bit more than a week.

INSTALLING 1401 MAINFRAMES AT CHM

This week, the two 1401 systems and their peripherals were ready to be installed in their new facility where visitors to the museum will view them in operation. I helped line them up, plan the floor openings and worked out details in the tight and irregularly shaped space in which it will go. By the end of Saturday, we had all the power and signal cables hooked up for both machines, and succeeded getting the CT - "Connecticut" -machine running with everything except the tape drives which will be hooked up later in the week.

Beginning to open floor tiles and install cables

                                                       Photos of install work taken by Ed Thelan

The other 1401 system, DE or "German", wouldn't power up when we attempted it. It appeared that we had a problem with the power being delivered to the system. The DE system came from Germany which means it was set up for 50Hz power. The museum has a full rack of power equipment that converts building electricity to 50Hz 220V three phase in order to drive the DE system's units, which makes this a bit more complicated than the other system.

The only changes that occurred were moving the machinery and electricians wiring them in place. Likely there is something off in how the main power feed is wired, as the 1402 box that receives it won't complete its power up sequence. The team will be looking at the power more closely on Monday.

Swapping phases of input power on CT system

It was great to see the CT system power right up, pass diagnostics and run some simple programs to list card decks on the 1403 printer. The work of cabling these was physically demanding. The cables are thick and plastic sheathed, between one and two inches in diameter and up to thirty feet long. They have large connectors on the end as well or printed circuit cards hanging off individual wires coming out of the cable end.  They had to be placed under the raised floor tiles in the room. Tiles had to be lifted out of the floor, the cables threaded along around the metal 'feet' that hold the the floor, power and water pipes, and the scattered sprinkler heads that would have flooded the room if we had banged into one.

Me diving under floor to push cable to Frank King. See some cables snaking down at right

Our boxes were closer together than the cable lengths, which meant we had to figure out a big looping path that would keep them out of the way of airflow or other cables, avoid sharp bends in the cable, all while bringing the connectors on the end up through holes in the floor tiles at just the right height and location to fit into each box. Several of the cables were run under the part of the raised floor where visitors will walk, as it would have no need for cooling airflow, others had to be placed under the parts of the floor which were the gaps between boxes.

The museum will open the facility to the public on the 20th of November, which gives us less than a month to get everything up and running properly, then train all the presenters and operators who will conduct the demonstrations. The work this weekend puts us well ahead of schedule, versus the requirement that we have the CT system cabled but not yet powered up and that the DE system might not have been touched at all.

BIZ TRAVEL INDUCED IDLE PERIOD TIL NOV 9

TIME AWAY

I am traveling to Brazil and won't be back to work on anything until November 9th, when I can resume work on various aspects of the project.

TWIN 1401 SYSTEMS INSTALLATION AT COMPUTER HISTORY MUSEUM

The electrician had indeed wired the 1401 incorrectly to the 50Hz converter. Once that was diagnosed and fixed on Monday morning, the power came right up. The DE (German) system is now up, but its first 4K of memory is not working properly. Ron Williams was still troubleshooting this by the end of the day.

We hooked the first tape drive of each system to its 1401 processor and laid out the cables to run from tape drive to tape drive. The floor tiles must be cut to allow the cables to be connected, something that will be done by a contractor. Frank King and I marked out the tile cuts for the CT system tape drives, while Stan Paddock and others worked on the DE system drives.

Once the drives are fully connected, the floor tiles with cutouts and protective rims are all in place and the memory defect is fixed on the DE system, both 1401 systems will be completely operational, ready for the unveiling to the public later in November.

CONSOLE PRINTER (TYPEWRITER) COMPLETION

It was time to test it with the system for producing monovelocity typing. For some reason, it is failing to work properly. The first few runs gave me an apparently correct behavior, althought the letter E, which is one that gets a low velocity signal, looked just as faint as before. When I turned it back on with a minor change to test out something, I found it was now blocking all print.

When I pulled the circuit out, I then had even the dummy cycles striking, which makes sense, but the no-print line from the logic board should be 24V for all printables and my circuit should leave the solenoids alone. It has stopped working right, which could be failure of one of the two transistors in the mini circuit board leaving it permanently on, or it could be something more subtle. I will have to wait to diagnose this until I get back.

I also ran a test of the margin release button, to validate that I could block the auto new line function in order to space over if the right margin needs to be set further to the right than its initial setting. It turns out that I don't need this, I can just use the tab and space buttons on the front of the typewriter to move beyond the current margin to the location where I wish to issue the set right margin command. I will remove the unneeded logic for the margin release and can 'sign off' on the adapter logic as final.

Back in the workshop, week ending Nov 10

CONSOLE PRINTER (TYPEWRITER) WORK

During the trip, I did some thinking about the approach I was taking to implement a monovelocity behavior for the Memory typewriter mechanism, in order to avoid the light strikes inappropriately used with some letters (e.g. E and K) because they sit in the location on the typeball that are used for punctuation on ordinary typewriter (correspondence) format type elements.

I need to recognize when the no-print solenoid is being activated by the typewriter logic board and cause the low-velocity solenoid to be simultaneously activated. This is because a no-print cycle requires BOTH solenoids to be activated; I can't simply disable the low-velocity solenoid or the typewriter will print unintended characters instead of spaces, tabs and other nonprinting actions. My first approach removed both low-velocity and no-print solenoids from logic board control, counted on the no-print line from the logic board to be driven down to ground when it wanted an activation otherwise floating at 24V.

This first approach was not reliable. While I have not had the chance to measure the actual behavior, I suspect that it needs the solenoid or an equivalent resistance in order to work correctly. Since I do want the no-print solenoid to fire, it can be left attached to the logic board. In this case, the logic board will really be controlling that solenoid. My circuit just has to recognize when the no-print solenoid is firing and drive the low-velocity solenoid at the same time.

I have a reliable means of sensing the activation of solenoids by the logic board, used to detect use of the carrier return, index and other solenoids. I will use the same approach to drive my circuit, so that when the no-print turn-on is detected, I immediately pull the line from the low-velocity solenoid down to ground which fires it. I thought through various options for the circuitry to put on my mini-board - schmitt trigger versus simple drive of the power transistor, for example - before I settled on my new circuit.

Ultimately, I used a simple pair of transistors, the first inverting the sense of the signal since the solenoid is fired by pulling its line down to ground, else it is at +24V. When the logic board pulls the no-print solenoid to ground, I want to simultaneously pull the low-velocity solenoid to ground, otherwise let it float to +24V the same as the logic board would have done. I am ignoring the logic board signal to fire the low-velocity solenoid, instead causing low-velocity to always mirror no-print.

 I wanted to drop the voltage coming from the logic board to the no-print solenoid to a safe voltage by a divider network. My circuit uses the lowered level to fire the first transistor whenever the solenoid is off, buts shuts off the transistor when the solenoid is activated by the logic board grounding the no-print line.

I built another voltage divider to bring the typewriter's +24V supply voltage down to a safe level for the second transistor base; my first transistor will pull that base level down to ground. Thus, when the first transistor is conducting, it holds the second transistor off. The second transistor is hooked to the low-velocity solenoid, pulling it down to ground when the transistor is conducting.

As the logic board line to no-print goes to ground to fire that solenoid, it releases the first transistor, which in turn stops pulling the second transistor base down to ground. With the second transistor base free to pull up to my divider voltage, the second transistor fires and pulls the low-velocity solenoid down to ground, exactly the way that the logic board would have done things if I left it connected.

Since the low-velocity line from the logic board is no unconnected, if the logic board tries to type a character with low velocity, it has no effect. If it had been left connected, it would result in only the low-velocity solenoid firing, which causes a light typed impression. Since it takes both solenoids to block the typing of a character entirely, I needed to mirror the no-print solenoid action to the low-velocity solenoid to give me the desired blank space on the paper.

Everything was designed and parts values were selected during my trip, to allow me to quickly wire it together when I returned home. I soldered it up and began testing. I uncovered a mistake in the board, corrected it and prepared to test another time.

In parallel, I had looked at the main logic board (planar board in IBM parlance) and satisfied myself that the no-print control line, which pulls the solenoid to ground to fire it, could easily handle both solenoids. Thus, I moved the two solenoid leads to the one logic board output for no-print and tested.

This worked just fine, without a need for a separate circuit board. I ran tests to confirm that this printed all characters with high velocity and handled non-printing operations correctly. With this test, the console printer adapter logic and hardware is complete. I can move on to the physical enclosure and mounting of that 1053-like box onto the 1130 frame.

DISPLAY PEDESTAL COMPLETION

The link to the electronics in the pedestal box continues to cause problems due to impedance mismatch on the long cable. The mismatch causes reflections that distort the signals and confuse the gates with phantom signal swings. Part of the problem is caused by the Digilent board I am using. It has two ways to connect to fpga IO pins, the 40 signals on the FX2 connector or a number of "PMOD" connectors they created in order to host simple add-on units, with different impedances.

The PMOD connections have a 200 ohm resistor in series, placed there to protect the fpga from short circuits. The FX2 lines have a 75 ohm resistor in series. Connecting a typical coaxial line at 50 ohms characteristic impedance, similar to many ribbon cable and I2C cables, guarantees a substantial mismatch for the PMOD. The FX2 line is barely adequate at 75 ohms, which does not include the actual source impedance of the fpga output, making the actual driving impedance even higher.

The PMOD lines are hopelessly mismatched being well above 200 ohms actual impedance feeding into a 50 ohm transmission line. I am not happy even with the FX2 lines, but if I were to rely solely on the FX2 connections I would lose 28 input-output lines that are only accessible by PMOD connectors JA, JB, JC and JD on the board, meaning I need a solution for both types of connectors.

I found a reasonable cable that should resolve the mismatch problems for the several fast serial links I employ throughout the 1130. IBM's token ring networking was designed around 150 ohm cabling, which is perfectly suitable for my purposes. I bought 900' on ebay at a low price and had it in hand when I returned.

I wired up a length of the new cable between the display pedestal control board and the fpga extension board where the signals originate. The cable is rock solid and reliable now. The display is solid, free of flickers and starts up correctly from a system reset every time.

I did discover that somehow I have the assignment of signals to lamps swapped around a bit. I could see the low order eight bits of the IAR, SAR and ACC accurately reflecting the state of the 1130 as I stepped through some code. However, the clock states X0 to X7 are displaying in the spot that should show the high order eight bits of the IAR. At first blush, it seems I have cabled the LED control board in reverse order, plugging the right hand panel into the socket for the left hand panel, with the middle panel the only correct one at this point. The middle panel displays the low order eight bits of the six major registers IAR, SAR, SBR, AFR, ACC and EXT.

It was quite difficult to get the cabling put into place and secured with cable ties, causing the most straightforward solution to be distastefully difficult. However, I can more readily swap the panels logically, by changing the bit stream I emit from the panel driver logic. I will do this before retesting.

I will additionally use of one of the buttons on the fpga board temporarily to act as a lamp test function. This is not straightforward since the physical lamptest button is supported by the I2C link which is not active at this point in my testing. Thus, the lamptest signal is not visible at the backplane level of my logic where I would normally tie it to an fpga board button. I choose to make use of a spare bit on the Status lines that are driving my display board, hooking button 2 to that bit which is tied to the lamptest line on the display module.

I swapped the signals in the display driver logic module to adjust for the way I have cabled the physical panel modules to the control board. I ran a functional test to verify that all the lamps work, are hooked up correctly, and the cabling is intact. There are still problems to work out.

Firstly, the lamp test shows that the left panel, rows 2, 3 and 4 are not lighting, nor is the right panel in a few spots. These are likely caused by disconnected wiring, but could be shorts in the panels. Secondly, the sixth row, which is the accumulator extension register, has some lights displaying that are undoubtedly intended to be the lamps on the main black plate (e.g. Run, Disk Unlock, or File Ready). 

I suspect that the black plate lamp signals can be swapped with some simple changes to the panel driver logic module in the fpga. I believe I will have to do some direct testing of the panels with an ohmmeter to diagnose and repair the sections that do not light with the lamptest button. 

The LEDs are quite bright, almost too bright without the plexiglass panel installed. However, that means that I will have a very acceptable and easily viewed display panel when it is all closed up. 

I have run out of time this weekend to test any further, but will have time during next week and weekend to wrap this up. As well, I can re-cable all the other serial links using my new 150 ohm cable that permits me to match the transmission line appropriately for reliable signalling. 

TEST GEAR ADDITION - STORAGE SCOPE

I picked up a Tektronix storage oscilloscope on ebay, model 466 which is 100MHz, dual channel with analog storage. I keep encountering situations where the analog circuit issues need investigating, which is easy to do with regularly clocked signals using my regular scope, but for sporadic or one-time pulses, I really needed to 'snap a picture' when the event occurs. The price was low enough that I picked it up, rather than those portable digital storage scopes at similar prices which are reported to be much less capable. The only advantage those have is portability in a shirt pocket, but if they aren't usable, why transport them?

A week home between trips, work ending Nov 17, 2013

DISPLAY PEDESTAL WORK

I worked through the wiring, shortening the cabling from the display panels as well as changing to thinner wire gage. After shuffling the logic around in the display driver logic module, I was able to verify that the Extension register is being displayed properly. The black plate signals are no longer visible on the display panel, which is appropriate, but they should be delivered to the black plate via its special cable.

The right hand display panel is the most complex as some of the logical rows of lights are split across different sections of the display. For example, an upper right (2R) row of five lamps displays the flag, tags and modifiers of the instruction while the row of three lamps displaying the index register just below (3R) are combined as a single logical row of 8 lights on the chip. Even more complex, the first row (3L) of six status indicators such as parity and shift control have the carry and overflow lamps from the bottom right (6R) interspersed to form a single logical row on the chip in the pattern AABABAAA. This panel also originates a cable to drive the main black plate lamps such as run and keyboard select.

I was able to clean up a few cold solder joints, get my display logic delivering the right signals to all the rows and lamps, and replace two bad LEDs. Now, all the panels are working correctly and I can finish the physical attachment of everything into the display pedestal enclosure.

I have epoxied the two panel parts together into a single long unit, having arranged the spacing to best fit the front panel. Somehow, my light panels have a spacing of 2.5" between the centers of the end of the T-clock lights and the beginning of the Op Reg lights, but the plexiglass panel with the cutouts through which they shine has the spacing as 2.75". To accommodate this, I have shifted the right hand panel so that the T-clock side lights have the plexiglass cutout to the right side of the lamp while the op-reg side lights have the cutout to the left side of the lamp. Since the lamp opening is wide enough to accommodate this 1/8" displacement, the discrepancy has no effect.

My current plan for mounting the light panels inside the enclosure is to make some L shaped wooden stops that hold the panel from moving backwards and hold it from moving to the side. These stops will be held in place by wood screws coming up through a hole in the bottom of the light pedestal box.

I formed the stops for the light panels and glued them into the L shapes. After predrilling a pilot hole in the wood for the attachment screw, I epoxied these to the sides of the light panel assembly. A short slot will be cut in the bottom of the enclosure under these wood stops, allowing me to affix them with a wood screw and slide the to fine tune the positioning of the panels. This will secure them, aligned with the plexiglass panel they sit behind.

Display panel assembly sitting inside pedestal enclosure for testing

I epoxied small nuts to the backs of the two side metal plates, the rotary mode switch plate and the emergency pull switch plate. An angle bracket was attached to the back using a corresponding screw through a bracket hole, into the nut on the plate. The bottom hole of the angle bracket will sit over a small slot cut in the bottom of the enclosure, allowing a screw and nut to lock the panel in place after fine tuning the position along the slot.

I created some wooden supports to sit inside the pedestal stands, giving me a more solid mount for my continuing work until I am ready to permanently mount the pedestal on the 1130 frame. I have a bit more work to form some channels for my cables that run inside the stands, but soon these will be installed and the enclosure much more solid.

Main black plate with lights on left hooked up for testing

I had tested most of the unit but not the lamps in the main black plate, so I hooked up the appropriate cable to that unit and tested the remaining lights on the system. Everything is working great with the lights, thus time to turn to finalizing the inputs - the rotary switch on the pedestal, the push buttons on the main black plate, the buttons that will sit on the typewriter faceplate, the console entry switches that will sit on the typewriter faceplate, and the keyboard itself. I had a lot to hook up before I could do the complete testing of the inputs.

Testing configuration running 1130 programs to validate display lights

 I had observed that the lamps are very 'blue-white' in color compared to the yellow cast of the incandescent bulbs used in an IBM built 1130. My solution will be to place a yellow plastic film between the lamps and the plexiglass panel, shifting the hue of the lights sufficiently to appear more realistic.

I made a short video ( Video of display lamp testing ) of the pedestal display lights and the main plate lights operating, by running a small program that normally drives the console typewriter. It loops waiting for a response but without the typewriter powered on, it cycles checking status of the device. I haven't set the proper parity in memory for all of that program yet, which causes it to register parity errors when running. By activating the CE 'parity run' switch, I am allowing it to operate while ignoring the parity errors. At one point at the end, I switch off the parity run switch and the system freezes as it should.

The 1130 is running at the same speed as the IBM built machines and is cycle accurate, with the display lights showing exactly the status that would be seen at every step and phase as the machine runs.

COMPUTER HISTORY MUSEUM ACTIVITY

I visited with the rest of 1401 restoration team briefly on Wednesday, just four days before the opening event of the new exhibition space where the machines will be demonstrated. The four tape drives on the right of the exhibition space, those attached to the CT 1401, were not yet cabled. I worked with some of the team locating and stringing the cables between the drives, including putting the proper floor tiles with cutouts underneath each drive.

The 1402 card reader on the DE 1401 is getting read check errors, indicating that the holes being read by the first set of brushes don't match the pattern sensed by the second set. A 1402 expert was working on this, without a resolution as of 4PM when I left the museum. One of the tape drives on the CT 1401 would not load tape - it didn't sound as if it were starting the vacuum pump. That could be any number of issues, beginning with faulty switches that indicate the capstan roller is retracted all the way, through various electronic circuits and up to the pump and vacuum system itself. This will have to be debugged further on a future date, as we ran out of time to dig deeper.

The physical exhibit room looks great, with big posters, wall sized pictures of the 1401 and other effects in place. Some of the docents who will give the demonstrations were practicing, using other museum staff as a stand-in audience. While I will be giving demonstrations myself, I haven't yet listened to the entire talk nor received copies of the script. Once I am back from my remaining trips for the year, I can get up to speed.

A few of us discussed whether it is possible to build a tester for the circuit cards that might be along the lines of the old vacuum tube testers - plug in a card, set various switches and connections based on the particular card type, then push a button to run the tests. We think there is enough commonality to the pin assignments that this may be possible - however, detailed research is necessary.

It would seem useful to equip this with both regulated voltages and adjustable 'margin' voltages, to allow the cards to be placed into their worst case condition. The setup should be able to measure both correct function and delay time, as both are important factors in a good card. Scope connections also make sense. This is something for us to noodle on over the coming weeks.

1054 AND 1055 PAPER TAPE PERIPHERALS

I am continuing the design of an interface for the 1054 tape reader and 1055 tape punch for the Computer History Museum. The reader is fully tested and adjusted, but I have not yet tested or adjusted the punch. I have a prototype electrical interface to an Arduino microcontroller which will manage both devices and permit connection to external systems.

1055 punch in foreground and 1054 reader and its interface board behind it.

REDESIGN OF DOCUMATION CARD READER ADAPTER LOGIC

I realized two fundamentally different and simplifying ideas to handle the adapter that sits between the Documation 600 card reader and the IBM designed adapter logic that believes it is cabled to an IBM 2501 card reader. The adapter logic has to drive the Documation to fill a FIFO queue and emulate a 2501 card reader to emit the proper signals to deliver the data from that FIFO exactly as if it were read by a 600 card per minute 2501.

The 2501 reader has a pre-read station, into which cards are fed by a read cycle before they can move on the next read cycle through the photocells and on into the 1130. One first 'primes' the 2501 by pressing start when the pre-read station is empty, which moves one card from the hopper into the preread area and turns on the "ready" light/status.

When the 2501 is in the ready condition, a read will feed one card past each station - a new card shuttles from the hopper to preread, while the preceeding card moves from the preread station through the photodetectors and onto the stacker. When the hopper is empty, the 2501 turns off the 'ready' condition even though there is still a card in the preread station. The adapter is poised for the 'last card' sequence.

This is the opportunity for the operator to do one of two things; more cards can be placed in the hopper and the start key pressed, or the start key can be pressed without any cards in the hopper. If no cards are in the hopper when start is pressed, the machine will allow a final read command, taking the data from that card but also raising the 'end of file' condition to the processor.

Thus, very long decks of cards can be run through the reader yet the software reading will see a continuing stream of data, punctuated by invisible pauses as more of the deck is dropped into the hopper. Yet, when that deck of cards is at its end, the last card sequence is triggered to alert software that the data file is at its end.

The Documation reader does not have a pre-read station. When a read is requested, as long as the hopper has cards and the reader is in the ready status, it will move a card from the hopper past its photocells and into the stacker as one single action. The last card of a deck would have already be read and delivered to the software before the hopper empty condition would be detected, making it difficult to flag 'end of file' with the last card. There is no 'run-in' sequence to move the first card from hopper to the empty pre-read station, either, since it has no analog of that station.

My solution is to use a two card deep FIFO and to track the state of the virtual pre-read station. Pushing the start button on the 2501 control pad signals my adapter logic to read one card from the Documation, assuming it is ready and has cards in the hopper. That sits in the FIFO as the pre-read, then the signals I send back to the 1130 adapter logic causes it to turn on the 2501 Ready light and condition, believing that run-in has been accomplished.

The software can issue a read to the 2501 and the IBM adapter logic believes the reader to be ready, with a card primed in the preread area, so it begins to empty the FIFO along with the various positional contact switch signals, emitter pulses and simulated photocell states - passing in the 80 columns just as the IBM 2501 adapter logic in the 1130 expected. it also triggers another read of the Documation, filling the end of the FIFO with another 80 columns of data, from the next card that is entering the virtual preread station. Thus, the data sent to the processor is always one card behind, allowing me to model the last card sequence, present the end of file indication and behave appropriately.

The adapter logic is timing accurate, simulating the rotational speed of the 2501 mechanism, the timing when various pulses are emitted and the time between card columns and from card to card, resulting in a 600 cpm delivery of data into the 1130. The Documation 600 is also able to run at 600 cpm, thus I can keep this generally balanced with one new card filling the back of the FIFO as each preceding card is removed to send to the software.

I have to simulate and then test this with real hardware, but it seems pretty straightforward in its new incarnation. The interesting challenge will be to work out the proper error recovery actions to take for each kind of error that can occur - failure to feed a card, logical error while the card moves, or hopper empty. I will map these into the most appropriate 2501 error condition.

I am a bit unsure of whether there are conditions that can occur where I may be reading from the Documation, detect an error during the card movement past the photocells, and leave the FIFO in a bad condition (e.g. not push in exactly 80 columns of data).

I want the recovery behavior to match what an operator would do on a real 2501 - when they remove the last card from the stacker and put it first in the hopper, I should do the same, when they just need the condition cleared so that additional cards can be read from the hopper, I should also do that. It may require a method of clearing out or shortening the FIFO, which I have to think through carefully, but if I am clever I can avoid the need for this entirely.

NEW FPGA BOARD PICKED UP ON EBAY

I saw an auction of a fairly high end fpga development board, one that has three SATA disk channels, 10G ethernet, sound circuit, HD video, twin PowerPC embedded processors, lots of DRAM, Compact flash, USB and many other IO options. I don't have a specific project in mind yet but I can use it for something I am sure, since I was able to buy it for $103 which is quite a bit below its selling price of 1,800.

Virtex II Pro development board

I received the board and tested it already - it is in great shape. It is fast enough to handle many tasks I might need during future parts of the project. It is a Xilinx XUP Virtex II Pro development board.

AWAY FOR TWO WEEKS OF BUSINESS TRAVEL

I left Saturday for a pair of back to back trips, the first within the US and the second to the UK. I arrive home the evening before the US Thanksgiving holiday, thus won't get to work on the 1130 until the very end of that week. I will bring the Surface Pro on which I do the VHDL coding and synthesis, in order to work on other logic in spare moments.

I should finalize the card reader adapter logic to be ready for testing in the coming weeks, similarly for the line printer and disk drive adapter logic. All of this are complex because they will deliver timing and behavior accurate signals to the IBM designed 1130 adapter logic exactly as if the true IBM peripheral (e.g. 2501, 1403 and 2310) were attached. They must do this while driving the physical boxes I am using, whose behavior, timing and mode of operation is quite different in places.

As well, I can continue to clean up my VHDL code, slashing the number of warning messages from the synthesis tools to a minimum and tightening up the code quality. To the extent that I accomplish all this, it will require a round of regression tests to validate that previously verified parts of the machine still operate correctly. I intend to bring the main fpga logic card with me on the trip to accomplish some of these regression tests as I modify the code, although anything involving physical circuits and peripherals will have to wait until I am back home.

Week ending Nov 24, 2013 - mostly traveling

TRAVELS

I spent half a week in Denver at SC13 trade show, meeting with technology providers, after which I swapped clothes and flew to London where I will speak and meet attendees at one of my employer's conferences next week. I had the weekend free in London, giving me a chance to visit the National Museum of Computing and Bletchley Park.

As well, I had an opportunity to meet with a fellow replica designer, Lawrence Wilkinson, who has a 360/30 implemented in FPGA and a typewriter console. I had hoped to spend Friday evening for this, but hotel issues kept me from the room until early evening and I ran out of time and energy. We met Saturday evening, after I was back from the museum visit, enjoyed dinner and talked about designing and building replicas of antique computers.

VISIT TO TNMOC

The National Museum of Computing has an HP punched card reader which is a slight variation of the Documation model 600, but the drive rollers have disintegrated - the rubber has turned semi-liquid due to long term exposure to ozone which is ubiquitous in most areas due to automobile and industrial emissions. The parts for the reader are no longer manufactured or available, but we have been searching for suitable replacements.

I discovered some wheels on ebay that match the external dimension, with a bit of trimming for the width, but need a bit of work to attach to the axle of the Documation mechanism. They have arrived in the post, allowing me to bring part of the supply to TNMOC for their staff to work on and the remainder at my home to allow me a shot at adapting them. The museum has many decks of cards that should be read and preserved, before the card readers are all out of service and before the card stock itself deteriorates.

Potential replacement rubber in between real rollers to be replaced

Roller to be split along circumferal groove, bored out to match hub, then press fit with adhesive to the hub

Current metal axle is easily pressed out, to allow boring of the opening

I was able to record characteristic sounds of the 1130 that is restored and operating at the computer, thanks to the kindness of Peter Vaughan who allowed me in before opening time where I could make the recordings. The background noise of fans running and noise from transformers and other components was the first clip I produced, as I want this to run continuously on my replica from power-on to shutdown.

I didn't record shutdown or power-up sequences - the start is so immediate I can just launch the background noise, while the shutdown could be handled by fading since it is essentially just the fans coasting to a stop. The remaining recordings were a variety of disk activities, especially long, medium and short seeks. The ramkit drive inside an 1130 used a mechanical detent to stop and lock the arm at each cylinder position, which generates a click-like sound as it engages.

The mechanism is arranged with two racks, offset by one cylinder, each with a solenoid and ratchet. By releasing and reactivating the solenoid on one side, the drive accomplishes a two-cylinder seek. Flipping from one side to the other achieves a single cylinder movement. Thus, any seek on the system is composed of a sequence of two-cylinder moves and a final one-cylinder action if the span to be traversed is an odd distance.

A seek all the way to the end of the drive and back to cylinder zero is thus a buzzing, rasping sort of sound from the rapid clicking of the solenoid and pawl up to 400 times in a couple of seconds. Short seeks of 10 cylinders have a brief buzz sound, while individual cylinder to cylinder movements produce a tick sound.

Peter ran the disk utility program DCIP allowing me to record random seeks, initializations and verifies which used single cylinder moves, and some long seeks. I can combine these files to recreate the desired sound as my DEC RK-05 disk drives silently seek between cylinders.

I took the time to carefully image all the logic diagram pages from the museum, as they contained some valuable information I need to implement the SAC feature that drives the 1403 printer, but also serves as additional triangulation on the 1130 design. Since each machine's logic diagrams are individual to fit its exact configuration, it is only by comparing diagrams of many machines that I can generalize the design approach to permit me to more accurately configure the 1130 system I am recreating.

This is a sample of the logic diagrams I photographed at TNMOC

I then walked through the museum, enjoying its collection of great old machines and components. Once again, I enjoyed watching the Harwell Dekatron aka Witch, a large calculator employing vacuum tubes (valves over here) which lit one of ten rotary positions around the face, thus each tube is a decimal digit.

A replica is under construction of the EDSAC, one of the first computers. EDSAC will join the replica of the Colossus, a system that predates Eniac and represents one of the important first steps of computing along with the Zuse system, the Atanasoff-Berry system and Eniac.

Many other fascinating items attracted me, such as an Eliott machine built using a kind of MTL circuitry- magnet transistor logic. In this case, it used magnetic cores as logic gates, forming OR and AND types of circuits. Pulses on the input windings would flip the core to its 'on' magnetic parity, then its state is read by a plus that moves every core to the off state. Any that were already on generate a short pulse on a sense winding, while those staying off create nothing; the gate is reset to read out its prior state, just like the destructive read of core based memories.

Multiple windings in the 'positive' direction would flip the core on if a pulse arrived on any of the windings (A or B or C). If some windings were in the 'negative' direction, a pulse on that winding would either neutralize pulses on positive windows or flip off a core that was already activated (A and not-B).

WORK ON DOCUMATION CARD READER ADAPTER

I began simulating the adapter code to debug the function as much as I could while traveling without access to the 1130 or the reader.I was able to tighten up the timing accuracy of the adapter, producing signals and behaviors for the virtual 2501 reader that should work properly with the IBM designed adapter logic in the 1130.

It was quite tedious to set up the simulation to cause the signals to arrive that would be coming from the 1130 adapter logic, since they have to occur at specific times related to what the simulated 2501 reader is doing. For example, activating the hopper magnets and feed solenoids to perform one card movement cycle requires them to switch on as a specific detector pulse activates at a certain rotational position of the 2501 machinery, then to switch off when another of those detectors (the feed contact breakers FeedCB1/2/3) is reached.

During the read cycle, but not the run-in that loads a card into the preread station, signals have to arrive to cause recording of timing pulses on the emitter wheel, at the time when the trailing edge of the card clears the preread station photocell allowing it to switch on. This prepares timing to emit a pulse right in middle of each of the 80 card columns as the punched card moves through the read station photocells; that emitter pulse is used to latch in the state of a card column.

I first ran the simulator to determine the timing of the contact breakers on their perpetual 100ms cycle. I then applied signals relative to the start of each 100ms cycle that the simulated 2501 is experiencing with its continually running feed wheel. Now that I have the timing of a run-in and a normal read determined, these are copied as a group onto the end of the simulator input to produce that type of 100ms cycle. If no action is commanded by the program or operator, then we have 100ms idle cycles where only the contact breaker pulses arrive.

I tested run-in and normal reads, seeing all the outputs at the right time, the state of various mechanisms change corresponding, such as the pre-read station status based on cards feeding through the reader.

OTHER DESIGN WORK

I want to adapt a line printer to behave like a 1403 model 7 printer, making use of the unaltered IBM adapter code and delivering realistic behavior including timing. However, I don't have enough documentation on the 1403 to make that happen yet.

I may be able to extract information from logic diagrams for an integrated print adapter on a 360/20, although the 1403 used with that system includes features like Universal Character Set (swappable print cartridges) which make it materially different from the model 7 adapter would be.

As well, I may be able to extract some information from the logic diagrams for 1401 machines with 1403 printers attached. Combining several sets of diagrams may allow me to triangulate on a suitable model 7 behavior. I have one, the system from TNMOC, and may get access to the diagrams from a private collector's machine across the bay from my home.

Some of this may be moot, since the 1403 is attached using the SAC feature, hooked to a 360 channel, hooked to part of a 2821 control unit, all contained in a large frame cabled to the 1130. Thus, the details of the printer are hidden by the control unit buried in the 2821, for which I have no ALDs, and all that is built into the 1130 is the SAC which hooks to the 360 channel. As long as I can mimic a 360 channel, I will get the IO commands and be able to shuttle data across the interface.

The only reason the internal operational details may still matter is if I want to make this as timing-accurate as I can, then I should be modeling the rotation of the print chain and other actions of the mechanism in order to know when to present 'device end'.

MISCELLANEOUS PICTURES OF DISPLAY PEDESTAL ASSEMBLY AND TESTING

The light panel with 244 LEDs plus wiring to six lamps on keyboard black plate

Six leds on the left side of this black plate, lit by same circuitry as the display panel

In the middle of mounting the light panel inside the display pedestal enclosure

During testing, before mounting of Emergency Pull panel and plexiglass front panel

PICTURES OF THE 1054 AND 1055 PAPER TAPE UNITS

The reader is furthest away, with interface board on top, the punch is closest.

PICKED UP IBM ELECTRONIC MODEL 75 TYPEWRITER AS A BACKUP PRINTER/CONSOLE

I found an ET75 on Ebay at a reasonable price, offered as not working/for parts. I picked it up during a trip last week and brought it home. Initially, something is wrong in the physical keyboard or the adjustment, as the mechanism that accepts a character then resets the key is cycling continuously. I will degrease, lubricate and then look into the adjustments to see if this can be brought back to working condition to act as a 1052 console. I have picked up several big lots of spare parts for ET machines which gives me almost anything I might need to get this and the ET50 I already owned both into working shape. Perhaps they would be of interest to some other hobbyist building a working console panel or machine replica.

ET75 mechanism in need of cleaning and adjustment, maybe more.