Friday, June 17, 2016
Overseas trip
I am currently in Dublin, Ireland and will be away from the 1130 until July 8th. I may get some things accomplished on the laptop in free time, but it will be fairly quiet here until I am back.
Tuesday, June 14, 2016
Xerox Alto CRT driver tool completed and sent to team
XEROX ALTO RESTORATION
Another team member had previously measured the video signals on an Alto, which gave me the data I needed. The horizontal line scan takes 38 us, with a 3.56 us sync pulse and appropriate front and back porch times (blanked intervals that bracket the sync pulse), it delivers 606 pixels of video in a line with the 20.16MHz pixel clock.
Vertically, it operates in interlaced scan mode at 60 fields per second, alternating odd and even lines of the display memory buffer on each scan. The 16.67 ms vertical interval has a 152 us vertical sync pulse and with its front and back porch times, permits the 404 even or odd lines to be scanned. To address the interlaced lines, the even field will have the vertical sync pulse delayed by 19 us, half of a horizontal line.
I wrapped up the logic for the tester and built a few patterns. It generates vertical and horizontal bars, vertical and horizontal lines, with various shifts in position. To help the other team members while I am away on my trip, I wrote up a very brief manual for using the tool. Everything was transmitted over to Marc before the end of the day.
Another team member had previously measured the video signals on an Alto, which gave me the data I needed. The horizontal line scan takes 38 us, with a 3.56 us sync pulse and appropriate front and back porch times (blanked intervals that bracket the sync pulse), it delivers 606 pixels of video in a line with the 20.16MHz pixel clock.
Vertically, it operates in interlaced scan mode at 60 fields per second, alternating odd and even lines of the display memory buffer on each scan. The 16.67 ms vertical interval has a 152 us vertical sync pulse and with its front and back porch times, permits the 404 even or odd lines to be scanned. To address the interlaced lines, the even field will have the vertical sync pulse delayed by 19 us, half of a horizontal line.
I wrapped up the logic for the tester and built a few patterns. It generates vertical and horizontal bars, vertical and horizontal lines, with various shifts in position. To help the other team members while I am away on my trip, I wrote up a very brief manual for using the tool. Everything was transmitted over to Marc before the end of the day.
Monday, June 13, 2016
Alto II CRT test tool designed
OVERSEAS TRIP
I am leaving in a couple of days for three weeks away, but will accomplish what I can while away for tasks that involve VHDL or Python. It has already been consuming quite a bit of time given a portion of the trip is my daughter's wedding.
XEROX ALTO II RESTORATION
The Alto has a monochrome CRT, in page orientation such that the vertical size is larger than the width. The documentation describes the signals that are sent to the CRT, which are very much like VGA or simplified NTSC video. We want to test and restore the CRT before we bring up the ALTO processor itself.
To support the testing, I will be creating an FPGA based tool to drive the video. I will be leveraging the patterngen open source code from open cores, building the tool for the low cost Elbert V2 development board. This board has a Xilinx FPGA and, among other IO options, a VGA connector. We will create a cable to hook the VGA port of this board to the CRT connector of the Alto.
I did the development work and some testing on my surface pro tablet, aiming to produce a binary file that the other team members can load onto the board when they want to do testing. I couldn't use my laptop because that had Vivado, which does not support the older Spartan 3 type chips, so I had to use the ISE toolchain on the surface pro.
There was some ambiguity in the video spec when comparing the known rate and display area size of the Alto manual to the timing ranges of the monitor manual. Since the display is interlaced scan at 60 fields per second, I need to complete 404 vertical lines in each field in order to support the 808 x 606 pixel display area. The specs for the monitor show it capable of 230 to 351 lines in a field, or 460 to 702 vertical pixels, not 808.
The team looked into the design question and studied other references in order to set a definite spec for the tool to produce. Once we have firm specs, it won't take long to finish up the tool and deliver it. Right now I am in waiting mode.
For those who know analog video, e.g. NTSC or similar, this is TTL instead. Three signals - vertical sync, horizontal sync, and video. There are no front or back porches, no negative sync pulses. The horizontal sync line just goes high for 11 microseconds once every 63 microseconds. The video signal is kept at 0 level to "blank" during the retrace time. Once every 60th of a second, the vertical sync line is set to 0 for 900 us then stays at 1 for the full time that all the horizontal lines are drawn.
Thus, once I have the specs for timing, such as 11us hor sync, 63 us line time and so forth, it is a simple matter of counters to drive the sync signals and to 'blank' video. Beyond that, any video pattern to be displayed has to be counted both in pixels across each line and in the line number to display. The Alto itself does this by fetching words for each line.
My design will algorithmically create vertical and horizontal bars, for example, but I can also precompute more sophisticated images and keep them in RAM for access during the scan.
We had discovered during our first day of restoration that the machine came with a Diablo 31 drive but did not have the disk controller card needed to access it. We are fortunate to know a collector who has spare controller boards and offered to give one to us for the restoration.
I am leaving in a couple of days for three weeks away, but will accomplish what I can while away for tasks that involve VHDL or Python. It has already been consuming quite a bit of time given a portion of the trip is my daughter's wedding.
XEROX ALTO II RESTORATION
The Alto has a monochrome CRT, in page orientation such that the vertical size is larger than the width. The documentation describes the signals that are sent to the CRT, which are very much like VGA or simplified NTSC video. We want to test and restore the CRT before we bring up the ALTO processor itself.
To support the testing, I will be creating an FPGA based tool to drive the video. I will be leveraging the patterngen open source code from open cores, building the tool for the low cost Elbert V2 development board. This board has a Xilinx FPGA and, among other IO options, a VGA connector. We will create a cable to hook the VGA port of this board to the CRT connector of the Alto.
I did the development work and some testing on my surface pro tablet, aiming to produce a binary file that the other team members can load onto the board when they want to do testing. I couldn't use my laptop because that had Vivado, which does not support the older Spartan 3 type chips, so I had to use the ISE toolchain on the surface pro.
There was some ambiguity in the video spec when comparing the known rate and display area size of the Alto manual to the timing ranges of the monitor manual. Since the display is interlaced scan at 60 fields per second, I need to complete 404 vertical lines in each field in order to support the 808 x 606 pixel display area. The specs for the monitor show it capable of 230 to 351 lines in a field, or 460 to 702 vertical pixels, not 808.
The team looked into the design question and studied other references in order to set a definite spec for the tool to produce. Once we have firm specs, it won't take long to finish up the tool and deliver it. Right now I am in waiting mode.
For those who know analog video, e.g. NTSC or similar, this is TTL instead. Three signals - vertical sync, horizontal sync, and video. There are no front or back porches, no negative sync pulses. The horizontal sync line just goes high for 11 microseconds once every 63 microseconds. The video signal is kept at 0 level to "blank" during the retrace time. Once every 60th of a second, the vertical sync line is set to 0 for 900 us then stays at 1 for the full time that all the horizontal lines are drawn.
Thus, once I have the specs for timing, such as 11us hor sync, 63 us line time and so forth, it is a simple matter of counters to drive the sync signals and to 'blank' video. Beyond that, any video pattern to be displayed has to be counted both in pixels across each line and in the line number to display. The Alto itself does this by fetching words for each line.
My design will algorithmically create vertical and horizontal bars, for example, but I can also precompute more sophisticated images and keep them in RAM for access during the scan.
We had discovered during our first day of restoration that the machine came with a Diablo 31 drive but did not have the disk controller card needed to access it. We are fortunate to know a collector who has spare controller boards and offered to give one to us for the restoration.
Sunday, June 12, 2016
Xerox Alto II restoration begins, some work on 1130
1053 CONSOLE PRINTER RESTORATION
Once the GUI is communicating successfully with the fpga, I can load the typewriter diagnostic to shake it down further. As is, the hand loop I entered into core lets me fire off steady sequences of two characters. That was the way I realized that my 1053 was not triggering the backspace operation when commanded by the program. All the others appeared to work.
ALTO II RESTORATION
I am helping a small team restore a Xerox ALTO II computer. Our first meeting was today to assess condition, begin on power supplies and plan out the restoration tasks.
The machine is mostly built of 7400 series chips, using four 74181 chips as the bit-slice ALU. Our power supplies are +12, +15, -15 , -5 and +5V. The machine is a microcoded machine and the microcode makes the machine look like a Data General Nova minicomputer. We will first work on the microarchitecture and when that works properly, can debug the next layer up with the Nova-like microcode running.
Most of the power supplies came up to full power, showing good stability and almost no ripple. However, the +15V supply did not. It would wander in voltage, sometimes drop to zero, and the level it reached lowered as we increased the load. We removed the unit and took it to the bench.
The two main filter capacitors were essentially open, causing the problems on the supply. We did find some corrosion on traces on the edges of a couple of circuit boards in the supply, which we removed. In one case we rebuilt the trace due to the amount of copper loss it had suffered.
With replacement capacitors in place, we tested the supply again and found it fully operational. All supplies now back in the system and ready to deliver power to logic when we are ready for that. We decided we had a couple of tasks to finish first - verifying the boards are in the correct slots in the Alto card cage and testing the CRT.
The cards were verified and properly seated in the cage, but we discovered some anomalies. Card 21 should be the disk controller, but we found a disk controller card in slot 15. Several connectors with twisted wire cables were unconnected in the chassis. The Diablo 31 drive signal cable had an edge connector but it wouldn't fit on the disk controller card.
Looking closer, we found the disk controller card was for a Trident disk, not for the Diablo. The twisted wire cables fit onto the trident controller and run to the Trident disk sockets on the back of the Alto. Unfortunately, we have no Trident drive to connect to this. The Trident is a drive similar to the IBM 2311, several 14" platters on a shared axis, which are top mounted and are accessed by an arm assembly with multiple heads.
The trident controller belongs in slot 15, leaving us with a gaping hole where the Diablo disk controller should be. We will see if we have access to a controller, even temporarily, to bring up the system during the restoration. The owners will need to secure a disk controller card at some point if they want an operational Alto.
BULBS TO IMPROVE 1130 DISPLAY LIGHTS
I ordered some candidate bulbs from Topbulb.com and will see if they give me a way to get a more reliable and accessible set of lamps on the 1130. The main advantages of these bulbs are:
Once the GUI is communicating successfully with the fpga, I can load the typewriter diagnostic to shake it down further. As is, the hand loop I entered into core lets me fire off steady sequences of two characters. That was the way I realized that my 1053 was not triggering the backspace operation when commanded by the program. All the others appeared to work.
ALTO II RESTORATION
I am helping a small team restore a Xerox ALTO II computer. Our first meeting was today to assess condition, begin on power supplies and plan out the restoration tasks.
The machine is mostly built of 7400 series chips, using four 74181 chips as the bit-slice ALU. Our power supplies are +12, +15, -15 , -5 and +5V. The machine is a microcoded machine and the microcode makes the machine look like a Data General Nova minicomputer. We will first work on the microarchitecture and when that works properly, can debug the next layer up with the Nova-like microcode running.
Most of the power supplies came up to full power, showing good stability and almost no ripple. However, the +15V supply did not. It would wander in voltage, sometimes drop to zero, and the level it reached lowered as we increased the load. We removed the unit and took it to the bench.
The two main filter capacitors were essentially open, causing the problems on the supply. We did find some corrosion on traces on the edges of a couple of circuit boards in the supply, which we removed. In one case we rebuilt the trace due to the amount of copper loss it had suffered.
With replacement capacitors in place, we tested the supply again and found it fully operational. All supplies now back in the system and ready to deliver power to logic when we are ready for that. We decided we had a couple of tasks to finish first - verifying the boards are in the correct slots in the Alto card cage and testing the CRT.
The cards were verified and properly seated in the cage, but we discovered some anomalies. Card 21 should be the disk controller, but we found a disk controller card in slot 15. Several connectors with twisted wire cables were unconnected in the chassis. The Diablo 31 drive signal cable had an edge connector but it wouldn't fit on the disk controller card.
Looking closer, we found the disk controller card was for a Trident disk, not for the Diablo. The twisted wire cables fit onto the trident controller and run to the Trident disk sockets on the back of the Alto. Unfortunately, we have no Trident drive to connect to this. The Trident is a drive similar to the IBM 2311, several 14" platters on a shared axis, which are top mounted and are accessed by an arm assembly with multiple heads.
The trident controller belongs in slot 15, leaving us with a gaping hole where the Diablo disk controller should be. We will see if we have access to a controller, even temporarily, to bring up the system during the restoration. The owners will need to secure a disk controller card at some point if they want an operational Alto.
BULBS TO IMPROVE 1130 DISPLAY LIGHTS
I ordered some candidate bulbs from Topbulb.com and will see if they give me a way to get a more reliable and accessible set of lamps on the 1130. The main advantages of these bulbs are:
- longer bare wires allowing more maneuvering room inside the 1130 display panel
- wires are not brittle, won't break off when the bulb is moved
Thursday, June 9, 2016
Back to work on the new GUI for the 1130
POSSIBLE RESTRUCTURING OF LIGHTS IN 1130 DISPLAY PEDESTAL
The lamps used for the 1130 system are glass incandescent bulbs with bare wire emerging from the glass envelope, but the wires have become brittle with age and easily snap off at the surface of the glass. To make this more complex, the bulbs are inserted in a socket which is inserted over pins on a control board, making contact by squeezing the bulb wire between the pin and its mating hole.
The boards have SCRs to modulate the 7.5V AC lighting power based on the logical state of the digital SLT signal line. A board is a narrow PCB, eight to sixteen lights wide and about 1/2" deep, with pins emerging from one edge to slide into the lamp sockets. Eight signal lines are connected to the eight SCRs, as well as the 7.5VAC and ground common lines.
The display pedestal has a plastic honeycomb with holes that the bulbs and their sockets should fit into. In theory, the sockets form a firm fit into the honeycomb holes with the control PCB hanging off the back of the lamps. The bundle of wires hooked to the PCB, however, pull back and down on the boards, tending to dislodge them.
Forcing the 16 independent sockets to fit into their honeycomb holes will often snap one or more of the brittle lamp wires, so that it appears to be intact but is electrically isolated and dark. The scheme is not well designed for replacement by the CE, requiring fiddling to insert or remove a row of lamps with their board.
It would have been ideal if all the boards were anchored to a common plate, spaced properly, with the lamp sockets aligned properly so that the plate is pulled back or pushed into the honeycomb as a single unit. Pulling the plate back would allow access to all the lamps but minimize the impact on every other lamp but the one being replaced.
I am looking at ways to clean this up, ranging from the common plate idea plus socket aligners, or other means. One possibility is to find reasonably compatible lamps which are modern, without brittle leads, and build new mounts to hold them in the honeycomb. I could then mount the control PCBs back a bit and connect these to the new sockets via wires.
Of course, if I could find modern incandescents that were compatible with the control board, that would not snap off at the merest movement, and that could be fit into the sockets used with the current bulbs, I could assemble the panel as it is currently designed.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
The first problem I discovered in my recovered laptop environment was that I had installed the 64 bit version of wxPython but the base Python version was 32bit. Uninstalled the old one and downloaded the correct version, then moved ahead.
Next up was the usb module (and the problem I remember having to manually move DLL files to get the USB support working). Installing pyUSB was easy, and yes the darned libusb-win32 was a obscure mess.
I didn't have the USB module configured yet when I tested, raising some exceptions that I coded around so that the application handles this condition gracefully. Next, I got the driver installed, allowing the application to come up and attempt communications.
My next issue is the same one I had with the old GUI when I tried it - the GUI times out trying to read a response from the fpga. I will have to put in some diagnostics to understand the state in the fpga when this happens.
The lamps used for the 1130 system are glass incandescent bulbs with bare wire emerging from the glass envelope, but the wires have become brittle with age and easily snap off at the surface of the glass. To make this more complex, the bulbs are inserted in a socket which is inserted over pins on a control board, making contact by squeezing the bulb wire between the pin and its mating hole.
The boards have SCRs to modulate the 7.5V AC lighting power based on the logical state of the digital SLT signal line. A board is a narrow PCB, eight to sixteen lights wide and about 1/2" deep, with pins emerging from one edge to slide into the lamp sockets. Eight signal lines are connected to the eight SCRs, as well as the 7.5VAC and ground common lines.
The display pedestal has a plastic honeycomb with holes that the bulbs and their sockets should fit into. In theory, the sockets form a firm fit into the honeycomb holes with the control PCB hanging off the back of the lamps. The bundle of wires hooked to the PCB, however, pull back and down on the boards, tending to dislodge them.
Forcing the 16 independent sockets to fit into their honeycomb holes will often snap one or more of the brittle lamp wires, so that it appears to be intact but is electrically isolated and dark. The scheme is not well designed for replacement by the CE, requiring fiddling to insert or remove a row of lamps with their board.
It would have been ideal if all the boards were anchored to a common plate, spaced properly, with the lamp sockets aligned properly so that the plate is pulled back or pushed into the honeycomb as a single unit. Pulling the plate back would allow access to all the lamps but minimize the impact on every other lamp but the one being replaced.
I am looking at ways to clean this up, ranging from the common plate idea plus socket aligners, or other means. One possibility is to find reasonably compatible lamps which are modern, without brittle leads, and build new mounts to hold them in the honeycomb. I could then mount the control PCBs back a bit and connect these to the new sockets via wires.
Of course, if I could find modern incandescents that were compatible with the control board, that would not snap off at the merest movement, and that could be fit into the sockets used with the current bulbs, I could assemble the panel as it is currently designed.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
The first problem I discovered in my recovered laptop environment was that I had installed the 64 bit version of wxPython but the base Python version was 32bit. Uninstalled the old one and downloaded the correct version, then moved ahead.
Next up was the usb module (and the problem I remember having to manually move DLL files to get the USB support working). Installing pyUSB was easy, and yes the darned libusb-win32 was a obscure mess.
I didn't have the USB module configured yet when I tested, raising some exceptions that I coded around so that the application handles this condition gracefully. Next, I got the driver installed, allowing the application to come up and attempt communications.
My next issue is the same one I had with the old GUI when I tried it - the GUI times out trying to read a response from the fpga. I will have to put in some diagnostics to understand the state in the fpga when this happens.
Monday, June 6, 2016
Recovered my GUI and fpga work of past month
RECOVERING FILES LOST WITH HARD DRIVE CRASH
The data recovery service (Datacent) responded immediately this morning when they read my message from over the weekend. They quickly put up the intended files and I downloaded them that morning. After a couple of hours, I had the files extracted and could verify their correctness.
All I needed was there! I still have some work to do in bringing my Python environment up to a fully functional equivalent to what I had, and a bit of work to update some IP in the Xilinx environment since I grabbed a slightly newer version of Vivado this time around, but I have the work I did.
Making a thumbdrive backup now, in addition to the online Crashplan backup, so that I don't face the loss of the data ever again. Once that was done, I updated the Xilinx IP and verified that my code can be generated by the toolchain. Worked well.
Next up, I have to merge my saved files with the wider set of files from my backup a month ago. With that done, it is time to work on getting the Python environment ready to run the GUI. That means the wxPython library, several other libraries, pyusb and some usb libraries moved into windows.
IBM 360 MODEL 50 CONTROL PANEL
A friend (Marc) just bought a front panel from a 360 model 50 and wants to create a model 50 in FPGA, connected to the panel lights and controls. There appears to be just about enough documentation to create the system, but it will take substantial investigation and interpolation.
The data recovery service (Datacent) responded immediately this morning when they read my message from over the weekend. They quickly put up the intended files and I downloaded them that morning. After a couple of hours, I had the files extracted and could verify their correctness.
All I needed was there! I still have some work to do in bringing my Python environment up to a fully functional equivalent to what I had, and a bit of work to update some IP in the Xilinx environment since I grabbed a slightly newer version of Vivado this time around, but I have the work I did.
Making a thumbdrive backup now, in addition to the online Crashplan backup, so that I don't face the loss of the data ever again. Once that was done, I updated the Xilinx IP and verified that my code can be generated by the toolchain. Worked well.
Next up, I have to merge my saved files with the wider set of files from my backup a month ago. With that done, it is time to work on getting the Python environment ready to run the GUI. That means the wxPython library, several other libraries, pyusb and some usb libraries moved into windows.
IBM 360 MODEL 50 CONTROL PANEL
A friend (Marc) just bought a front panel from a 360 model 50 and wants to create a model 50 in FPGA, connected to the panel lights and controls. There appears to be just about enough documentation to create the system, but it will take substantial investigation and interpolation.
Sunday, June 5, 2016
Setback getting my recovered data
RESTORING LOST WORK FROM LAPTOP CRASH
Well, a setback on the road to recovering my work on the fpga and python GUI program arose yesterday. After seeing the list of files that the data recovery service was able to extract from my failed hard drive, which included everything I was worried about, I paid the fee and scheduled access to my data.
The service (Datacent) offers up to 10GB free by FTP, otherwise for an added fee they will load the data on thumbdrives or hard disks and ship them. While the extra fee wasn't a concern, the delay waiting for 'standard shipping' from Canada was an issue.
I found a way to get the maximum useful data to fit in their limit, essentially taking all of C:/Users/Carl but with two big folders excluded to bring it all under the max. I excluded my Dropbox folder, since that content is already accessible from the Dropbox cloud, and I excluded a 3+GB folder of reference files that is very old and available on my backup media.
They gave me the link and password to fetch down 8 individual GB sized segments of a zip archive, all of which are needed to unzip the data. This took hours to download, but finally it was on my disk and I launched 7-Zip to unpack it. Aaaarrggh. They gave me the dropbox folder and the static old folder, nothing else. The exact inverse of my request! Useless.
I have to wait until Monday when they return to work and hope we can get the proper data loaded up. I don't want to think of a scenario where they might have scrapped the data already. While I would still have no big reservation to paying for a thumbdrive of all 35GB of recovered content, I really want to get my key data right away.
I hope they will just put up the 6.08GB of content I requested (all of c:/users/carl EXCEPT for the dropbox and other folder) - but will be anxious until I actually have the data spinning on my laptop.
Well, a setback on the road to recovering my work on the fpga and python GUI program arose yesterday. After seeing the list of files that the data recovery service was able to extract from my failed hard drive, which included everything I was worried about, I paid the fee and scheduled access to my data.
The service (Datacent) offers up to 10GB free by FTP, otherwise for an added fee they will load the data on thumbdrives or hard disks and ship them. While the extra fee wasn't a concern, the delay waiting for 'standard shipping' from Canada was an issue.
I found a way to get the maximum useful data to fit in their limit, essentially taking all of C:/Users/Carl but with two big folders excluded to bring it all under the max. I excluded my Dropbox folder, since that content is already accessible from the Dropbox cloud, and I excluded a 3+GB folder of reference files that is very old and available on my backup media.
They gave me the link and password to fetch down 8 individual GB sized segments of a zip archive, all of which are needed to unzip the data. This took hours to download, but finally it was on my disk and I launched 7-Zip to unpack it. Aaaarrggh. They gave me the dropbox folder and the static old folder, nothing else. The exact inverse of my request! Useless.
I have to wait until Monday when they return to work and hope we can get the proper data loaded up. I don't want to think of a scenario where they might have scrapped the data already. While I would still have no big reservation to paying for a thumbdrive of all 35GB of recovered content, I really want to get my key data right away.
I hope they will just put up the 6.08GB of content I requested (all of c:/users/carl EXCEPT for the dropbox and other folder) - but will be anxious until I actually have the data spinning on my laptop.
Friday, June 3, 2016
Adjusted the 1053 console printer for color ribbon shift, working on other quirks
1053 CONSOLE PRINTER RESTORATION
I decided to hook up my old Python program, the version before I made all those changes post retirement which are currently lost on a dead hard drive. When I started up, however, the code timed out and didn't find the link on the fpga. I had hoped it would still work, allowing me to load the typewriter diagnostics and work on the console printer.
I pulled out my CE Handbook, a set of notes that IBM repair people carried, and found a section on hand code to be toggled in to work various peripherals. The typewriter section was less than twenty words, easy to enter on the console bit switches, and worked. It continuously drives the typewriters with the two characters selected by the bit switches - top 8 bits for one character, bottom 8 for the other.
I then could see it typing everything through the red portion of the ribbon. I referred to the documentation I have to decide how to adjust the tape - whether to tighten or loosen it - so that I get black or red depending on the solenoids pulling the tape.
It only took a couple of minutes to get the tape set properly to switch my printing between black and red portions of the ribbon. Works perfectly.
The console printer still exhibits the few quirks from lubricants that are still being worked out of the pivots. Carrier return is slow, sometimes stalling in the middle until nudged by a finger. Line feed will sometimes begin repetitive feeds until the restore latch works, but fortunately only a few percent of the time. Spacing near the left edge is a bit erratic. I found that programmatic backspace isn't working, which would involve adjusting the pullrod from the operational solenoid up to the release for the backspace operation. My plan is to run the heck out of it to warm up and flush out the old lube.
The carrier return issue and lack of backspace involve more than just lube, and some sort of adjustment or repair is needed. I won't put on the cover or position the printer in its proper seat on the 1130 until these two issues are addressed.
LAPTOP CRASH AND LOST DATA
The recovery service emailed that they were getting near the end of the recovery process and emailed me a list of files recovered. It seems that enough is saved to reconstruct my fpga and python program changes, I will pay and begin transferring files as soon as they make them available.
It shouldn't be long before I have my new GUI code and the latest FPGA logic ready to resume enhancing and testing. This will give me things to do during quiet times when I am not actively working on the hardware.
I decided to hook up my old Python program, the version before I made all those changes post retirement which are currently lost on a dead hard drive. When I started up, however, the code timed out and didn't find the link on the fpga. I had hoped it would still work, allowing me to load the typewriter diagnostics and work on the console printer.
I pulled out my CE Handbook, a set of notes that IBM repair people carried, and found a section on hand code to be toggled in to work various peripherals. The typewriter section was less than twenty words, easy to enter on the console bit switches, and worked. It continuously drives the typewriters with the two characters selected by the bit switches - top 8 bits for one character, bottom 8 for the other.
I then could see it typing everything through the red portion of the ribbon. I referred to the documentation I have to decide how to adjust the tape - whether to tighten or loosen it - so that I get black or red depending on the solenoids pulling the tape.
It only took a couple of minutes to get the tape set properly to switch my printing between black and red portions of the ribbon. Works perfectly.
The console printer still exhibits the few quirks from lubricants that are still being worked out of the pivots. Carrier return is slow, sometimes stalling in the middle until nudged by a finger. Line feed will sometimes begin repetitive feeds until the restore latch works, but fortunately only a few percent of the time. Spacing near the left edge is a bit erratic. I found that programmatic backspace isn't working, which would involve adjusting the pullrod from the operational solenoid up to the release for the backspace operation. My plan is to run the heck out of it to warm up and flush out the old lube.
The carrier return issue and lack of backspace involve more than just lube, and some sort of adjustment or repair is needed. I won't put on the cover or position the printer in its proper seat on the 1130 until these two issues are addressed.
LAPTOP CRASH AND LOST DATA
The recovery service emailed that they were getting near the end of the recovery process and emailed me a list of files recovered. It seems that enough is saved to reconstruct my fpga and python program changes, I will pay and begin transferring files as soon as they make them available.
It shouldn't be long before I have my new GUI code and the latest FPGA logic ready to resume enhancing and testing. This will give me things to do during quiet times when I am not actively working on the hardware.
Thursday, June 2, 2016
Continuing design for use of EMM 32K word memory module
1053 CONSOLE PRINTER RESTORATION
I spent the morning at the dentist and afterwards it was just too hot to work in the shop. Hoping to resume work tomorrow morning when it is cooler.
EMM MEMORY MODULE AS EXPANSION MEMORY
There is some ambiguity in how the interface is to be wired, at least as far as terminators for the twisted pairs coming from me to the memory module. The address lines are 15 or 16 single ended inputs and if they are terminated also, the math gets funny
I would have 52 candidates for termination but only 43 terminators. I had to investigate further to understand this. Fortunately, I figured out why I don't need all 52 signals terminated.
Looking at the schematics, I found three signals (COOP, TIOP and MSOP) that wouldn't need termination, as they pulled up to high in the PCB and are only statically set to configure how the board should work. Additionally, the MP (memory protect) and GR (general reset) signals are designed for startup and powerdown, not during operation, so they dont' need termination.
Selecting the board uses three select signals (MS1, MS2 and MS3) but the board provides three inverters so that the incoming signal can be inverted if that makes sense for the particular board. If the inverter is used, the terminator is on the input to the inverter (XA#) and no transmission line is needed to connect the inverter output to the MS# input. This eliminates three more signals.
As a result of the above, 8 signals were and I can ignore the high address bit when using this in its 32K word x 18 bit mode instead of 64K x 9. Still short a couple of terminators, probably there are 2-3 signals that are static in a full system. Fortunately for me, I am only working with an 18 bit word length and the basic design is for a 20 bit word. Thus, I can skip terminators for data input bits 19 and 20.
I planned out the pin numbers for all the twisted pair signals, plus the terminator pins to tie to each input pin. The remaining task was to tie all the grounds of the twisted pair to the 7 or 8 ground pins on each connector.
I will check the board against the pin assignments, as a sanity check to be sure something isn't off with the documentation.
Time to begin wiring up the connectors. First will be the terminator connections to the input pins. Next will be all the twisted pairs side A to the input pins, and hooking the side B of each pair to some common ground lines. Finally, I will wire up the power supplies to the connectors.
I spent the morning at the dentist and afterwards it was just too hot to work in the shop. Hoping to resume work tomorrow morning when it is cooler.
EMM MEMORY MODULE AS EXPANSION MEMORY
There is some ambiguity in how the interface is to be wired, at least as far as terminators for the twisted pairs coming from me to the memory module. The address lines are 15 or 16 single ended inputs and if they are terminated also, the math gets funny
I would have 52 candidates for termination but only 43 terminators. I had to investigate further to understand this. Fortunately, I figured out why I don't need all 52 signals terminated.
Looking at the schematics, I found three signals (COOP, TIOP and MSOP) that wouldn't need termination, as they pulled up to high in the PCB and are only statically set to configure how the board should work. Additionally, the MP (memory protect) and GR (general reset) signals are designed for startup and powerdown, not during operation, so they dont' need termination.
Selecting the board uses three select signals (MS1, MS2 and MS3) but the board provides three inverters so that the incoming signal can be inverted if that makes sense for the particular board. If the inverter is used, the terminator is on the input to the inverter (XA#) and no transmission line is needed to connect the inverter output to the MS# input. This eliminates three more signals.
As a result of the above, 8 signals were and I can ignore the high address bit when using this in its 32K word x 18 bit mode instead of 64K x 9. Still short a couple of terminators, probably there are 2-3 signals that are static in a full system. Fortunately for me, I am only working with an 18 bit word length and the basic design is for a 20 bit word. Thus, I can skip terminators for data input bits 19 and 20.
I planned out the pin numbers for all the twisted pair signals, plus the terminator pins to tie to each input pin. The remaining task was to tie all the grounds of the twisted pair to the 7 or 8 ground pins on each connector.
I will check the board against the pin assignments, as a sanity check to be sure something isn't off with the documentation.
Time to begin wiring up the connectors. First will be the terminator connections to the input pins. Next will be all the twisted pairs side A to the input pins, and hooking the side B of each pair to some common ground lines. Finally, I will wire up the power supplies to the connectors.
1053 reassembly moving along, plus other activities
1053 CONSOLE PRINTER RESTORATION
Remaining tasks for the 1053 are:
Before I drove over to the Computer History Museum to work on the 729 tape drives, I completed the first two tasks in the 1053 list. When I get a chance to load the typewriter diagnostics into the 1130 I will use it to adjust the ribbon shift tape tension, then wrap up the remaining tasks.
CHM 729 TAPE DRIVE MAINTENANCE
I replaced carbon brushes in six brush blocks, then began working on the one drive that has not had all its brushes replaced. To do this, we moved the remaining drive to the end position in the string, so we could keep that powered down while the rest of the system was usable.
Each brush block has two cylindrical carbon brushes that ride on circular slip rings on the pulleys in the tape drive. They transfer power onto the clutch, which is rotating on the pulley. The clutch will cause the common axle to rotate with the pulley it clutches. The axle has two pulleys, one rotating clockwise and one counterclockwise. The clutches choose whether the tape hub with the reel of mag tape will rotate clockwise or counterclockwise.
Each brush is a cylinder of graphite, with a wider lip at the bottom to keep it inside the holder. There is a copper braided wire soldered to the cylinder, which passes through a spring and is soldered to a terminal on the holder. This allows the brush to move in and out to accommodate variations in the slip ring height and also adjust for wear over time.
There are six holders on a tape drive, each with a pair of graphite brushes. I had to unsolder the worn brushes, use new ones we had made, while reusing the spring and soldering the replacement back into the holder. Each block has a capacitor across the terminals in addition to the connection that supplies power through the brushes to the clutch.
Putting a restored brush holder back in the drive is a procedure that must be done slowly and carefully. If a brush pops off the slip ring and the brush block is moved, it can crack the brush off. We have various homebuilt tools that fit on the block, holding the twin brushes depressed. This gives us clearance to slide the holder into place, tighten mounting screws and verify correct placement before we let the brushes pop out.
A problem on a different 729 drive was finally traced to pitted points on a relay. The relay feeds power through the brushes to one of the clutches. In this case, it was the takeup reel axle clutch that drives clockwise rotation. This will pull the tape upwards from the vacuum column and wrap it on the reel.
Our defect was that the takeup reel was sluggish in rotating clockwise, so that the tape loop dipped below the lower vacuum switch in the right vacuum column and sometimes dumped - when the tape loses vacuum and piles up at the bottom.
When Iggy traced the problem to the relay, he cleaned the points which restored crisp rotation to the takeup reel and eliminated the dumping. We did not complete the brush installation on the last drive, planning to finish it up next week.
EMM CORE MEMORY TO UPGRADE 1130 TO 32K WORDS
I picked up the two 80 position connectors that will connect my EMM 3200 memory module to the rest of my circuitry. I have to wire up the signals with twisted pair cabling and route it to a spare FPGA which I will use to test out the memory. Once I know it is working, I can build the interface board to hook it into my 1130 and give my system a full 32K words of storage.
Remaining tasks for the 1053 are:
- Install faceplate on printer
- Hook up tab set/clear rod
- Set tension for red ribbon shift tape
- Hook up forms empty switch from cover
- Install cover
- Pull cables back to allow printer to sit on its stand
- Put printer in final position
Before I drove over to the Computer History Museum to work on the 729 tape drives, I completed the first two tasks in the 1053 list. When I get a chance to load the typewriter diagnostics into the 1130 I will use it to adjust the ribbon shift tape tension, then wrap up the remaining tasks.
 |
| Moving along with reassembly of console printer |
CHM 729 TAPE DRIVE MAINTENANCE
I replaced carbon brushes in six brush blocks, then began working on the one drive that has not had all its brushes replaced. To do this, we moved the remaining drive to the end position in the string, so we could keep that powered down while the rest of the system was usable.
Each brush block has two cylindrical carbon brushes that ride on circular slip rings on the pulleys in the tape drive. They transfer power onto the clutch, which is rotating on the pulley. The clutch will cause the common axle to rotate with the pulley it clutches. The axle has two pulleys, one rotating clockwise and one counterclockwise. The clutches choose whether the tape hub with the reel of mag tape will rotate clockwise or counterclockwise.
Each brush is a cylinder of graphite, with a wider lip at the bottom to keep it inside the holder. There is a copper braided wire soldered to the cylinder, which passes through a spring and is soldered to a terminal on the holder. This allows the brush to move in and out to accommodate variations in the slip ring height and also adjust for wear over time.
There are six holders on a tape drive, each with a pair of graphite brushes. I had to unsolder the worn brushes, use new ones we had made, while reusing the spring and soldering the replacement back into the holder. Each block has a capacitor across the terminals in addition to the connection that supplies power through the brushes to the clutch.
Putting a restored brush holder back in the drive is a procedure that must be done slowly and carefully. If a brush pops off the slip ring and the brush block is moved, it can crack the brush off. We have various homebuilt tools that fit on the block, holding the twin brushes depressed. This gives us clearance to slide the holder into place, tighten mounting screws and verify correct placement before we let the brushes pop out.
A problem on a different 729 drive was finally traced to pitted points on a relay. The relay feeds power through the brushes to one of the clutches. In this case, it was the takeup reel axle clutch that drives clockwise rotation. This will pull the tape upwards from the vacuum column and wrap it on the reel.
Our defect was that the takeup reel was sluggish in rotating clockwise, so that the tape loop dipped below the lower vacuum switch in the right vacuum column and sometimes dumped - when the tape loses vacuum and piles up at the bottom.
When Iggy traced the problem to the relay, he cleaned the points which restored crisp rotation to the takeup reel and eliminated the dumping. We did not complete the brush installation on the last drive, planning to finish it up next week.
EMM CORE MEMORY TO UPGRADE 1130 TO 32K WORDS
I picked up the two 80 position connectors that will connect my EMM 3200 memory module to the rest of my circuitry. I have to wire up the signals with twisted pair cabling and route it to a spare FPGA which I will use to test out the memory. Once I know it is working, I can build the interface board to hook it into my 1130 and give my system a full 32K words of storage.