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


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


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.


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


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.


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.


I ordered some candidate bulbs from 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:

  1. longer bare wires allowing more maneuvering room inside the 1130 display panel
  2. 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


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.


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


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.


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


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.