Thursday, July 7, 2016

Short day but cleared up a few SAC Interface issues


Wednesday is my usual day to visit the Computer History Museum, socialize with other team members and fix any issues that arise with the twin 1401 systems we maintain for visitor demonstrations.

The museum is engaged in a major renovation of the building to support a much larger exhibit space, featuring a greatly expanded software focus. The plans evolved as various building code and city requirements were added, until it became necessary to include our workroom in the construction zone.

This room is shared by the PDP-1, RAMAC and 1401 restoration teams, contains many spare parts plus tools, instruments and other items needed to keep these ancient beasts in operation. The loss of the space for a few months requires us to improvise in order to protect our supplies and be able to keep the systems working in the interim.

We had a meeting of the various restoration teams and museum staff, including the head of the museum, to iron out details. Once that was completed, we pitched in to organize the packing and movement of the workroom contents, we had to be moved out by tomorrow (Thursday). It was a long day but we had an acceptable, even if less than desirable, plan put in place and the cabinets, workbenches and other items tagged for their placement in temporary homes.

There was one 1401 problem to be addressed, which a few of the team members focused on while the rest of us moved, tagged, packed and planned. One of the 729 tape drives was breaking tape when it transitioned from high speed rewind to the normal vacuum column based tape movement.

The timing of the stop of reel movement, drop of the head mechanism and application of the normal movement capstan were not properly, so the capstan pinched the tape to a halt while the reels were still moving. By the time we had to stop, because of the scheduled demonstration session for museum visitors, we had almost corrected the timing, but felt that the capstan movement was still a trifle aggressive. More tweaking will occur next Wednesday.


I resolved a third of the open questions needed to build a disk emulator based on a Xerox PARC paper from 1979 by the developers of the machine. Almost all of the remaining questions are embodied in the microcode for the 'word task' that runs in the Alto, since it handles checksums, establishes gaps and delays, writes preambles and establishes synchronization for the deserializer.

One of our restoration team members is visiting PARC today to dig through their archives for anything useful to our Alto restoration. This in addition to the offer of parts and access to staff.
Another team member has located a source for new-old stock of the CRTs used in the Alto display. These have an unusual long persistence phospor on the screen, meant to reduce the flickering that results from a 30 Hz refresh rate (60 Hz interlaced scan).


Fixing temporary problem with interrupt level triggering

I had augmented the Storage Access Channel (SAC) feature that connects my FPGA board to the 1130, in order to allow the FPGA to sense and trigger interrupt levels 0 and 1. The feature, as designed and implemented by IBM, only supports interrupt levels 2, 3, 4 and 5. If I were to support virtual or mirror 1132 and 1442 devices, which use levels 0 and 1, I had to add these in. A small filtered power supply and some logic was placed in the 1131 and wired to the appropriate backplane pins of the system.

While I was tugging the 1053 Console Printer cable back into the machine, to allow the console printer to sit flat and level in its base, I did something that caused the machine to be triggering levels 0 and 1 spuriously. Some investigation revealed that I had dislodged the ground feed to my small power supply, which was easily corrected.

Restructuring the GUI

I ran my new GUI with the diagnostic information to determine when the transactional link between PC and FPGA was stalling, having slowed the processor status task down to one transaction each 10 seconds. This allowed me to write diagnostic info as I wrote the transaction, read the response and processed it. Coupled with the LED signals on the FPGA, I would be able to spot the source of the problem I am debugging.

My first tests showed that I do not have a problem normally, but there is a timeout issue that can occur in rare cases I don't understand. I will need to watch this as I work on the interface.

No comments:

Post a Comment