Built PLL, integrating it into the driver logic; PCBs shipped

ALTO DISK TOOL

Today, my driver boards are on their way, That would put the boards in my hand sometime on the 20th. The emulator board also shipped, but that will arrive midweek, a bit after the driver boards.

Monday night, at a dinner meeting with a number of technology enthusiasts that began life decades ago as the Motorola 6800 computer club, we discussed the data separation issues and a number of potential solutions. PLL is the consensus approach. .

I ran a few reads of sectors with repeatable errors and looked at the digital and analog results carefully to draw some conclusions if possible. Slow going. Knowing exactly what fails and why is important to devising a solution, otherwise I am just using brute force enhancements in the hope I hit the target.

I set up a phase locked loop and am doing some experimenting to see how well it does at data separation as a possible replacement for the one built into the Diablo drive. Tedious work to set up various jittery input patterns and read the simulator output to judge its response. Bashed through the day working on it.

Once I had the PLL doing a decent job syncing to the clock bits, I had to modify it to produce a fixed duration pulse of 100 ns, as the PLL produces 50% duty cycle outputs. Once that is done, I need to sort out the separator logic and the startup state which routes the first transition as a clock. This will be tricky.

Waiting on PCBs, refining retry logic while reading cartridges

ALTO DISK TOOL

Final components are on hand, now watching PCB move through the foundries. The driver PCB is currently being plated, presumably the next steps are creating the sandwich of layers and QA inspection before shipping. They estimate shipping by December 15th, with three day shipping in place, which means the boards likely arrive early next week.

Driver boards in process, arrive early next week

The single emulator board is assigned to a large panel to be manufactured. Once the entire 4 layer panel is built and cut apart to the separate boards, mine can be checked and shipped. This board will likely arrive late next week.

Digilent had an online sale, where I picked up both extension boards and FX2 connectors at a very attractive rate. These will allow me to build out all the boards I expect to make in the coming weeks.

Extension boards

FX2 connector to use in lieu of extension board

I tweaked the ReadEntireCartridge transaction to let me control the number of retries when a checksum error is detected. I can have none, 31 or 62 based on fpga board switch settings. I will run some experiments - seeing the number of error sectors with no retry, then assess the results of 31 or 62.

This afternoon, I ran those tests and see that very few are corrected by retry. Performing a single read across the entire cartridge resulted in 123 sectors with a checksum validation error. Whether retry was done for 31 or 62 times, we had 119 bad sectors. That is, only four sectors had temporary errors that were resolved by rereading. The bad sectors are extremely consistent from run to run, as well.

It is time to study failing sectors in more detail, to discover where the fault happens and the characteristics. If there is a pattern that I can detect and if a more intelligent data separator would avoid the fault, then I will build it.

To do separation, I must first OR together ReadClock and ReadData to give me the original combined pulse stream. That is simple to accomplish. Separating, depending on the full list of errors I find, might be a bit challenging but perfect extraction is the goal. 

Working on the drive and fpga to further improve reading accuracy

ALTO DISK TOOL

I bought some 9601 timer chips, the same as used in the Diablo board, in order to experiment with the timing and appropriate component values. The 'long' timer might be running a hair short, hard to say for sure based only on the logic analyzer traces. I tried to set up the scope to get a more precise value.

Using the scope and some calculations, I worked out some fine tuning to get the timers closer to the ideal timing for the Alto, reworked the board and validated the timings afterwards. Resistances increased to make the times a bit longer.

With that change in place, I did another ReadEntireCartridge transaction and uploaded the resulting image and checksum status files for processing. Immediately I saw that I had very long stretches where no errors at all occurred.

I did the postprocessing and analysis on my laptop, running the Python programs I derived from Ken's work, and looked at the success rate of reading this cartridge with the improved board. I am seeing differences in 4% of the sectors and 2.1% of the total words, statistically about the same as before, but actually a lot fewer sectors had errors.

The only checksum validation errors were on cylinders 5-15, 26 and 44, just 12 out of 203 cylinders on the cartridge. with the errors concentrated so that about half the sectors on each cylinder had errors.

I am going to tweak my ReadEntireCartridge logic to support additional retries and make it more robust. At this point, it is possible that there is some corruption on the cartridge on those low cylinders, because I have an exact match between the bitsaver archive image of the cartridge and the contents I read, other than on those 12 low cylinders.

