Building out 1130 bulb assemblies, begin construction of 1402 relay tester

IBM 1130 LIGHT PANEL UPGRADE

Today I soldered together more lamp assemblies, eight at a time with breaks to minimize frustration and achy backs. By the end of the day the main board had all its 96 light positions installed. Now that the big board is done, there are a mere 60 to build for installation across the two small boards.

RELAY TESTER BUILD FOR TECHWORKS!

I received all the remaining parts today and began layout of the components inside the project box. I marked up the holes to mount the two relay sockets as well. I located my 20V and 5V power bricks which will drive the coil and contact current.

The design uses 1W resistors to control current through all the contacts, developing about 150 ma on each set and measures the voltage drop of the contacts to determine quality. Small Arduino interface relays fire the 20V pick and hold coils on the relays under test.

I will solder the 1W resistors directly onto the relay sockets, so save the space required for a resistor mounting perfboard as used in the original machine. Thus I just need to mount an Arduino, a small relay board, the two relay sockets, and four LEDs. The two power bricks and most of the USB cable will be outside the project box. 

Repaired 1401 system at CHM, worked on 1130 lights and began relay tester for TechWorks!

1401 RESTORATION AT CHM

Today I replaced all the power transistors in the 30V, 7A power supply for the 1406 box that hosts the additional 12K core locations. When they were all in place, I tested my two rebuilt voltage regulator cards. Both worked, allowing me to set the voltage and have it hold steady regardless of load or input voltage.

I moved on to the Over Voltage Protection card, which crowbars across the supply if the voltage exceeds a trigger level just a few volts above the 30-31 V normal level. The card has an SCR which shorts the output through a 4 ohm power resistor when triggered, the resulting 12A or more should trip the circuit breaker within microseconds.

Our card was quite scorched, as were the power resistors, since the circuit breaker had held open for about ten seconds, allowing almost 500W of energy to cause the resistors to glow. As the resistor is a 10W type, able to handle a few microseconds of current but not the prolonged operation during this failure.

We had a failed voltage regulator card, which let the output surge up to 40V, triggering the crowbar which did its job. The resulting 10A flow should have tripped the breaker rapidly but didn't. I found a circuit breaker on a spare power supply of a different voltage type, swapped it in and we put the repaired power supply back in the 1406 box.

The machine came up, we trimmed the voltage to spec and it performed perfectly during the public demonstration today. Pleased to get the Connecticut 1401 system back in operation after a few weeks of downtime.

IBM 1130 LIGHT PANEL UPGRADE

I am up to 24 soldered lamps on their holders, only 72 more to go for the big board. I do batches of 8 at a time, looping the bare wire ends of the lamps around the .100 spaced header pins, soldering, arranging the bulb and wires, testing on my prototype SCR circuit and then installing each into the board socket.

BUILD RELAY TESTER TOOL FOR TECHWORKS! MUSEUM IN BINGHAMTON

The 1402 Card Reader/Card Punch that is the heart of a 1401 system uses dozens of relays to sequence itself through operations such as reading, punching, run-out and initial card feed. Stan Paddock invented an Arduino based tester that drives a relay, measuring the voltage across the contacts as it operates.

We used it to shake the relay while contact cleaner was applied, then test all four or six SPDT contact sets on the relay simultaneously. It helped us identify relays that needed repair, perhaps replacement contacts or just some bending and burnishing. Without the tester it was very hard to keep the 1402s running.

To help TechWorks! get their 1402 operating, I decided to build them another relay tester based on Stan's design. It uses an Arduino, dual relay board, resistors, two DC power supplies and a pair of sockets. I have all the parts on hand, but have not yet picked out the right enclosure for the build.

Once I have the enclosure and create the mounts for the relay sockets and some indicator LEDs, I can wrie up and test the tool before shipping it to Binghamton. 

Building up self-testing generator inside disk tool, working on 1130 lights

ALTO DISK TOOL

