Cleanup after VCF West, fixing system and restoring to operation at home

1053 CONSOLE PRINTER RESTORATION

A spring was lost on the left margin mechanism inside the console printer, causing the margin to shift all the way to the left when hit by the carrier during a return. I have to find a suitable spring and install it, hopefully without having to remove the cover on the printer again.

REPAIRING DISPLAY PEDESTAL

During the move back out of the Computer History Museum, while the 1131 bumped over the front door sill on its way to the truck, the light panel on the pedestal fell completely off. Now I have to confront this festering problem of the poor design and extreme difficulty replacing light bulbs.

Display pedestal after the panel had fallen off

There is one plastic honeycomb still attached, on the lower right, the rest are attached to the rear of the panel as you can see below. These honeycomb rectangles are glued to the horizontal opaque plastic bar that runs across the middle of the panel below, and the end honeycombs are glued to two vertical opaque plastic bars you can just see at the left and right side of the opening in the picture above.

The glue that holds them has failed at the two sides and for the one honeycomb. A friend's 1130 has had all the honeycombs separate. I will attempt reglue these more effectively and then share the method with my friend to allow him to rebuild his system.

Rear view of the panel

The design of the light pedestal has wide circuit boards for each row of 8 or 16 lamps. The boards have a Silicon Controlled Rectifier (SCR) for each lamp, delivering the 7.5V AC lighting power to the 3V incandescent bulbs whenever the logic signal applied to the SCR gate is a 1 (+3V) instead of 0V. Thus only half cycles of the AC power are delivered to the lamp, giving it roughly the right average power as hooking 3V DC to the lamp.

SCR boards from read side

The bulbs themselves have wire leads coming directly out of the glass envelopes, inserted in a nylon holder which is pushed over two round pins on the SCR board. The wires to the round pins can shift a bit to either side.

Bulb in its nylon holder

Inserting 16 lamps into the honeycomb requires pushing 16 of those holders while the board is in the way. Further, the board has wiring from the rest of the machine to deliver 16 logic signals, 7.5V AC and ground. It would be annoying, tedious work to insert just one, as each bulb as to be shifted and pushed into the honeycomb.

There are six rows of boards vertically stacked, thus there is almost no room in between them to touch any lamp. The task is to push 12 of these circuit boards with all their lamps so that every lamp fits in its honeycomb cell, without breaking the fragile leads on the lamps. Yes, the old lamps have leads which readily snap off right at the glass envelope with very little provocation.

This has meant that if I pull out one circuit board to replace a burned out lamp, I am very likely to break at least one other lamps leads (silently and invisibly due to the way it all fits together), so that I am no better off than before I attempted the replacement.

This design is hard to work on. The proof of that is that sometime in mid life of the 1130, the design changed. An alternate design had SLT circuit boards screwed onto the back cover of the pedestal, each board handling multiple lamps by having mulitple SCRs installed. Then, the bulb itself had wires running back to the board. This gave the customer engineer access to replace bulbs without disturbing 16 or more associated bulbs.

I am going to study this setup to figure out the best way to deal with my lamps going forward. I might implement the multi-lamp boards for the back cover, or some other approach, with the goal of maintaining a full set of working bulbs on the 1130 at all times. More later when I decide on an approach and implement it.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Improving seek time modeling of the virtual 2310 disk drive

I noticed two defects in my virtual 2310 disk drive while doing demonstrations at VCF West over the weekend. The first will be extremely quick to fix, the second will take a bit more restructuring of the logic.

When a new disk cartridge is inserted in the drive, the drive logic has retained the last cylinder number that it had reached by seek on the previous cartridge, instead of beginning at the home cylinder.

During the boot card process, if the disk is not already at home cylinder (0), the code loops doing a seek of -1 cylinders until home is reached. I could see it counting down from the prior cylinder. The fix will reset the drive to the home cylinder when it is unloaded or loaded.

The second problem is related to the first. As the boot card looped doing the seek backwards, I could see that each seek took a couple of seconds to complete. It should be much faster. As I investigated I realized that I was modeling the disk arm 'settle' time improperly.

At the end of any arm movement (seek), the drive waits 22.5ms for the heads and arm to dampen any movement related oscillations and be stable enough to sit accurately over the intended track. I therefore waited 22.5ms before issuing the operation complete interrupt on a seek.

However, on the real drive, it works differently. As soon as the arm reaches its target cylinder, the operation complete interrupt is issued. Simultaneously, a 22.5ms settle timer is begun. If a read or write request is issued via XIO during that 22.5ms, the request is queued and does not begin until the time expires. If the timer is already at zero, the read or write begins immediately.

Thus, a program like the boot code which seeks one cylinder then waits for the op complete interrupt to sense if it is at home would have a 15ms wait before each interrupt, but I made it 37.5ms. Then, something else is wrong given the very long time.

My correction is to move the settle timer to an independent process which is fired off at the end of a seek, and to which the logic for read or write will look before beginning its operation. This will be a bit more tricky because I need to hold off storing the XIO function for polling by the GUI until the timer has elapsed.

Finally, I have to look into whatever is causing the overly slow seek delay on the backwards seek. My guess is that I am somehow rolling to a large negative number in the fpga timer for how many tracks to move, which introduces the long delay.

Possible timing error in virtual 1403 function

I believe I have a timing error in how I model the 1403, because on certain lines of a job I will see spurious characters printing, while most lines are presented correctly. The place where garbling occurs is completely repeatable - the same job gives the same bad characters in the same places every time it runs.

This is likely a case where I am giving an interrupt too early, not yet having fetched the print line, yet the software will go ahead and reuse the print buffer in core since it thinks that is now safe. The 1403 has a discrete interrupt cause triggered by having completed the fetch of a print line - I should examine this section of my logic in the fpga.

SETTING UP 1130 SYSTEM IN ITS OLD HOME

The various boxes of the 1130 are rolled into place in the workshop but not yet wired and bolted together, IO units are not cabled and the power connector has not been swapped back to the L6-20 to match my outlets. I can't power up until I complete my repairs of the light panel on the display pedestal, thus have not been in a big hurry to cable, wire and bolt.

The memory blister had to be detached for transportation, separating the core memory from the rest of the system. I have to bolt the two frames together than do some wiring. Two power wiring harnesses are connected to terminal blocks, and three flat ribbon cables are routed to the C gate and plugged into the top row of the memory compartments.

By late afternoon, the frames were bolted together and I had routed the cables to the memory blister, but not yet attached them. I also inspected the disk heads. I can see wisps of ferric oxide on the heads, which is normal wear as these are used. I will clean these with 99% isopropyl alcohol and kimwipes before I put the drive back into service.

Disk head with a bit of oxide to clean off

After dinner, I went out to the workshop and reconnected the power and signal cables to the memory.  On top of that, I removed the L6-30 plug and put back the L6-20 that fits to my house power. Those done, I noticed that one of my two jumpers I recently added to the memory backplane had come loose. I will research this before restoring it and closing up the machine.

Tomorrow gets the jumper fixed, doors all back in place and the disk heads cleaned, leaving only the light panel on the pedestal to restore.