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. 

Wednesday, May 10, 2017

Finished up the upgrade of 026 keypunches, 1401 power sequencing, and built Digicomp I replica


I finished up the work changing out selenium rectifier stacks for silicon diodes in the remaining two 026 keypunches. It was a somewhat tedious job but done by lunchtime.

I managed to find another IBM 030 transistor and heatsink, which I put into my modified power sequence card for the 1401. This version of the circuit, discovered in the main 1401 ALDs but not matching the cards installed in the systems, runs much cooler. 

The original cards, used to validate a power supply voltage and activate relays in the powerup sequence, had pretty low resistor values biasing the transistor, one end of the divider tied to a 30V reference voltage and the other tied to the power supply being validated. It burned almost 4W in the divider, all the time, with the two resistors sitting flat on the card with no airflow around them.

The result is scorched card material, sizzling hot resistors and periodic failures of the cards. The alternative schematic I found replaces a 600 - 56 divider with a 3000 - 220 divider and puts in a different transistor number with a small heatsink. The circuit runs about 25 times cooler.

Now we have both of the two sequencer cards in the German 1401 converted. As soon as Glen, our wizard finding parts in the workshop, returns and finds me two more, I will convert the two cards for our other 1401. 


When I was young, in the 1950s and early 1960s, the only 'computer' access available to virtually any youth were machines designed to teach computing principles but built with mechanical, switch and light bulb and perhaps a few relays on the high end options.

Geniac (sometimes called Brainiac), consisted of a large perfboard with six large round perfboard dials, where the holes would be filled with screws and nuts, so that the round dial's screws contacted the screws on the main perfboard underneath. One wired between the various screws to implement logical functions, ultimately illuminating one or a few small flashlight bulbs to indicate the answer. 


Digicomp I was a plastic kit with three "flip flops", where a lever was turned to implement logical functions. It was programmed by placing cylindrical plugs on the flip flop edges, then when the lever moved the boards, some vertical wire rods were pushed and in turn shoved sliders left and right. The outcome was read through a slot on the left, consisting of the three binary digits that were the current flipflop state.

The Minivac 601 had eight pushbuttons, eight relays, eight slide switches, and eight light bulbs, which could be wired up to implement very simple logic functions. In addition, it had a rotary dial powered by a motor, which acted as a rotary switch. You could program it to run the motor and stop when the dial reached the answer position, thereby energizing or dropping one of the relays. 
Minivac 601.jpg
As you can see, these were incredibly simplistic virtually toys. Unless you were one in a million and had some access to an actual computer, this was all you could get as a 'personal computer' in those days. The Minivac 601 was designed by Claude Shannon, had some cachet, but was also inordinately expensive for a youth, as its price was the equivalent of over $675 today. 

I had a Geniac and a Digicomp I, plus I knew a well off schoolmate who had a Minivac 601 that I could look at longingly on occasion. My Digicomp, being rickety plastic, fell apart long ago and was just a memory, but I discovered someone selling a reproduction kit, using cardboard and foamboard rather than plastic.

I just assembled my Digicomp I replica and spent a bit of time 'toying' with it. Three flip flops and a limited number of ways to make them interact - pretty limited but it can count modulo 8 and do some very simple tricks. 

My high school had a 1620 computer but the conditions for attending the related class didn't work out for me, so it wasn't until a couple of years later than I had a chance to get hands-on time with an IBM 1130.

Not just keypunch decks of Assembler or Fortran to have run in a batch, like most users, but if I was willing to show up at 2AM when the batch processing was complete, I could work by myself for the rest of the night. Hand stepping code and quick turnaround of coding errors helped me appreciate computers to a sufficient depth that I changed the trajectory of my life and moved into the computer field, rather than working on space programs. 

Tuesday, May 9, 2017

Digging into remaining Alto disk mysteries, prototype successful for IBM 1130 pedestal panel light enhancement


I have two unresolved questions concerning the Alto disk behavior:

  1. 1) There is a delay at the start of the sector that appears as a long wait in the logic analyzer trace but I don't know what causes this.
  2. When the Alto does an update, it reads at least the header record before switching to write mode to write the data (and optionally label) record(s), but I don't see how it retains the 10 word gap that exists with pure write or pure read. 

