Wednesday, June 21, 2017

Slogging along working on Digibarn Alto power supplies


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. 

Thursday, June 15, 2017

IBM 1130 light panel upgrade boards complete, working on Alto disk tool debugging


I investigated the three bad SCR positions I had previously uncovered and discovered that in two of the cases, the issue was that the large flat contact surface (anode) didn't flow onto the PCB pad beneath, leaving the circuit open. Resoldering brought them into full operation.

Working through my big PCB, I began to check the continuity to the anode. Fortunately, the SCR type has a stub lead sticking out of the side between the cathode and gate, which I can reach with ohmmeter probes and check to see if the anode is connected to the lamp pin. I repaired several positions that had such faults and each worked perfectly after the fix.

I definitely had to repair the original SCR that is wrong, the one I tested with in my first attempt, since it won't fire until the voltage gets to an unacceptably high level on the input pin. I used my hot air rework gun to strip off the failed part and solder in a replacement. Voila, the board is now fully functional. 

I am now bottlenecked waiting for the light bulbs to arrive from China. The boards are complete but I don't have enough bulbs to load onto the boards and install them into the 1130. When I solder each lamp on the header pins, I plan to encapsulate it in silicone which will prevent the wires from ever shorting together, as that would destroy an SCR. 

I installed quite a few bulbs onto one of the boards and did a test fit to see how easily the could be fit into space without bending or damaging the lamps. The results were excellent, which implies that once I have all the bulbs on their headers and potted with silicone, placing the boards against the honeycomb will be easy. 

Bulbs on headers plugged into sockets on PCB, after test fitting into honeycomb


I worked on the testbed to check out my write cartridge code, since something is going wrong when I attempted to write an entire cartridge on the real disk drive. The logic stopped after the first sector was written and a flag bit indicated an overrun, where the writing FSM is still active when the next sector mark arrives.

I can't see any place that will write the overrun flag, so that must have been a false indication during my testing, something I misread. I concentrated on the logic that steps my transaction through writing the entire cartridge.

I don't see anything that should block the write from continuing sector by sector, so I set up for some testing, simulating the sector mark and disk status to allow my logic to run. I set up the scope to track key signals, the first of which is the WriteGate signal which defines the range of the write to an individual sector. If that is active long enough to run into the next sector mark (3.3 ms) then I may be experiencing overrun conditions.

I see the sector begin writing at the sector mark and the last word of zeroes is written at 3.168ms. The sector has over 160 us of free time before we reach the next sector mark. This reinforces my belief that we are not experiencing overruns when writing a sector.

I wondered whether I might start the next sector (sector 1) while in the midst of a sector mark interval (i.e. it was already logically 1 when I started looking for a sector match), but with the SM only 5 us long, it can't force us into an overrun situation.

I kept looking, focusing on what has to happen for the WriteEntireCartridge state machine to step through the entire cartridge sector by sector. I changed the diagnostic outputs to give me the data that will help pinpoint the cause of any problem.


We have a document of uncertain quality that was built by field engineering specialists back in the 7094 and 1401 era, listing a number of general market transistor types that are said to match an IBM transistor number. We were missing spare 028 and 036 transistors, but the chart gave us 'equivalents' as 2N1038 and 2N456. Those in turn are in equivalence tables to the NTE numbering scheme as NTE176 and NTE104.

Using the NTE numbers, we bought a few of each type to use in repairing the voltage regulator card for the extended memory frame of the Connecticut 1401 system. This card is a differential amplifier that compares the voltage being produced by the power supply to a reference value set on a small potentiometer. The difference signal is amplified by a chain of two transistors (028 and 036) and that drives the base current of the parallel 108 transistors that deliver up to 7A of the regulated voltage.

Normally we can test transistors for signs of death using a DMM, either looking at resistance across the various junctions or using the diode tester function. There should be a one-way path from emitter to base, and a one-way path from base to collector, of the appropriate polarity, but no path from emitter to collector.

That is true for silicon transistors, but germanium ones exhibit enough leakage current that they will slightly bias themselves on, passing current in one direction from emitter to collector even with no current supplied to the base. Further, if a transistor becomes weak, having too low an amplification factor, it will still test good on the DMM but fail to deliver enough current in the real circuit.