This morning I wired up the sector number input signals to the spare pins where I was generating sham sector numbers tied to the sham SectorMarks I produce. The remaining logic design task is to produce a steady stream of clock pulses on ReadClock and periodic one bits on ReadData, such that the ReadSector logic can complete (albeit with checksum validity errors on every field).

I introduced the code, a variant of the logic that builds the clock and data pulses for writing. Clocks are steady, 100 ns on every 600 ns. Data bits alternate a 1 every 96 clock times (6 words apart) with 0 for every other clock time. The wiring is set to loop these signals around to the ReadClock and ReadData inputs to the board.

First I tested the WriteEntireCartridge to verify that my sector number generator will allow the mechanism to drive up through all sectors writing from memory. Next, I tested a ReadSector to verify whether the stream of bits coming it would cause it to complete a read, albeit with checksum errors since the incoming bitstream is nonsense.

Results of the test were initially poor. I forgot that the inputs from the Diablo are inverted logic, thus SectorMark is always at 1 except for the brief interval when it turns on with a value of 0. Same with the sector numbering, but I forgot the inversion. Also, the clock and data pulses needed to be inverted.

With the inversion change done and another 30 minutes of toolchain time, I reran the tests. This time, things looked much better. The WriteEntireCartridge function advanced properly through all cylinders, heads and sectors writing different patterns that I believe correspond directly to the image file I downloaded into the FPGA.

The ReadSector completed with checksum errors, as expected and a ReadEntireCartridge transaction ran up through all 202 cylinders reads 12 sectors from each of two heads. Untested as yet is the evidence that the data being read was placed properly in FPGA memory and available for upload, but I should be able to look at an uploaded file and see the pattern of 16 words of zero, one word with x0001 repeated over and over throughout memory.

After lunch, I will think a bit about ways I might inject a more realistic bit pattern including causing a checksum match. This might get complex but it is worth a half hour of thinking. I came up with an array of words, 366 long, which represents all the words to be output during a sector.

Triggered by the gotsector signal that informs a WriteSector or ReadSector transaction that it has matched the desired sector number and is ready to read or write, this steps through 16 bit positions in a word each time I am ready to send the next sham bit cell of 600ns, resetting and bumping the word pointer at the end of the word, then shutting down when the word pointer reaches 365 and the last bit 15 is output.

The remaining task is to preload the 365 words of this array with the proper values. For example, 34 words of zero, a word of x0001 as the sync bit, two words of header data, a checksum value, and ten words of zero as the interrecord gap. I will try to do this with a long string of initialization constants if I can sort out the syntax and stand to type in all those binary word values.

Meanwhile, I checked over my watchdog timer function, which flags if the WriteSector transaction ever experiences a new SectorMark before it is done writing out the three records of the sector. It is working properly, writing every sector of data and stopping the write transaction before the next SM arrives.

With the first version of my sham data emitting logic, I did a ReadSector and looked at the checksum validity bits when it completed.  All bad, furthermore when I looked the first two words were inverted. This was the signal itself to define whether it is a 1 or a 0 bit.

Even with this, the result is checksum errors on all three records and the data in memory is nothing like it should be. Time to look over the logic for ReadSector and ReadField and ensure that it is properly storing the extracted data word. Besides that, I put the scope on the stream being sent in, just in case my sham data logic was malfunctioning.

I can see the proper data bit sequence right on the scope, delivered from my sham data generator to the ReadData line of the disk tool input. The logic is not reading properly yet, but I think I saw a flaw in my sector triggering and did a run to fix that up.

Since the Alto stores data in reverse order (last word of a record, then each lower word until one word comes at the end), setting up my sample sector is a bit messy. I started with a sector where the header, label and data records were all filled with zero words. That made the checksum calculation easy - 0x0151 - and I will get a proper match.

Later I can enter the label field in reverse word order and compute as best I can the checksum value for that field. With those set in the sham sector, I would have a good checksum validation for that sector.

IBM 1130 LIGHT PANEL UPGRADE

I don't have my jig built yet but I did solder up a small number of lights onto headers, using the new tinier bulbs I received from China. I will work on small batches until I have all 160 done, hopefully with a jig to speed things up. 

