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.

No comments:

Post a Comment