The errors occur sporadically across the cylinders, not bunched together. If it were surface defects or deterioration of the media, I would expect to have errors on all records of the sector and several consecutive sectors, not the pattern I see; there are errors only on the data record and they are well distributed across each head and cylinder.

If I can get the errors down to essentially zero, I will be satisfied. Until then, I want to continue researching and honing the system.

Still investigating the read error cases, plus working on the new PCBs

ALTO DISK TOOL

I am still pondering the best way to handle the data separation for the Diablo drive. Yesterday I was looking at using a phase locked loop, but am now considering other means as alternatives. The point I am set on is the need to reverse the disk drive's separation and then accomplish this myself in the fpga.

Data Separator circuit inside Diablo drive

The circuit above accomplishes data separation from the signal coming off the disk surface. In other circuitry, not shown here, the flux reversals detected by the disk head are converted into a positive going pulse of fixed duration, somewhere between 50 and 100 ns in duration. Thus, each reversal delivers on pulse to the circuitry above.

We will discuss its behavior proceeding from a point in time just before the arrival of a pulse that represents a clock. The routing flip-flop in the center is initially reset, thus the incoming pulse is routed to the lower right gates to become a ReadClock pulse.

The pulse that is sent as ReadClock will also serve as the clock to the routing flip-flop, which has its D input tied high so when the clock pulse arrives, the flip-flop sets to on. This will continue forever until the timer circuits to the left side switch off, this causing the routing flip-flop to again reset so that new pulses again go out on the ReadClock line.

However, while the routing flip-flop is set and has not yet been reset by the timer expiration, any pulse coming from the heads is routed out the upper gates as ReadData. Thus, from the arrival of a clock pulse until some time duration has elapsed, subsquent pulses are routed as data, but after the time elapses they again are processed as clock pulses.

The timer circuits on the left consist of two different timers, both are started by a ReadClock pulse, but lasting a short or a long duration. Which of the two timers is used depends on the leftmost flipflop, which is set to on when a ReadData pulse is delivered, but reset when the next ReadClock pulse arrives.

Thus, the default state once the ReadClock pulse arrives is that this is a zero bit, enabling the long timer to be used. This enables the long timer chip to produce a negative going output pulse for the duration of its time, kicked off when ReadClock line goes on.

However, when a data pulse arrives during the time interval, it sets the logic to instead use the short timer chip whose negative going output pulse occurs earlier after the clock. This occurs by setting the 'one bit' flipflop on the left. It is not reset until the next clock pulse ends, thus the timer started is based on the prior value at clock rising edge, before the falling edge resets this flipflop.

Our routing flipflop in the center is switched off by either of the timer chips emitting the negative going pulse when it times out, as well as when a ReadData pulse is emitted. It stops looking once it finds a 1 bit transition pulse, or when the timers run out.

When two transitions are close to each other, they seem to be shifted in time relative to each other, compared to the actual flux reversal written onto the media. Thus, this bit shift or pulse shift phenomenon is compensated for by the left side circuitry, If a 1 bit was detected, the routing resets earlier to look for a clock pulse.  

The fault I am seeing is the arrival of the subsequent clock pulse early enough that it is routed as a data bit, not a clock bit. This is a fault of a timer that is too long. It happens sporadically and rarely, but causes a checksum validation error since the clock pulse is lost and the deserialization becomes confused.

If the timers are shortened further, there is the risk that a data pulse will appear as a spurious clock pulse, the inverse error to the one I saw. Since Xerox chose to operate the Diablo disk drives outside of their spec, which intends for a 660 ns bit cell time, timing becomes more critical.

Our big enemy is jitter - not just the pulse shifting that is inherent with magnetic reading, but jitter from other sources. The result is that the arrival timing of clock and data pulses is shifting about often, thus solutions such as fixed timing or a PLL are not perfect.

The rotation rate of the disk can vary as much as 1% per specifications, which in practice means that arrival times can be offset by up to 2% in the worst case where the writing drive is 1% off in one sense and the reading drive varies by 1% in the opposite sense. This can give us a jitter from 0 to 12 ns.

The oscillator used to write the disk is an imperfect circuit, thus its nominal rate of 3.33 Mhz can deviate a bit leading to jitter in the pulse timing of a similar amount. This might be as much as 30 ns jitter, although the rate of change is low so the impact won't affect single bit cells.

The clock rate recorded on the surface is totally determined by the writing system, in this case an Alto which wrote to the cartridge many years ago. Variations of the clock frequency are locked into the recorded signal. The receiving system (my fpga) uses the recorded clock not its own, thus it can't contribute any significant jitter.