We suspect that is what has happened in the voltage regulator card (and a second known failed card which keeps the voltage lower than the first card, but still is not able to drive it down to the set target voltage. Our bad card will allow the voltage to exceed 40 volts, while this second card keeps it down to 33V. The target is 30V, which neither can maintain. Weak amplification would explain this.

I have a Peak Atlas DCA Pro DCA75 tester that will measure amplification, leakage and other factors. I will use that when checking out any suspect transistors. 

Wednesday, June 14, 2017

All boards working on IBM 1130 upgrade for light panel


All boards are built and I began live testing. Lamp test works properly but for some reason I was not getting the bulb to light with the signal pin at an acceptable voltage. A single instance of the circuit built off board works, so this is a matter of interaction among circuits that I have to address. 

In the 1130, the lamp test line is hooked to all SCR gates with 6.8K resistors, while the individual signal inputs are hooked to the gate directly. The 1130 wiring has 6.2K resistors in series with all signals, thus it appears that the SCR gate is hooked to a voltage divider between the +3V logic signal and the ground level that lamp test is normally holding. 

About 1.5V goes into the SCR gate which should conduct. When lamp test is pulled up from ground to +3V level, the SCR gate conducts. The fact that I don't see the lamp lighting with the input signal is troubling. It only works when the voltage is boosted to 3.26V with lamp test floating or 3.9V when lamp test is at ground.

To hook this into the 1130, I have to accept the constraints of that system. Signal inputs are somewhat less than 3V to fire the lamp, AC supply to the SCR is 7.25V and the serial resistance with the signal inputs is 6.2K. Thus, it seemed the current boards wouldn't work. 

I moved the bulb over one position and the results were completely different! I seem to have a rogue SCR or a flaw in that one circuit. I will now populate bulbs in as much of the board as I can, set the input signal voltage to less than 2V and spot any positions that don't work as intended. Moving bulbs around will let me check out the entirety of each board.

I completed both small board checkouts. Three positions didn't work properly and need to have components replaced, but the remaining 59 worked properly with both 1.41V signal and 1.41V lamp test voltages applied. I am off to the CHM to work further on the power supply regulator card I am happy that the circuit is sound and these should work well when installed into the 1130 panel.

Tonight I only had time to test a portion of the big board, since it will require about 20 setup and test operations to move 5 bulbs carefully through all 96 circuits. I may need to float the lamp test line when not active, rather than grounding it as the 1130 currently does, since the grounding will drive the signal voltage to about 55% of its value at the SCR gate. Floating will provide all 100% of the signal voltage to operate the thyristor.


We worked on the voltage regulator card but were ultimately stymied by the lack of any 028 and 036 transistors on hand. We have sourced them and can continue with the repair next week. 

Monday, June 12, 2017

Finished all 1130 light panel boards, worked on 1401 system at CHM


I continued building the final large board today, completing all 96 triacs and resistors before breakfast. I continued with inserting all the lamp sockets and half of the signal pins before it was time to head over to the CHM to work on the 1401 systems. 

I did some testout of the resistors and signal pin wiring, confirming that the first 48 pins and their associated lamp test resistors were installed properly.  After I returned from the work at CHM and evening with the 6800 club at Holders, I finished up the board.
Big board completed
All boards check out, but the power on testing with the limiting resistor will be needed tomorrow.
Three boards in approximate relative position as they will sit inside 1130

One of the 1401 systems (Connecticut machine) was down since smoke poured out of the 1406 memory extension box last Wednesday. We removed the power supply and found the part that emitted the smoke.

The power supply has two SMS cards installed, one regulating the output voltage and the other protecting against overvoltage. If the output of the power supply goes too high, a silicon controlled rectifier is clamped across the output. This technique, called a crowbar, will cause a circuit breaker to pop.

In our case, the breakers did trip but took far too long, since the twin 3 ohm load resistors limiting current in the crowbar carried 10 amps each for enough time that they scorched the board underneath and burned insulation off of nearby wires.
Trace side of crowbard card

Component side of crowbar card
The cause of the crowbar activation was the failure of the regulator card, allowing the voltage to soar up to more than 40V, instead of the nominal 30V expected from the supply. We don't have any spares for this card type, thus will have to diagnose and repair the card before we can restore the 1401 system to operation. We have replaced one transistor so far but the card is not yet working properly.

Sunday, June 11, 2017

Building the IBM 1130 light panel upgrade


My PCBs arrived along with the remaining components, while I was on my trip to NY. I found that I hadn't specified the right size hole to mount my turret connectors directly on the board, but I thought I had a workaround that would retain the turret connectors. It did not pan out, so I will be soldering the power wires directly to the board. 

Small board (one of two)
Large board (only one required)
I will begin to build one of the boards to test it on the 1130. First step is to solder down the surface mount resistors, as they are the smallest and closest to the board. Second step is to solder the surface mount triacs in place. Third is to mount the lamp sockets on the bottom side. Fourth is to mount the signal pins on the top side. Fifth is to mount the turret connectors. 

I am concerned about shorts in my soldered lamp holders, since the bulbs have bare wire leads. This vulnerability affected the original IBM boards and will affect mine too, destroying the Triac immediately. I have two ways to address this. 

First, I will work out an insulation scheme that protects the bulb leads and prevents possibility of a short. Second, I will put in a current limiting resistor to the AC line while I am checking out the light circuits one by one, so that I will only have one of three cases for any light circuit:
  1. The lamp lights correctly and all is good
  2. The lamp does not light due to a bad bulb or open circuit, replace and repeat test
  3. The lamp does not light because holder is shorted but the resistor protects the Triac from catastrophe
By Sunday evening I had the small panel for the far right side completed and a number of lamp holders guaranteed to be short free. First, I fitted the board into place to confirm how it sits inside the 1130 pedestal box on the face of the honeycomb. That was a perfect fit.

Trial fit of one small board against honeycomb
As you can see from the board above, not every position is used on the small boards. The first board above only has 27 bulbs out of the 48 possible positions, thus I only installed components on those 27 spots. The middle board, also a small one, has 33 lamp positions utilized The final, large board has every position implemented, a total of 96 lamps.

I began construction of the second small board, installing all the resistors, triacs and lamp sockets by dinnertime. All that was left were the 33 signal pins and the three turret connectors. Soon those were installed as well and I could move on to the final large board. A very long process, soldering 387 components, so didn't finish this evening.

Tomorrow, I will hook them up to test power with the limiter resistor and check each light circuit. Since my hot resistance of the bulb is around 50 ohms, my limiting resistor to protect against shorts can't be more than about 10 ohms if I hope to see the filaments light.

I am still waiting for my 200 light bulbs coming from China, which I will then have to solder onto the holders to plug into the sockets on my boards.

Major progress on 1401, 1311, 729 and 1402 restorations


1401 System

Our team arrived at our hotel late on June 6th, worked on the 7th, 8th and 9th, with travel home on the 10th. There were tours, picnics, interviews and other events that took time, but we did get a decent amount of time working on their equipment.

The 1401 system had been previously powered up by the local team, but it was not able to do arithmetic correctly. When we arrived we started to work on that problem. Other problems arose that had to be dealt with, such as when we lost the ability to store the A bit in any position in memory. 

The A bit problem manifested itself as a C bit (checksum) error, which we began tracing through the C bit logic until we realized that the machine was also not holding the A bit, whose absence made the C bit value incorrect.

We found a total of three cards that were malfunctioning, replaced them and had data storing properly again. We went back to work on the addition failure. The machine could correctly add 1 + 2, for example, but not 2 + 2. 

We quickly realized that we had a 'hot' 1 bit, where any arithmetic result would have the 1 bit turned on regardless of its proper value. Thus, 1 + 2 produced 3, but 2 + 2 produced a 5 since the 1 bit was erroneously set. 

We were tracing this from the adder logic itself out to the memory. The way that arithmetic works in a 1401 is that the result character of an addition (or other arithmetic operation) is stored in memory without going into the B or A register. Thus, along with the wrong value, if the 1 bit was not intended to be on, the parity would also fail. The 2 + 2 case stored a 5 (1 and 4 bit) without the C bit since parity should be odd, flagging an error due to an even parity.

The 1401 uses wired-OR logic, where multiple gates have their outputs shorted together to form an OR of the conditions of the contributing gates. This means when you have the extra 1 bit set, it could come from any of several gates that are shorted together. 

We did lots of oscilloscope work probing the state of various signals in the path from the adder to where it stores in memory. For quite a while, we saw that no set of inputs should produce a 1 output yet it was there. 

To do the scoping, we set up a short loop to set up fields for an addition, perform it and loop perpetually. We had the most success triggering the scope by a signal that is activated when the adder is ready to store its result in memory. 

The 1401 system encodes numbers as binary coded decimal (BCD) characters, but the arithmetic hardware itself uses a system called qui-binary by IBM. Thus, the input digits are converted from BCD to qui-binary, arithmetic occurs and the output digit is converted back to BCD. 

Qui-binary has a five value and a two value section, the quinary (base 5) and binary (base 2) portions. Thus, we had to find the circuitry that assembled the BCD bits from the quinary and binary states. We looked at the first gate generating the 1 bit and found that the adder was giving the proper value. 2 + 2 had only the 4 bit set, not the 1 bit. 

The 1 bit value then transitioned through a small number of gates until it reached a double negative AND gate whose two sections were ORed together and also wire ORed to several other gate outputs. This wire OR output is the drive for whether a 1 or 0 is written in the 1 bit during the current memory cycle.

The top of our double AND gate had the 1 bit value from the adder and the overall signal to write an arithmetic result to memory. The bottom had the value of the 1 toggle switch on the console and the overall toggle switch to manually enter data into memory. Thus, this double gate drives a 1 either because of manual entry or arithmetic results. 

The inputs to the manual entry section don't change unless the toggle switches are moved. The inputs to the arithmetic result section were 1 for the 1 bit value and a pulse to store. Since this is a negative AND gate, it only passes a result if both inputs are negative. It therefore should NOT write a 1 into memory.

The wired OR output of this and the other gates showed a positive pulse, writing a 1, at exactly the timing and shape of the enabling pulse for arithmetic result storing. Inputs don't meet the conditions of an AND but the output pulses. 

Swapped the card but no change. Examined inputs to all the other gates wired into this output, but none had conditions that would fire. Swapped each of the other cards just in case, but no change. Looked at the wiring on the backplane near the card. Tested the signals on the card itself, with an extender, to see if there is a socket problem. 

After half an hour of increasingly fanciful hypotheses and tests, looking for some analog issue or hidden path to drive the erroneous 1 output, the problem went away. It was the end of a workday and inexplicably the addition was no longer producing a hot 1 bit in the result. 

We could tell instantly because my looping program encounters the parity error when the hot 1 overrides the intended 0 value for that bit. This shows up as a red light in the storage block on the console panel. When that stopped lighting we checked the stored field and found that 2 + 2 was now 4, not 5. 

We came back the next morning, and extended my program to add multidigit fields, rather than a single digit for each operand. The red light flashed again while the program looped. A look at the result field showed that our problem had simply changed from a hot 1 bit to a dead 1 bit - always a value of 0. 

Thus, 2 + 2 properly produced 4 but 1 + 2 produced only 2, not three because the 1 bit was permanently set to 0. The scope went back on and we began tracing signals again. At this point, I noticed the the input to our double AND gate, arithmetic results section, was at ground potential. Since this is a T level logic signal, the only valid values are -6V and +6V.

I looked at the ALD page and saw that our input to the double AND comes from another logic compartment. The signal moved over our backplane to a paddle card that would route the signal to the other compartment. I checked continuity with a meter to the paddle card. 

Since continuity was good on the original compartment (01A3) we moved to the arithmetic unit compartment (01B3) and verified continuity over the cabling between compartments. In fact, we traced it all the way to the output pin of the card that produces the arithmetic 1 bit value. 

The output of the card was at ground (invalid level) but the input to gate was valid and correct - either a 1 or a 0 depending on the arithmetic result. We swapped that card with a spare and resolved the problem. Apparently this card was producing the hot 1 bit through some weird failure mode and got worse suddenly yielding the permanent 0 value for bit 1. 

We proceeded to check out many variants of arithmetic - different length fields, carries, and subtraction for example. After this proved arithmetic is good, we went on to check other instructions. Among the instructions tested successfully were:

  • Move
  • Compare
  • Branch
  • Branch when Equal
  • Add
  • Subtract
  • Set Word Mark
  • Clear Word Mark
  • Move zone
  • Move digit
  • Zero and Add
  • Read a card

As far as we can tell without running the complete and comprehensive diagnostic tape, the 1401 is fully operational. 

1311 Disk Drive

The 1440 system came with a 1311 disk drive that so far was only able to spin the platters. The arm could be manually pushed out over the disk surface but the heads never loaded (lowered to fly on the surface). Iggy worked on this, beginning with a careful inspection and full cleaning of the disk heads and disk pack.

He discovered a misadjusted microswitch, several missing logic cards and a few other things over the course of the three days. After one day, the drive would sequence up to the point that it moved the arms all the way to the inner cylinder, but was not jumping back to the outer cylinder and loading.

By the time we left, the drive completed its sequence, loaded the heads and was fully operational as far as we could tell with the limited testing we completed.

729 Tape Drive

Iggy pulled out one of the tape drives to work on. He found a failed microswitch that kept the vacuum pump from operating, a few other problems and then had the motor that lowers the head onto the tape fail to spin. He determined that the motor itself works but the relay to control it is not operating properly. Since he didn't have documentation for the drive he couldn't finish getting it working.

1402 Card Reader/Punch

The local team were concerned because they had found fragments of rubber belts in the bottom of the machine, but had no spares to install. Frank examined it carefully and found that the only two belts which were missing were both for the punch side. One is critical, as it drives contact breakers in time with the feeding process, but the other is only needed to move the stacker rollers for punch output. As long as one can accept that all punched cards will fall in one stacker, it isn't needed.

We were able to trigger a read reliably by issuing the appropriate 1401 instruction (op code 1) although the data may not be scanned in properly due to a premature reader stop. One cause of this is that the alignment pins to hold down the first reader block were sticking, thus not holding the brushes fully in place.

Frank was able to rebuild the alignment pin mechanism. The brushes in the 1402 are kind of scraggly, so we will send some spare brushes to this museum after we return home. Another problem was that doing a non-process runout (NPRO) operation didn't reliably trigger the read clutch, which we attribute to a problem with the relay logic that drives the 1402.

The machine has many relays which sequence through operations such as reading, NPRO, punching and handle conditions like the hopper emptying. The contacts tend to oxidize over time if not used. We couldn't look at the suspect relays because we didn't have the documentation to tell us which relays were involved. We will send the museum a relay tester that has helped us find and fix bad relays for our 1402s.

Wednesday, June 7, 2017

Working on 1401 and other gear at museum in Binghamton, NY


I have been out of touch for a few days while traveling and helping the teams at TechWorks! in Binghamton with their 1401, 1440 and other IBM gear. Two way exchange of advice and ideas plus a chance to see some historic IBM and other gear. One non-computer example is part of the lunar module simulator used by NASA to train the Apollo astronauts for their landings on the moon.

We are currently chasing a problem in the 1401 system here which causes Add instructions to inject a 1 bit into any result. If the result of the added characters already had the 1 bit set (was odd) then no harm, no foul. However, if the result was even, the added bit causes a parity error in the work going into memory.

The signal only passes through a few gates from the point where the adder converts the qui-binary result into BCD, with a signal called Arith 1, to the point where it drives the inhibit line on the 1 bit core planes. The way core works, inhibit lines must be active to keep a core from flipping on, leaving it at the zero state created during the readout of its previous contents. If no inhibit, then the core is set to 1 at the end of the memory cycle.

Our tools were inadequate to watch the signals and find the spot where it is failing, but we will have access to a more modern storage scope tomorrow when we hope to find and eliminate the problem.

We will also help inspect and clean some 1311 disk drives, as well as one of the 729 tape drives for the system. We have already done some inspection of their 1402 reader/punch and are finding the part number for one missing rubber belt.

Thursday, June 1, 2017

Making good progress on disk cartridge writing but not there yet


I continued to solder bulbs onto headers to use with my new PCBs, including one of the original size bulbs used by IBM in the 1130. It is possible that with great care I could use original size bulbs and get them to fit into the honeycomb blocks, but that won't be necessary if my newly ordered mini bulbs arrive from China.

Two mini bulbs and one original sized, installed on headers


I made some adjustments to the logic related to when the new parallel word is prepared for access by the serializer, as it will be important to having the checksum written out properly. With these changes it appears I am writing the sector correctly.

The timing is still off, with the crystal on my board running 9+% slow. I bought some LVCMOS oscillator modules and stuck one on the board, but the clock did not run with it in place. A quick look at the documentation gave me the correct pin for that clock signal - U9 - and I reran the tool chain and tested again.

The error persisted, I dug deeper and found a spare cycle in my clock FSM. I fixed it. Measuring again, I found the inter-record time (from sync bit to next sync bit) to be 144, close enough to the 134.4 theoretical timing. I will put the clock module on the other two fpga boards so that they all run at the (same) intended speed.

Next up was a validation that the checksum is working properly. To address this, I set up a spreadsheet with the eight words of the label record and calculated the XOR of those with the seed value 0x0151. It came to 0xA32C

The value being emitted by the disk tool is 0xA32C so this is working well. I ran over to Marc's to give it one live trial before I leave tomorrow for the visit to the TechWorks museum in Binghamton, NY.  The attempt to write an entire cartridge failed with an overrun error, where the write is still active when a sector mark arrives.

Wednesday, May 31, 2017

Digging into the disk tool writing function and building lamp holders for the 1130


I know just about where the logic is going wrong, but not yet why. I added some more diagnostic output from the fpga board and set up for testing. I wanted to see either the output data word being loaded into the serializer or the running checksum.

I can see the two correct words of the first record being written out (both 0x0000) and the running checksum is correct through these as well. It is when the logic shifts to write out the checksum that I find the value going awry. This points me right at the logic where I transition from having written the last data word and set up the checksum as the output word.

I also looked to check the data words being written out for the second (label) record and the beginning of the third (data) record. Everything was correct - the preamble and postamble, the sync word, and the contents of those records matched exactly the cartridge image I had downloaded into the fpga board.

This leaves only the checksum to resolve and I should be able to write a cartridge image with my tool and boot it on a real Alto. I hope I can nail this before I leave for my visit to the east coast, where a few of the 1401 restoration team will visit with the Center for Tech Innovation (TechWorks) in Binghamton and share ideas as they restore their 1440, 1401 and raft of peripherals.


I have begun building all the plug-in incandescent lamp units, soldering mini bulbs to a 2 pin header that fits into the sockets which will be on my PCBs. I had hoped to have enough mini bulbs to avoid any of the regular sized bulbs from the existing panel, since these have relatively tight clearances in the honeycomb blocks.

Once I looked over my inventory of bulbs, however, I found that I only had about half the quantity I need. I did find a source for a couple hundred mini bulbs of the type I need, which should be shipped from China and arrive in mid June when I am assembling the panel boards.

I have about 40 more mini bulbs on hand, which I can solder onto headers in advance of receiving the shipment from China. This would allow me to stock one or both of the smaller PCBs and do testing even if the new bulbs haven't arrived.

Tuesday, May 30, 2017

Resolved one anomaly and digging into the other, in the Alto disk tool


My first test today was to measure the clock frequency directly. It runs at roughly 45.5 MHz which gives a clock duration of about 22.2 ns. This accounts for the timing discrepancy. Time to figure out a more accurate timing method.

One possible complication is that different FPGA boards might run at other frequencies, so that a correction made to fit the board I am testing here might not work properly on a different board at Marc's house or one used by Al Kossow.

My solution is to use the external oscillator socket on the boards, plugging in some new 50MHz oscillator modules I am buying from Digikey. These are accurate to 30 ppm, which locks the frequency to within 1.5K of the target. I have no idea why my board is off so much but the tool must operate very close to the target in order to drive the disk properly.

I then set up the logic analyzer, which is a tedious effort, in order to watch the checksum calculation to determine what is throwing my written checksum off. The initial setup had some problem seeing a reliable clock pulse, so I reconfigured the fpga to output the clock on a different type of output pin, requiring a 40 minute turnaround of the toolchain.

I watch the checksum flip from its correct value to a wrong one - not sure where things are in the overall flow but emitting helpful signals will be the focus on the next round of changes. It appears that the seed is set properly as 0x0151 but the next word ORed in is 0x8342 which doesn't exist in the sector image.

My first record should stay with the checksum 0x0151 since the two data words are both 0x0000 and that doesn't alter the checksum. The second record would be seeded with 0x0151 and then OR in the eighth word of the label, 0x0079 which would produce a new checksum of 0x0128

Until I can know where we are in the process - which record and what 'word time' - I didn't have enough of a clue to spot the flaw. 40 to 60 minutes later, I was ready to test again. The checksum goes awry right away with the header record, first data word being handled.

The proper data is being written to the disk, but somehow the checksum isn't updated with that data. I will map out the FSM that writes the record to the disk, looking carefully at how the checksum is handled.

Monday, May 29, 2017

Good progress on the disk tool debugging


I set up a simulation testbench to closely examine the serializer, a module which loads parallel 16 bit Alto data words and shifts them out one bit at a time upon request from other logic in the disk tool. Symptomatically, I am seeing nothing but '0' bits shift out of the serializer and it never raises the signal asking for the next 16 bit word to be set up for loading. 

Most of my logic wasn't being executed. I stared for a while then saw it. My first test in the process checks to see if we are at startup, when an input signal is '1', to set up initial conditions. Once that goes to '0' it checks for the request to send the next bit and does its thing.

However, I coded the first test this way:
if loadword <= '1' then
The sequence <= means assignment, not a test for equality! The line actually forced the reset input signal to be on and always passed that first test. It never got to my other logic to serialize and emit output.  It should have read if loadword = '1' then

With that moronic error fixed, the serializer began to work. I could move back from simulation to the real testbed and see that I was now emitting the signals that I should. I could zoom back out and watch the actual written stream to verify that it wrote the preamble, sync word, two header data words, checksum, postamble, etc.

I found the system emitting the preamble of zeroes, the sync word and first two data words, but the checksum being emitted was incorrect. Further, once it wrote the postamble the clock shut down and the remaining two records were not attempted.

It is time to hook up the logic analyzer and record what occurs during the writing of the first field. I will also capture the running checksum since the first problem I saw was an incorrect checksum being written. 

The watchdog logic shut down the write sector operation before the first record was complete - clearly wrong behavior. I temporarily turned off the watchdog logic and was able to write the entire sector on the testbed.

The overall pattern and data content appears good, at least up to the first data word of the label (second) record in the sector. I looked at the signal which is output by the serializer each time it is ready for the next word to be loaded and the count between the sync bit of the two records was indeed 14 word times, just what it should be.

The sync words are correct, the two header record data words are correct, the postamble of that record and the preamble of the label record is correct, the sync word for the second record and its first data word match exactly.

However, two things are not perfect yet. First, and most seriously, the checksum being written out is not correct. Second, the length of time between words is a bit too long, so that the fourteen word times I wrote out take over 158 us to produce when the expected duration is closer to 135. An 18% elongation of each bit cell would produce this timing.

I will be simulating the bit cell timing machinery tomorrow to either fix it or determine that I have a problem in the oscillator on the FPGA board. If the fpga board runs a bit slow, at 4.24MHz instead of 5 MHz, it would create this behavior.

Sunday, May 28, 2017

More work on IBM 1130 display panel upgrade


I began disassembling the existing IBM boards and wiring inside the display panel pedestal box. The boards and attached lamp holders were pulled from the white plastic honeycomb and all the yellow signal wire clips were detached from the rear of the boards.

Lamp holder and PCBs pulled out of honeycomb prior to removing yellow signal wires
Signal wires laced in position, by row, for attachment to my boards
The signal wires are laced together by the IBM manufacturing plant with each of the six rows grouped together and the wires for each column position exiting along the bundle at the appropriate point. This makes it easy to attach all 96 register signals to the right pins on the boards.

A terminal strip on the right side (from the rear) brings up the AC, lamp test and common voltages and distributes those to the individual PCBs for each row. I detached the lugs from the PCBs and removed the mass for storage, just in case someone wants to restore this to original condition in the future. 

Removed innards to be replaced by my upgrade
My three PCBs will sit flat against the honeycomb blocks, having the signal pins on the side facing the rear of the machine for attachment to the yellow signal wires. The PCBs have three turret connectors to wire them to the AC, lamp test and ground lines at the terminal strip. On the front side of the PCB, facing the honeycomb, are 2 pin header sockets where each light should be placed. 

Honeycomb blocks with a paper image of one board placed roughly where it will sit
There will be a huge increase in room inside the pedestal box with my boards in place. They are pulled back to gain access to the 2 pin socketswhere each light is plugged in, in the event that a bulb burns out and needs replacement. 

I will remove each light bulb from the existing plastic holders. These bulbs have wire leads that I will wrap around a 2 pin male header, slide a short section of paper straw over the exposed pins, and plug into a socket on the PCBs. First up, I have to remove all the working bulbs from their IBM holders in preparation for installing them in my new holders. 

I haven't fabricated the holders that will keep the boards in place against the honeycomb, with the bulbs sticking forward into the honeycomb at each location that should light up. I expect to use some rubber insulation as a standoff between my PCB and the honeycomb, thus I will wait to measure the size of the holder until the PCB is in its final location. 
Wire lead bulbs in the IBM oval plastic holders, attached to the IBM PCBs
I made up a sample light assembly to see whether I need to make any adjustments to my plan. If the bulbs are susceptible to too much tilt or misalignment, it will make it very difficult to get all 96 to slide into their holes simultaneously when I install the big board. 

The bulbs themselves are quite small, leaving plenty of margin to fit into the hole, although the 2 pin header on the bulb is oriented vertically while the honeycomb holes are wider horizontally than vertically. I had no choice, a horizontal layout for the sockets didn't leave enough room for the thyristors and other parts. 

I was able to solder in a miniature bulb onto a pin socket, rather than a machine pin header, with excellent control of the orientation and stiffness. When I attempted this with an original bulb used in the 1130, a much larger cylindrical bulb, I found the leads too oxidized to solder readily. Fifty years of oxidation built up quite a thermal barrier. 
Mini bulbs soldered into pin socket - bottom socket a quick and dirty test
Testing bulb and socket with thyristor circuit
Even if that were solved with plenty of flux, the bulbs are close enough in diameter to the hole in the honeycomb that alignment becomes too critical. With 96 bulbs in the matrix, even a few off center by a small amount would block the PCB from fitting into place. The solution is to exclusively use miniature bulbs, considerably smaller than the holes. 

Original IBM bulb with oxidized leads

IBM bulb holder, wedges into hole in honeycomb block

I set up an extension board on the fpga, allowing me to tie various inputs to 0 or 1 level and to loop back some outputs to the inputs. The goal is to drive a sector write operation without having a real disk drive attached, so that I can debug everything at home. Waiting for a few hours at Marc's lab is dragging this out way too long.

With the testbed set up, I began observing status signals emitted on the PMOD connectors where I had output likely signals that would point at the malfunctioning section of logic. With only a few minutes work, I focused in on the logic that is misbehaving.

This appears to be another of those cases where VHDL logic that appears correct does not work in the real world. The serializer should be counting bits as it shifts them out, raising a signal to request the next word when the last bit has shifted out. The raised signal isn't raised. Tomorrow I will set up a test driver and synthesize the behavior of the module.

Saturday, May 27, 2017

Finished designing PCBs for the 1130 display panel, ordered all remaining parts, boards to foundry


In addition to the two swapped thyristor and output socket components, I found that some of the 2 pin headers, which align the lamps to the holes in the 1130 panel, were misplaced slightly. I realigned all the sockets and properly placed the register 2 bits 4 and 5 components. 

Next< looked over the detailed signal and power routing, finding many suboptimal layouts that I could improve by manually routing traces. In many cases, signals were routed on the bottom side of the board and vias placed to move the signal between top and bottom, when there was a direct top side routing possible. 

Right side is autorouted with extraneous use of vias, left side is hand routed alternative

I was able to remove most of the vias (through holes that conduct a signal from one layer to another). I also bumped up the trace width of the power lines (from the anode of the thyristor (big pad) to the 2 pin header that connects to the lamps.  Now satisfied with how the board is configured, I printed an actual size copy on paper and verified alignment inside the 1130 pedestal panel. 

Vertical clearance will be tight, requiring the board to be tilted to get inside the pedestal box, but will fit in place with enough room to work properly I think. I will measure the height inside the box precisely as a cross check. I did compensate by every so slightly shrinking the height of the board, taking a smidgen off the top and bottom margins and even a bit off the left edge. 

Final layout for the PCB that drives the 16 x 6 register display
I also test fitted the actual thyristor and resistor parts on the paper copy to be sure that I didn't make a stupid error. Those appear fine as well, giving me adequate clearance between physical parts. The thyristor, resistor, turret connectors and 1 pin headers all fit on the top surface of the board, while the 2 pin headers are placed on the bottom side with only their pins sticking up for soldering on the top layer. The only soldering required on the bottom layer is for the 1 pin headers. 

Since this is so tight, the order in which I solder everything will matter. I am not sure whether the resistor or the thyristor goes first, but the headers get soldered last. The turret connectors are fasted with nuts, not soldered, depending on mechanical pressure to make a good electrical connection. 

With this presumably ready to ship off to the PCB manufacturer, I started in on the two boards that handle the remaining lamps inside the pedestal, each an 8 x 6 matrix of possible lamp positions. In practice, the 1130 does not use all 48 positions on either board, but I could lay this out symmetrically and omit components on the unused positions.

I copied and cut down the schematic and PCB files, before making the remaining adjustments necessary. There is not a wide free area for the three turret connectors, thus I will have to be clever about where I place them to have a usable board that can fit in the spots required.

In fact, I noticed that part of the bottom row of lamps is unused on both boards, so I simply removed row 6 columns 4, 5, 6 and 7. That gave me plenty of room to move the three turret connectors and still have a small board that will fit side by side where it has to inside the 1130 pedestal box.

Small PCBs to implement the remaining lamps (other than the six major registers)
The pedestal box has a matrix of 5 x 5 plastic honeycomb units organized as two rows of seven blocks each. Horizontally, each hole may be used but vertically, only the odd numbered rows have lamps installed. Thus, the six rows of the panel sit on rows 1, 3 and 5 of the top honeycomb block then on 1, 3 and 5 of the bottom block.

Honeycomb blocks (1 is missing in the picture)
There are a total of 35 lamp positions horizontally across all the blocks, but only 30 are active. The registers sit in the rightmost 16 spots (viewed from the rear of the machine), thus take 3 whole honeycomb blocks plus on position of the next block. One open position sits to the left of the last register lamp, which is open space to accommodate the edges of my big and little PCB boards.

One of the small boards implements six lamp holes, the leftmost honeycomb plus one hole in the adjacent one. My board covers eight holes horizontally, however, so my board sits across two more hole positions in that adjacent block.

The block has two remaining hole positions, that will remain free or have just a smidgem of the small board edges over them. The other small board sits over the next eight hole positions, en entire block plus two holes of the block shared with the end of the big board.

Counting from left to right, in the rear, for the 35 possible lamp columns implemented by the seven honeycomb blocks, we have my first small board covering holes 1-8, the second small board covering holes 11 to 18, and the large board covering holes 20 to 35. The edges of the left two boards have holes 9 and 10 open and will have no problem fitting side by side.

The edges of the middle (small) and right (big) PCBs have just row 19 open to accommodate them, but that is sufficient for them to fit side by side. There is 1" between the centers of the end lamps of the adjacent boards, but they have less than 1/2" of margin from the lamp on their edges.

I will remove the mini PCBs that are the original IBM mounting spots for thyristors and to which the bulb holders are fit, detaching the wires from the terminal blocks which feed them. This will be saved so that the machine could be restored to original condition if someone so desired.

The turret connectors arrived today, spurring me to purchase all the 2 pin sockets and header strips needed to finish the construction of the boards. I picked up paper straws, which I will use as a barrel to hold the miniature light bulbs soldered onto their 2 pin headers so they can be plugged into the sockets on the boards.

Next up, I shipped off the boards to the foundry, using to panelize them. I should get them in about two weeks. Nice high quality 4 layer boards that cost almost $250 including shipping.

I am excited enough about this that I will go out and begin removing the original holders right now. I do have to separate out all the bulb holders, because once I have the headers and straws I can remove the bulbs and begin assembling all the plug-in lights.

Alto event planning, work on IBM 1130 panel upgrade and on disk tool


I attended a meeting today at Computer History Museum to discuss holding an event to celebrate the Xerox Alto and other innovations, leveraging a few restored machines and many of the people who made those inventions. We also had staff from the museum, both historians and the live event producers, plus Marc, Ken, Luca and me for our restoration team.

Some of the people at the meeting who worked on these systems at PARC and are going to help with the upcoming event: Chuck Geschke (co-founder of Adobe), Doug Fairbairn (a founder of VLSI Technology), John Shoch (former president of Xerox Office Products Division and venture capitalist).

A number of the current staff of PARC were there too and will be involved. We expect to have the Alto we restored, at least two Altos restored by Al Kossow, a networked link to an Alto at Living Computer Museum, and hopefully Bruce Damer's machine which we are attempting to restore.

I did some diagnostic work during the brief time we had at Marc's lab today. I found that my synchronization between the various state machines involved in writing was not working properly, leading to a sector with nothing but zero output bits

I attempted to read a cartridge that wasn't archived properly earlier, but all records of all sectors had checksum errors reported. I used a scope to capture sector 0 on read of the cartridge in question. The data appears properly formatted so the issue is some regression error when I updated my logic.


I thought I had everything placed properly, it routed successfully and I worked my way through the minor manufacturing issues, such as silkscreen component outlines touching via hole pads. I was almost done when I spotted two light positions whose components were swapped around - register 2 (Storage Access Register) bits 4 and 5.

PCB layout - some swapped components to be corrected
While I could swap the input signal wires, it ruined the symmetry of the trace lines and complicated that section. I therefore planned to move things into their intended place and manually draw the traces to connect it properly. As you can see from the picture, it is a very dense board where the parts barely fit in place. 

Thursday, May 25, 2017

Building PCB design for IBM 1130 light enhancement, plus working on disk tool debugging


I think I have worked out some light modifications to allow me to trigger my disk tool for writing, without having an actual disk drive attached, such that I can capture the stream being written to debug any further bugs.

I was ready to make the changes, but had to find where I stored my FPGA boards in order to load the logic onto it. I spent a bit of time putting in the changes to help with testing tomorrow. We should have a good session tomorrow at Marc's home, collecting data to get my cartridge writing logic working properly.


I launched the PCB design software and began to tediously build the panel that supports the 16 lights each for the six registers (IAR, SAR, SDR, AFR, ACC and EXT). This board will have 96 thyristors, 96 resistors, 96 single pins for the signal inputs, 96 double pin headers for the lamp attachments, and 3 turret terminals to provide power, ground and lamp test voltages, capable of delivering 1A on AC and ground turrets when all lamps are lit.

The design begins with a schematic to define all the connections, which I built up first by drawing a single register of 16 circuits and then replicating that six times across the sheet. When I transfer this to the PCB for layout, I will have hundreds of parts to find and place in the correct location.

If I left the sequentially assigned part numbers, such as JP3 for an input pin or D34 for a thyratron, the layout would be extremely tedious and error prone. I took the time (considerable mind numbing time) to rename all the parts with a logical structure that instantly identifies which light position they implement. Thus, S103 is the input signal for register 1, bit 3. T311 is the thyristor for register 3, bit 11. R200 is the resistor for register 2, bit 0. and O415 is the 2 pin header for the lamp for register 4, bit 15.

With this, I can find and drag the parts to their desired locale on the PCB. The only parts with strict locations are the output (2 pin) headers for the lamp mounting. The power headers and the various signal pin headers just need approximate siting - signals near their thyristors and the power turret terminal in the right edge zone.

This first PCB, for the six registers, will be 8 1/2" wide and 4 1/4" high. The right hand 1/2" is the zone for the six double-pin power connections. The lamps are separated 1/2" center to center running left to right within a register, and the register rows are separated 3/4" center to center from top to bottom. The board has a 1/4" margin on three sides and 3/4" on the power connector edge.

The remaining lights in the pedestal will be covered by two identical but smaller boards, each hosting an array of six rows of eight lamps each. Some lamp positions are not implemented, depending upon the signals being displayed and the arrangement of the faceplate.

Image result for ibm 1130 pedestal
Faceplate - registers on left half, status at mid right and other data on right
One board handles the mid-right section that has the T and X clock states and various status lamps, while the other board on the far right covers the op code, registers, interrupt levels, and so forth. One design will produce both of the smaller boards, with the board sparsely populated to fit its role.

The schematic relabeling of the register board took many hours to complete, before I could lay out the physical board and place components. I wasn't done with the relabeling until the evening. Therefore, I am just beginning on the layout.

However, I found that spacing will be much tighter than I expected, because the spacing between lights is just 1/2" horizontally and 3/4" vertically. The SCR is more than 1/4" by 7/16" which fills a lot of the space between adjacent lights in the grid. The resistors and signal pins are easy to fit, but the SCR is the dominant factor.

I tried out a different organization to see if I can get the parts to fit in the tight grid. I rotated the 2 pin header from horizontal to vertical orientation. This allowed the thyristors to fit between the columns of lights and my 0805 sized resistor and signal pin will fit as well. I had to lay out an entire row across the top and the entire left column to ensure that everything fits.

The only unknown is routing. The path from the resistor and input pin is very direct to the thyristor, as is the path from thyristor anode to output pin. Further, the ground and AC voltage lines are on the inner planes of the four layer board, saving the need to route those lines. The only line that will be significant for routing is the lamp test signal.

It will take me another day to finish laying out all the components across the board before I can attempt the routing. 

Tuesday, May 23, 2017

Adjustments made to disk tool

Maker Faire took place these last few days and I was busy volunteering as an examiner for amateur radio license testing, for attendees who wished to get or upgrade their ham radio licenses. Since the FCC requires a ham license to transmit video from a drone, in addition to the usual reasons people become hams, we were fairly busy. I worked the first shift every day. 


While at the ham testing booth at Maker Faire waiting for the show to open to the public each morning, I did some work on the disk tool to clear up the synchronization issues when writing images to disk cartridges. Of course, this requires testing to validate but this looks promising.

I also tweaked the reading logic to be independent of recorded clock pulses from the disk drive once the checksum of each record is read and tested. The Alto switches from the disk drive clock line to its internal clock at this point, just as it uses the internal clock to count off the preamble time before it looks for the sync word beginning each record.

Thursday, May 18, 2017

Mostly testing and data collection tasks on the Alto


I stopped by the workshop in Marc's basement and did some testing with my logic. I discovered a problem in the way I load the shift register that serializes each word to be written to the disk drive. I am clobbering the data in the shift register before it has been written fully out, in some cases, which manifests itself when the sync word (x0001) last bit '1' does not make it onto the disk.

The challenge here are several independent processes with strong timing requirements that have to interface with my overall logic to write out a record. Another timing dependent activity is RAM access, taking multiple fpga cycles to complete, in order to fetch the next data word.

One machine is emitting clock bits every 600 ns and at the 300 ns point, midway in that cycle, it will emit either a 1 or 0 data bit. The serializer must shift out a bit to set it up for the first machine. The serializer counts down the 16 bits as they are shifted out, then emits a signal to get the next word.

My overall record-writing logic must load words when the serializer requests them, but also has to have read the data word from RAM in advance to allow it to feed the word on demand to the serializer. I issue the load request for the serializer as soon as the RAM read is complete, but that is before the prior word is fully shifted out since I have to do the reading in advance.

I am refactoring the logic again to get this cleaned up and will then have to test next week, after Maker Faire is over since many of us will be doing duty there.


In addition to the data capture I pursued, we worked on a few other tasks. I upgraded the ethernet bridge machine (on loan from LCM) with the latest code they sent. We made use of it to boot over the network and explore many functions and capabilities. The one we failed at was achieving a copydisk over the network, to read a cartridge in the real Diablo drive in the Alto and copy it to the bridge machine which is PC based.

Ken worked with his ethernet tool to check out and build up his protocol support. His code begins the network booting sequence for the Alto getting back the specific image request but is not yet able to send the entire image. He is able to connect as ftp users and ftp servers, but something is still going awry with building command lines the server will accept

Wednesday, May 17, 2017

Issues found and hopefully fixed in disktool writing, plus good day with the 1401 computers


Counting clocks and laying out the data bits into words was the key to spotting problems. Immediately, I saw a few issues in the stream I wrote. I have to work through the logic in the tool, instrument some signals to help me debug it with a logic analyzer and resolve these.

First, I see that the bits that looked correct for the header record were actually incorrect. The header record consists of the sync bit, two words of zero (32 bits of 0), and a checksum word of 0x0151, then there will be ten words of zero following it. 

The checksum on the disk is a bitwise XOR of each word with the running total, initially seeded with 0x0151. Thus, if we start with 0x0151 and XOR by 0x0000 twice, we still have 0x0151 in the running total. The checksum word on disk, 0x0151, is compared to the running total 0x0151 and we have a validation of the record integrity.

However, I found that I wrote the sync bit, only one word or 16 bits of zero, 0x0151, and a stream of zero words after. I dropped one of the two words of the header (0000 instead of 0000 0000). This coincidentally passes the checksum validation (!) thus giving the misleading symptom that my reading problems only occurred on the following label record.

To see why this still passes muster, consider the process in the microcode. After it finds the sync bit, it reads two words in and XORs them to calculate the checksum. It then reads the third word from disk and compares to the running total. Here is what happens with my abbreviated record:

  • Initial seed for checksum sets it to 0x0151
  • First word of zero is read, XOR leaves running total at 0x0151
  • Second word is 0x0151 since I omitted the true second word
  • XOR of second word with running total sets it to 0x0000
  • Third word read is really one of the zeroes that sit between records
  • Check of the third word - 0x0000 - with the running total 0x0000 yields equality
  • Checksum appears to validate integrity of the record
I have a miscount in writing out the data, omitting one of the header record words of 0x0000. That must be addressed, But wait, there is more! The gap between the header and label records should be exactly ten words of 0x0000 followed by the sync word of 0x0001 but the timing shows there are a few extra clock cycles or bits of zero in the gap. This must be addressed too,

Looking at the label record, which should be a sync bit, eight words of the label data, a checksum for the record and another gap filling set of ten words of zero, I find that the first data word is correct but the second is not right. Therefore, the problems are not simply a failure to write all N words of a record, but are worse. 

My logic is fetching words from RAM to fill a shift register, shifting the bits out serially to output each word of a record. Either I didn't fetch the second and ensuing words properly or there is some other failure in coordination between shifting, reading, loading and managing the record. 

The first word of each record comes out right, which makes the results on disk superficially appear correct. It is only when carefully counting more than 5000 clock cycles and laying out the words they represent that the problems are clearly visible. 

I think I fixed several of the problems through a refactoring of the write field logic in the disktool, but I also set up key signals to be monitored on the four PMOD connectors on the fpga board. I can hook these to the logic analyzer and debug more deeply, if what I see on the scope doesn't match what should be written.


I rebuilt four more of the power sequencing SMS cards today, replacing three resistors with two of different values and one transistor from type 26 to type 30. They were all tested in the Connecticut machine and performed perfectly. We now have both machines with two new cards in the sequencing gate, plus two spares placed into our inventory.

We seem to have a problem on one of the 026 keypunches which were converted from selenium rectifiers to modern silicon diodes. We think that at least one of the six diodes is malfunctioning, although the full wave bridge is working fine. More diagnosis needed to find and replace the pesky critter.

A new volunteer, Nora, is working on organizing all the parts in the workroom. It will be a delight to have everything well labeled and easily accessible. The challenge in front of her is formidable, as we have many boxes or bags that contain a huge jumble of components.

Imaging a few hundred assorted transistors in a plastic baggy, then multiply that by many such collections. Finding a part of a given type, such as the type 30 transistors I needed, is a painstaking process thumbing through everything. When Nora is done, we will have these sorted, separated and labeled.

One of the 1401 systems forgot how to stop today. A program would be started but none of the Stop buttons on the CPU or peripherals would cause it to stop the execution. Bill traced it to a failed Stop Latch and replaced the card. I will diagnose and repair the card itself next week and put it back into spares. 

Saturday, May 13, 2017

IBM 1130 panel schematic, Alto restoration progress


I decided to attach the circuit drawing for the replacement lamp driver circuit I am building, noting its similarity to the original IBM circuits although superior from a mounting and service standpoint.

Lamp driver circuit - lamp test switch shown at bottom

IBM 1130 circuit by comparison


Still not booting from the cartridge after I write it. Did read of the sector and captured on a scope. Now for extremely tedious counting and measurements to see what/if I did something wrong.

I centered the scope on some key pulses, such as the one bit that comprises a sync word, to get precise timings relative to the sector start, then other sets of pulses were interpolated from the grid marks on the scope face so that I can determine the timing with reasonable precision.

The clock pulses are in a train on the other trace below the data bits, one every 600 ns in a sector that 3,333 us long. That is a LOT of clock pulses and for long strings of zero words I have to count them. Each word is 16 bits therefore 16 clock pulses per word. For example, the separation between records in a sector is 10 words of zero plus a sync word with a single bit on. That is 176 clock pulses that have to be carefully counted.

Then, in the data words of a record, I have to carefully count clock pulses to divide out the data bits into words, before checking them against the file contents I tried to write to the cartridge. Checking 326 words in a sector involves accounting for 5, 216 clock pulses.

I spent the day Saturday capturing and recording the timings of the 1 bits, but was only beginning the checking of clock pulses to align them into words by the end of the day.


Yesterday we made progress on several fronts and dug into diagnostic information on others. The Digibarn machine was further cleaned and examined. The monitor that came with it is built for a Dorado, a later machine. It has a 6502 microprocessor on a board inside that multiplexes the monitor, keyboard and mouse signals over a bus using seven differential pairs with fast ECL drivers. That is very different from the connectors used with the Alto. Fortunately, we can intercept the signals from a connector inside the monitor and wire up our own cable adapter.

The capacitors to replace inside the power supplies have not yet arrived, so we didn't make any progress on that part of the Digibarn machine. Al Kossow warned us of a tantalum capacitor that often fails in the supplies, which we will also check before finishing the restoration of the supplies.

Ken's network tool passed several milestones, successfully handling echo protocols, telnet connections and ftp connections. The ftp protocol is different from the more commonly known protocol that comes with TCP/IP systems, but has similar goals. The client connects to the server properly, and command strings are mainly recieved and parsed properly, but the unit is not yet executing those commands.

With a bit of tweaking, we had the LCM ethernet bridge operational, which will be important to link together groups of Altos as we more are made operational. We did some network booting and communications, but didn't explore the file server or other utility functions.