Fixed some defects, cleaned up disk tool

ALTO DISK TOOL

First result from the testing is that I have disabled the mechanism to read and write between the PC and the fpga memory. I stripped out something when I was removing all the combinatorial inputs to the state machines. I have a backup from about a month ago that I could look over and find the missing bits to restore the capability.

I did find what changed, but it was in an area with combinatorial logic creating signals that are inputs to FSMs, which I tried to remove as far as possible by replacing them with clocked processes that produce registered outputs.

A couple of signals weren't easily amenable to registering, without introducing a one cycle delay in responding to conditions, but they were slow changing fields that I thought worth taking a risk with. Meanwhile I will noodle on ways to move all to clocked processes.

The memory read/write logic is not working properly, thus I had to move on to the more challenging approach that removed all combinatorial logic from the mechanism.  This changed the flow enough that testing will have to be focused heavily until we know it works.

By early evening it was writing and reading to memory properly, at least as far as the PC to fpga link is concerned and the contents of the archived image I downloaded to the fpga was reading properly. I then set up the scope to watch it write a sector, to see if it is still doing that properly.

My testbed doesn't provide all 12 sector values back to the logic, thus making it challenging to check out the full WriteEntireCartridge logic. Even more, it can't deliver a realistic input stream of disk data and clock pulses to check out the ReadSector function properly. I believe my ReadSector is hanging waiting for a sync pulse, but I need to route other signals to LEDs in order to test this out.

I now have the eight non-idle states of the ReadSector transaction displayed on my eight board LEDs. I also set up a counter to emit SectorMark signals once every 3.33ms just as the real disk does. This will allow me to try out a WriteSector and observe the pattern on the scope, in addition to determining where the ReadSector is stalling.

My sector signals are working properly and the WriteSector function seems to work perfectly. I still have the watchdog timer switched off - this should fire off if a sector is still being written when the next SectorMark arrives, but I have some flaw that triggers it falsely.

When I attempt a WriteEntire Cartridge, the logic writes the first sector and stalls waiting for a match on sector number 1, since my current testbed is continually reporting sector 0. However, I may be able to loop some more signals to drive the sector numbering appropriately.

I tested the ReadSector function, which should stall on the first field waiting perpetually for a sync bit, but instead it clocks through, issues a checksum error (appropriately for an all 0 field), then waits forever for the sync pulse that starts field 2. I can temporarily fix this up by wrapping signals that issues one bits periodically along with a steady stream of clock pulses.

The big question is why ReadSector thinks it got sync for the first field. Must be an error in the startup of my bit logic.

This will take some additional signal lines, jumper wires and a bit of fpga logic to produce the appropriate signal timings. By the time I retired for the night, the logic for producing 'rotating' sector numbers was complete but not yet wired in. Tomorrow I will need to work on the ReadData and ReadClock simulated signals.

DIGIBARN XEROX ALTO RESTORATION

Marc continued to battle the power supply, discovering a bad regulator and a failed power resistor (so far). I bought the replacement parts and will deliver them to him so he can fight on. We shall see what it takes to get this dual power supply (5V and 5V, interestingly) to work completely. 

Refactoring and ruggedizing my fpga logic for the disk tool

IBM 1130 LIGHT PANEL UPGRADE

My shipment of 200 miniature incandescent bulbs from China arrived yesterday and are waiting for me to begin soldering them onto 2-pin headers for use in the 1130. I think it best if I make a jig that will hold the header and the bulb in place for quick soldering of the wire leads onto the pins. It will give me consistency of results and some speed in preparing the 160 bulbs needed to populate the light panel. 

ALTO DISK TOOL

My disk tool design is suffering from glitches driving state machines into undefined states. The state machine (FSM) then will stall in that invalid state. The state of an FSM is defined in a register using some encoding (examples are binary, one-hot and gray code).

In the simple case of a binary encoding, if the FSM doesn't have a number of states that match the number of total states, some values in the register are invalid. For example, a three bit register encodes 8 possible binary values, but if the state machine has five valid states, coded 0 to 4, then if the register becomes 5, 6 or 7 the FSM will stall.