I am studying microcode and thinking about this, hoping to resolve #2. I can deal with issue #1, if I can't understand its cause, either by writing without the padding if an Alto still reads it, or by injecting an arbitrary padding myself.

The flow of the microcode is to loop through four times in the lifecycle of a sector. First is a quick initialization pass. The next three are for the header, label and data records respectively. Most of the flow is the same, but there is a conditional branching construct based on the record number being processed that picks up the unique values related to the record being processed.

The other important conditional branching constructs are RWC and WR. The first changes the path depending on whether the operation for this record is a read, check or write. The second changes path depending on whether a read or write line operation is active.

The microcode sets up a countdown loop, called a preamble, at the front of each record. It is 29 words long when writing zeroes in front of the header record and 18 words long of ignoring input for reading that same record. The preamble for the label and data records is 4 words of zero when writing and 5 words to ignore when reading. The postamble of all three record types is six words when writing and four words when reading.

Thus, we write all three records in a sector with 29 zero words, the sync word, the header record, six postamble zero words, four preamble zero words, the sync word, the label record, six postamble words, four preamble words, the data record and six postamble zero words.

When we read that record, we skip over 18 words, then start reading but waiting until we see the sync word. That would be in roughly 11 more word times. We read the header record and read four of the postamble words but don't look at them. The next record begins by skipping over five words worth of time then reading while looking for the sync word, which takes one word of zeroes before we see it.

This all works because the reading process involves 9 words in total across preamble and postamble, while we wrote 10 during the write operation. That means we skip over one more word of zeros before seeing the sync word.

Reading the microcode for an update operation shows timings that don't make sense. The header record is always read, so skip 18, look for sync, read the record, and read but ignore the next four zero words as a postamble. Now, however, when we switch to the label record which will be written, the logic will write out four words of zero as a preamble. It then writes a sync word and the label record itself.

The inconsistency is that the gap between the end of the header record we just read and the label record we write has eight words of zero before the sync word, not ten like occurs with a pure write of all three records. Yet, the reading logic will consume nine words before it looks for sync. This means it will gobble up the sync word as the last of the nine words, thus failing to sync up.

It doesn't make sense that only eight words will be between the records after an update but ten otherwise. I have to ascribe this to something subtle I don't understand in my interpretation of the microcode and its likely execution path.

To handle issue #1, I dedicated slide switch 3 to add an 82 us delay at the start of a written sector when the switch is on, otherwise we write the 29 preamble words immediately. I can experiment with the effect of adding this, to see whether the Alto can boot or read packs that I have written in either case.

As I prepare for a testing session on Friday, I expect that I will be able to write a cartridge that can be booted and read by the real Alto. Whether this requires the mystery padding words or not, this will allow the tool to both read and write cartridges properly. The ability to update just the label or label plus data records is still untested and in great doubt.


I looked closer at the SCR modules used by IBM and found that they do NOT have isolation diodes as I would have expected. Instead, IBM places a 6.2K resistor in line with every system signal input to the modules and has a 6.8K resistor internally to the module in line with the lamp test input.

My prototype circuit will involve a series resistor to limit current into the SCR module, which hopefully will work safely with the existing 6.2K inline resistors since it will be infeasible to replace them. I could augment them if I need more resistance, however.

I could play around with an alternative that uses a diode to isolate the lamp test input, driving the entire panel worth of SCRs with a single 6.8K resistor (or whatever value the SCR needs) fed through those diodes.

My testbed consisted of a 6.3VAC AC power source (not quite the 7.5V of the IBM system but good enough as a proof of concept), a variable DC source set to 3V to mimic an SLT output level, and some point to point wiring across the scr, resistor and other components as I tested it. I also tack soldered the lamp onto the module.

The circuit worked great. Bulb bright, with the actual AC voltage measuring a tad over 7V so even better than expected. I studied the IBM lamp test and lighting circuit wiring more closely and discovered that the resistors will work just fine, avoiding the need for diodes. The trigger voltage was dropped to near 1V and still turned the lamp on brightly.