Still, we have a drive engineered for a 660 ns bit cell operating at 600 ns with jitter than can run to about 45 ns if the worst case of clock rate and drive speed variations were to occur. This gives us a bit cell that could be 555 ns at worst case. Since each pulse produced, for clock or data is 50 to 150 ns in width, we have a window of approximately 405 to 495 to look for the data pulse.

The data separator in the Diablo uses 440 or 460 ns for long or short, which should just squeak by in the worst case. That worst case is a compressed 555 ns bit cell, with the prior cell containing a data value of 1 so that pulse shifting occurs.

Looking at the pulses separated during the anomalous period, I see a set of ReadClock pulses 600 ns apart, then the next clock pulse follows in just 300 ns. The following pulse, 600 ns later, is routed as a ReadData. 600 ns after that and every 600 following we see ReadClock pulses.

The odd issue with that sequence is that a pulse arriving 300 ns after the last clock would be a data pulse, but if it were then the clock following it is missing because the gap is again 600 ns. Something has interrupted the pulse train, chopping 300 ns out of it. I don't understand how this happened.

BUILDING DRIVER AND AND EMULATOR PCBs

I received most of the components on hand that will be used to build the driver and emulator boards, once the PCBs come in. The remaining components arrive on Monday, whereas the PCBs will take another week or so to show up.

I do have to prepare the cable for the emulator role, inserting the 40 pin connector on the cable half that runs to the Alto driver board. This has the metal ground plane bonded to the cable, just as the disk side of the cable had, and must be carefully peeled back in order to install the connector.

Contemplating replacing Diablo data separator circuit with fpga based phase locked loop

ALTO DISK TOOL

I developed a watchdog timer in the fpga that will emit a signal if the time between clock pulses is 700ns or longer - this will help me flag spots where the Diablo drive is misidentifying a 0 bit with late clock as a 1 bit and missing clock. I can then reliably trigger both logic analyzer and oscilloscope to see the behavior of interest.

Data is recorded on the disk with a non-return-to-zero encoding (also called frequency modulation which evolved to MFM for the first PC disks), where bit cells of 600 ns are written by reversing the magnetic flux once or twice. At the beginning of each bit cell, the flux is always flipped, which is the clock. In the middle of the cell, if the bit in question is to be a 1, another flux transition occurs, whereas a 0 bit value does not cause a reversal.

This is why disk records start with a long string of zero bits, to help the reading circuitry to synchronize on the clock bit as the start of a bit cell. The clock bits are the only transitions when the data values are all zero.

The start of meaningful data is signalled by a special non-zero pattern, which for the Diablo is a single bit cell with a data value of 1. The reading circuits pass through the flux reversal as a clock pulse and then flip the logic for less than 500 ns so that any reversal in that interval will be passed as a data bit value. This window of time where a flux reversal is a data bit is how the circuit separates clock from data pulses.

I have found spots on the disk where a record gets a checksum error, at least on some read attempts, because the clock pulse is misreported as a data pulse. Specifically, the bit cell is meant to contain a value of 0, so that the flux reversals are the clock at the start and end. In this case, the next reversal which is intended to be the clock is passed along as a data value of 1, because the timer window is still open. The clock pulse arrived a bit early.

Now, when the clock pulse following a 0 value bit cell is misrouted as a 1 data value, and the next bit cell is also a data value of 0, then we will have a longer than usual gap until the next flux reversal. The two 0 bit cells are collapsed together as a single 1 bit.

Out of the data separator circuit, we see the clock pulses skip a beat, with 1200 ns between pulses at this point. The data pulse is also wrong and more sinisterly, the serial train of data bits is compressed with two lost 0 bits reported as only a single 1 bit. This misaligns all the remaining data bits and checksum for the remainder of the record.

It is possible that I could detect and correct for this error, but it would be complex. I would need to establish the bit rate, adjust to stay synchronized with the clock transitions and then look for malformations. One such would be a skipped clock pulse coupled with a 1 data value. I could morph that into a pair of clock pulses representing the two data bits of 0.

I would need to look carefully at all the possible cases - 0 bit cell where this happens followed by a 1 bit cell, as well as other cases where clock and data are misrouted by the data separator circuitry. In essence, I will combine these to produce the flux transitions and separate them myself using more sophistication than a simple timing window.