One-hot encoding uses a string of bits as long as the number of states, with one and only one bit set at any time. Thus, for the five state machine discussed above, the register is five bits long and has valid values 00001, 00010, 00100, 01000, and 10000. If the register ever has more than one active bits, or none are active, the FSM will stall.

The next value of the state register is determined in the FSM as a combination of the current state value and some input signals. If an input signal changes very close to the clock edge, it might produce a glitch where the next state register attains one of the invalid values and stalls.

Developing reliable operation of the FSMs requires careful attention to details. Particularly with externally generated asynchronous signals, such as the Sector Mark value, the value may be changing too close to the clock edge and lead to stalling.

One solution is to have every input signal that generates the next state value be itself registered so that it cannot change near the clock edge. Other techniques include methods to detect invalid states and force the FSM back to some valid state. For example, a parity test of one-hot values might detect an error.

Even with auto correction to recover an FSM from a stall, the result may be an FSM at idle when it was supposed to generate some triggering output. Another FSM may be waiting for that missing output, producing a deadlock. The result is still a stalled system. This can get quite tricky.

My first task is to ensure that I force all the external signals to become aligned to the clock boundary, passing each through a chain of a few registers in a row. This is the classic cure for preventing meta-stable states but also forces signal states to only change on the clock edge.

I completed a set of two-stage D flipflops to pass each outside signal through, getting them aligned to clock boundaries. I used the schematic approach, placing 54 D FF symbols and routing the signals graphically. Previously, I inverted the signals using combinatorial logic from the input pin, but now I invert combinatorially then pass through the two stage D flipflops to get it properly aligned with the clock.

I will then look to see if any of my input signals to important FSMs are passing through combinatorial logic where they might be in transition around a clock edge. As much as possible I will remove such logic leaving all inputs clean, and if I still need the logic then the outputs will be registered so they only change on clock boundaries.

While doing this, I will strip out some logic that had been in place for functions which I will eventually implement, but am not dependent on for the near term archiving and cartridge writing roles. This includes sector update transactions, disk drive emulation and some display functionality.

As part of stripping this down, I am also reviewing several hundred warning messages from the toolchain to look for any that are truly relevant and act upon them. In most cases, these will be leftover signal declarations that are not being used any more, which I can strip out.

I spent about one day in total doing all of this, then set it up for initial testing at home with a wrap-around board of some signals. Full testing will require the disk drive and cartridges  Done for today.

Disk tool wrote cartridge images that boot on Alto; work on CHM 1401 and Digibarn Alto continues

ALTO DISK TOOL

I spent a week chasing inexplicable behavior in the tool, such as the stalling of the WriteEntireCartridge process after the first sectors. I kept exposing signals to external pins and LEDs to see what was happening, until I found the state machine for matching sectors was hung up.

It has six states, two of which are single cycle advances to provide a short pause. I saw that the machine was not in any of the four longer term states. I then added the two short term states to the LEDs. That would either show it stalling in those one-cycle states or more likely getting wedged into an invalid state value that was none of the above.

However, with the six states displayed on the LEDs, it worked properly. I was able to write disk images to our scratch disk cartridge, first booting up and verifying the games.dsk image from Bitsavers.org and then the xmsmall.dsk image.

We took some time to play with Smalltalk, using the latter image, hoping to end up with a compelling brief demo to use on a video and at our upcoming VCF West appearance. We did find that this disk had very little free room, causing some out-of-space conditions as we played.

After we were finally sated on that, I wanted to test out the ReadEntireCartridge function using the Smalltalk cartridge which I could compare to the xmsmall.dsk image from which it was written.

The file I uploaded did not match well at all, which indicates problems in the reading function. My suspicion was that my timing was now off and I was encountering checksum errors as evidence of that bit shifting. To see this, I exposed the header, label and data checksum state bits on three LEDs and resynthesized.

Aaarrrgh. Once again the unit was stalling after reading one sector. When I pushed button 2 to command a seek back to cylinder zero, it triggered the ReadEntireCartridge state machine to start advancing through cylinders but while I was simultaneously triggering seeks.