The way the IBM circuit is wired, the SCR gate is tied to a voltage divider of a 6.2K ohm resistor up to the system signal line and a 6.8K resistor to the lamp test line. Lamp test is held at ground unless the switch is momentarily activated, at which point it is connected to +3V.

The input from the system logic will be either up near +3V if logically on or down near 0V if logically off. The resistor divider network will take that signal down to ground through 13K of resistance, drawing less than a milliwatt of power and less than 1/4 milliamp of current. The midpoint of the divider presents a bit more than 1.5V, which works just fine to switch on the SCR.

If the lamp test is connected, the +3V on the lamp test line is either divided by the near 0V from the system logic line or up at +3 if both are active, in either case firing the SCR. There is no issue with having multiple system logic lines connected through 13K to ground as this is a normal load for an SLT circuit.

This saves me a bunch of money, as I only need a 6.8K resistor and an SCR for each bulb and I will have a completely suitable lamp driver for the 1130. The signal lines connect in directly to the gate of the SCR, the cathode is at ground, the 6.8K resistor runs between the gate and the lamp test line, and the anode of the SCR runs through the light bulb to the 7.5 VAC that swings above and below ground.

I have to plan for 155 lamp circuits - 96 for the six major registers plus another 51 status signals and 8 CE lines that can be wired to monitor any 8 logic levels in the system. With some extras as a buffer, hat comes to about $100 in SCRs, perhaps another $100 for the circuit board and miscellaneous components such as resistors and headers.

A project that is well worthwhile given the headaches it saves. I placed the order for the SCRs and resistors today and will begin designing the circuit boards soon.

Monday, May 8, 2017

Introduced important fix to the Alto Disk Tool, began prototyping for 1130 panel upgrade and worked on CHM modifications


I reengineered the tool to add the extra delays I am seeing in packs that boot properly. Initially, the tool will write zero words equal to about 82 us of delay before it starts the 28 preamble words of zero. In between records, the tool will insert two extra words of zero.

The microcode uses constants for the delay words between records, but the actual execution takes one more loop than the value in each constant. Thus, if a constant of 4 is described, the microcode does this task five times. It was easy to overlook this when interpreting the microcode listing, but the logic analyzer makes it clear.

I don't think the initial delay is critical, as the Alto did read the header record of the sector correctly before stumbling on the label and data records. However, the extra two words between records is essential. The way an Alto moves between records ensures that it has already passed the sync word I wrote before it starts scanning for it, thus guaranteeing a misread.


I received my sample SCR and diode devices, allowing me to build a prototype to test driving indicator lamps with a 7.5 VAC supply and logic signals conforming to IBM Solid Logic Technology specs on both the signal and lamp test inputs. If this works well enough, I can design the circuit board to implement all the light positions in the 1130 pedestal box.


I worked with Bill Newman who was applying an upgrade to four of the 026 keypunch machines, replacing the original selenium rectifiers with modern silicon diodes. We are doing this to avoid the noxious and slightly toxic fumes that Selenium rectifiers emit when they fail, as a safety measure.

We completed two of the four machines completely, meaning replacing the bridge rectifier as well as six separate selenium stacks used as diodes. Two other machines had their bridge rectifiers replaced, but we didn't have enough single diodes to replace the stacks with six diodes apiece. We will complete those on Wednesday.

I brought in a supply of 220 ohm 2W resistors to refill the empty drawer in our workroom and to complete the modified power sequencing SMS card for the 1401 systems. The original cards that sit in the machine have a pair of resistors that get extremely hot in operation, scorching the actual card underneath.

A 1401 power sequencing schematic shows an alternate set of components that run much cooler. I changed the card to match. This involved three new resistor values to drop the bias current, reducing the power dissipated from 3+ watts down to fractions of a watt, in conjunction with a changed transistor type.

We placed the modified card in the machine and verified that it successfully sequences power up and down. Next, I will build another such card since the 1401 uses a pair of them. The next card was all but complete, except for the IBM type 030 transistor, which I couldn't find in our stocks.