I can also imagine errors where the pulse is split between data and clock, when the timing window elapses somewhere in the middle of a flux reversal pulse. If I combine the ReadClock and ReadData signals myself to form the original pulse train before the separator does its task, I can bypass the source of these errors and accomplish the detection of bit values correctly.

I need a second order digital phase locked loop to recover the clock properly, then use that to indicate bit cell boundaries and watch for the data 1 pulses. The incoming signal is messy, having timing jitter due to rotational variations on both write and read passes plus bit peak shifting. It may also suffer from minor variations in the media surface and from oscillations of the head heighth.

Beginning with single density floppy disks and PC era hard drives, the written signal was 'pre-compensated' to minimize the shifting of pulses upon reading, but no such technique was used with the Diablo drives.

Floppy disk data separator chips were available but are intended to support the much lower bit rates of the original SD and DD floppy drives, 250Kbps to 500Kbps whereas the Diablo is streaming data bits are 1.67 Mbps. The phase locked loops available on the Spartan 3E fpga chips won't operate at so low a frequency, requiring minimum frequencies in the range of 10Mhz.

Thus, I have to work out a different method. Opencores has a DPLL although I am not certain how good it will be at handling disk signals.The goal is to generate a train of clock outputs that is synchronized to the time averaged clock pulses observed from the head, then use that to cleanly separate transitions that are far enough from the clock to be considered a data bit value of 1.

I will implement this in the fpga, digitally mix the ReadData and ReadClock as an input, create the scaffolding for the data separator based on this, then compare the results of this versus the Diablo separator circuit. This is going to be complex design work. 

Emulator board designed and fabbed out

ALTO DISK TOOL

Today I completed the emulator role board design and shipped it off to a different foundery, pcbunlimited.com, as they would do a quantity one order. I need to be more confident in the correctness of the board before I order more.

Multilayer view of PCB design for emulator board

The above board is 6" wide by 4" high and has an 2x20 IDC type male shrouded connector on each side. The left one is mounted on the bottom of the board and plugs downward into the female connector on the Digilent FPGA extension board seen below. The right side connector is mounted on the top and accepts the 40 signal ribbon cable that runs to the Alto computer or other system that makes use of a Diablo 31 disk drive.

Extension board, fpga plugs to left and driver/emulator board sits on top

Below is the multilayer view of the driver board, the same size as the emulator board but with different numbers of input and output circuits and connections as befits its role. It also mounts atop a Digilent extension board that will in turn plug into a Nexys3 fpga board.

Multilayer view of PCB design for driver boar

Finally, to round out the pictures, here is the Nexys3 board onto which the extension board is connected. A USB connection on the left lower side communicates with a PC in order to load and store disk images.

Nexys3 fpga board hooks to extension board

Driver board released to foundry, beginning on emulator board.

Wednesdays as always I spent most of the day at CHM, meeting with the 1401 restoration team members. 

ALTO DISK TOOL

I spent another day iterating with the online free design verification tool associated with the 4PCB foundry and with my design on DesignSpark PCB. I really cleaned up the design substantially, ensured a good silkscreen layer, but had to accept some spurious errors that reflect limitations of the checking software.

Specifically, a metal plated hole through a board is called a 'via' and links a copper trace on one layer to another trace on a different layer. Mostly, these are linking the top and bottom layers of the board, where traces run left to right on the top layer and top to bottom for the bottom layer. Thus, a signal can pass over another using the 'other' layer.

I designed this for a four-layer board, which has two internal layers in addition to the top and bottom. One of the internal layers is ground and the other is the +5V power. If a component is connected to ground or +5V, it has a larger via which is electrically connected to one of the inner layers.

The design review software spots vias when they have signals connected to them on both top and bottom, the typical usage, but if the via is connected internally, the software confuses the plated hole with a hole that a component lead will fill. If a component is attached to the hole, it has to be soldered on.

Any spot where soldering occurs must have an opening on the solder mask layer, all other parts of the circuit board to and bottom are insulated with a thick green coating. Since the software falsely thinks the power or ground via is a solder pad for a through-hole component, it is flagging to me that the solder mask is covering this pad. That would render the pad or component hole un-solderable but in this case, no solder is needed.

I placed the order for four boards, to arrive in a bit more than a week, at a net cost of just under $300 or $75 per board. I should have all the components to attach by the time the boards arrive, thus I can assemble them at that time.

It is time to begin designing the complementary board, for the disk emulator role, which will use the tried and true components and circuit elements, only connecting them in a different order to suit the disk signals going in and out of the Alto computer.