Digging into ALTO disk controller interaction with cartridges written by my disk tool

ALTO DISK TOOL

I have a working hypothesis for why cartridges I write cannot boot on the Alto, but can be read back fine by my logic. It centers on a quirk of disk heads that the erase head poles cannot be exactly coincident with the read/write head poles. Typically the erase poles are in back of the read/write gap by a short distance.

The consequence of this spacing is that, when both erase and write head currents are switched on simultaneously. there is a time of about 25 us where any writing flux transitions on the write head would be placed on media that had not had its prior contents erased. The erase poles are lagging.

Requirement to consider the 25 us delay from read/write head position to erase poles

The Diablo drive electronics also requires a minimum delay after WriteGate is turned on, energizing the read/write head, until flux transitions are written, but this is just 2 us. The Alto turns on the heads as soon as it executes a command to write, with no timing circuits to wait 2 us.

Requirement for 2 us minimum delay from WriteGate to first transition

The Diablo manual recommends that a write operation wait 25 us after the sector mark before turning on write and erase heads to write data, and also leaves the write and erase current on for 25 us AFTER the next sector mark arrives. This produces an erased and written swath that fits exactly between the sector marks.

Green circle shows lagging delay of erase head poles behind SM and read/write poles

This is not how the Alto manages the disk, however. On the Alto, every time a sector mark goes active, the disk sector task checks for a match of the cylinder, head and sector specified in an active write command. When there is a match, the disk word task is woken up and the disk sector task goes to sleep, only to awaken at the subsequent sector mark.

The disk word task sets the state for read or write, sets up the count for preamble words, and then goes to sleep. It is awoken when the write shift register has written out sixteen data bits (these are all zero values in the preamble). The preamble on the first record of the sector is 34 words, so the task is woken 34 times before it moves on to write the sync work and the rest of the sector.

Thus, we will have data written essentially immediately after the sector mark occurs, bit cells with one or two pulses depending on whether it encodes a 0 or 1 bit value. This is very different from the recommended method in the Diablo manual.

The way the Alto handles a read operation is the same as write in the disk sector task, where it just matches the address and then fires off the disk work task. The disk word task will be interrupted every time the read shift register has shifted in 16 data bits, a 'word time'.

Reading the first record of a sector involves an initial delay, where the disk word task is woken 21 times as a delay counter, not looking at the data being read, then begins looking waiting for a sync word. That will involve some number of all zero words, which are ignored, until the pattern 0000000000000001 is seen.

Alto format on disk

The error I am experiencing occurs quite early in the disk word task execution, when it is looping waiting for the 21 word times to expire. There is a status bit init or wdinit which is on during on of the first invocation of the disk word task, causing an error condition.

That line wdinit is switched on at all times when the command line wdallow is off. Once wdallow is on, the state of wdinit is reset if the word task is going to sleep, i.e. block signal is on during a word task execution.

Init state on for first pass of word disk task, then reset

My error condition is occurring while the wdinit condition is still on, but the microcode task is trying to count down word times from the disk drive. It will shift some value into the read shift register every time the ReadClock signal from the drive pulses, then after sixteen of those clock pulses the register is full raising wddone and forcing a new task execution.

74161 counts up to 16 bitclock pulses then sets WDDONE

The wakeup logic is all reset when the wdallow control signal is low. When the counter of bit clocks gets to 16, it sets wddone which toggles on the left FF. That FF changes asynchronously to the system clock, driven by disk drive ReadClock signals, so the next two FFs serialize this into the Alto clock domain, After two cycles, the wake up signal reaches the top NAND gate and awakens the disk word task.

Wakeup logic above init state FF

 The wdallow signal is set by the hardware when a microcode instruction specifies the ldcom control signal. That is generated by instructions setting a specific value in the microinstruction F bits.

LDCOM sets up WDALLOW signal

F bits select LDCOM signal

Now what I need is a listing of the assembled MU code (MU is the microcode assembler) to let me see how it uses the F bits and bus to set wdallow on and off, in relation to the start of a disk transfer.
The existing listing I have is only of the source code, which is pretty opaque.

Annotated microcode source for start of disk read in disk word task

Until I get get the generated output include microinstruction ROM addresses, to correlate this to the logic analyzer traces of the disk boot failure, it is hard to zero in more on the cause of the problem.