At this point, I will have to look over my design and find ways to 'bullet-proof' the state machines. There are techniques, for example, to manually specify the encoding of the various states in the state register for a machine, so that I can ensure the register won't glitch into an undefined state. This is my homework assignment for the week.

CHM 1401 RESTORATION

The 1406 memory cabinet power supply remains out of commission. It is a 30V, 7A supply that uses a regulator card to adjust the output to a setpoint from a potentiometer, but the circuit is not regulating. We have swapped all of the transistors and checked just about everything we could think of.

I have a few more tests to attempt on Monday or Wednesday, then we may be forced to pull a power supply from a spare 1406 that we have in the warehouse.

DIGIBARN XEROX ALTO RESTORATION

We put in another full day working on the remaining bad power supply for the Digibarn Alto. It is the unit that supplies 5V for the main logic. Actually, this is a dual 5V supply, one providing high current and another providing a low current second 5V source. Neither supply inside the box is working.

Previously we had identified four bad large electrolytic capacitors and replaced them, found and replaced two silicon rectifier diodes that were blowing the PS fuse, then realized that the 18V and 5V internal power to the power supply circuitry was missing.

Today, we removed and checked the 18V voltage regulator (LM7818 chip) which was good. We then chased down a short to a section of the machine, applied controlled current to that line until we found smoke coming out of a tantalum capacitor.

Replacing that capacitor allowed the power supply to develop its internal 18V and 5V power, but it was still not delivering any output from the unit on either primary or secondary sides. We found a smaller electrolytic inside that was also bad and replaced that by 5PM. Still no output.

Marc continued that evening after Ken and I left. He hunted for and found the 23KHz chopper signal on one side, which was being blocked from driving the rest of the circuitry by a NAND gate. Note that there are no schematics for these supplies available, so that figuring out what is going on is notably harder than a normal diagnosis process.

Marc lifted the regulation line, which is what kept it cut off, seeing some unregulated voltage develop on the primary side. Secondary side is still dead. While working on this, something else failed, likely another tantalum somewhere but alternatively a failing diode or other semiconductor. The power supply is back to blowing 12A fuses.

At this point, the effort required (16 hours so far) is getting out of proportion to the value of continuing to restore this particular machine. It had many bad power supplies, as were most of the spare supplies that Bruce had available. The Alto itself is missing one logic board and one cable, at least.

The monitor was not compatible with the Alto at all, thus had never worked together as a system. The disk drive had a label inside - "smoked" - thus of suspect condition. The spare logic boards he was given with the donation contains missing chips, burned sections and other signs that they are non-working items.

This machine is a great artifact and static exhibit, but is appearing to be a collection of broken parts pulled from working systems and donated to Digibarn. That would imply extraordinary time will be needed to find and repair, if possible, all the nonworking parts that were assembled to make up this artifact.

We are therefore coming to the conclusion that this is a poor candidate for restoration and a bad use of our time, compared to restoring other machines such as the exhibit in the Xerox PARC lobby that were clearly working at shutdown or units at CHM not already restored by Al Kossow. We will finalize a decision within a week. 

Slogging along working on Digibarn Alto power supplies

DIGIBARN XEROX ALTO RESTORATION

We restored three power supplies to operation, replacing bad capacitors and other failed parts. The fourth supply is the big one, delivering +5V for most of the logic, and it was blowing its 12A fuse immediately on powerup. 

We discovered that all the electrolytic capacitors were bad and replaced them - fairly expensive parts to match the mounting method and available space. We then found two of the rectifier diodes were blown and replaced them. Now the fuse does not blow, but no power is produced yet.

On the board, the logic for the power supply is powered by an 18V regulator chip for operational amplifiers and in turn a 5V zener diode, that feeds off the 18V line, for TTL logic. The output of the LM7818 was zero, which can either be due to a failed regulator or a short circuit downstream. We ran out of time to work further on this unit, having spent the day restoring the other three and doing the capacitor and diode replacements.