Using the "Phi1 Echo" to distinguish disk controllers

Apple hid a quirky feature inside its disk drives: one of its head-positioning signals (Phi1) is deflected from the motor-control circuit board into the write-protect switch.  I suppose they could have generated a TTL logic-level signal some other way, but it worked and that's the circuit they adopted.  And Apple retained this eccentric wiring in their later Unidisk 5.25...which contributed to the headaches in designing the Yellowstone disk controller, as Steve wrote in a blogpost at Big Mess o' Wires: Circuit Sleuthing: Unidisk 5.25 Enable and PHI1.

As a side effect, the Disk ][ analog board is forced into write-protect mode any time Phi1 is enabled.  That doesn't interfere with writing onto a disk for two major reasons:

1. Phi1 corresponds to phase-1 of the stepper motor -- a guard band between tracks, not a recordable track
2. All stepper phases are turned off before RWTS attempts to begin recording (which includes Phi1 naturally)

But it also provides a quirky way to distinguish the original Disk ][ controller from its TTL-based clones: by accessing switches Q7 Q4 Q6 Q1 to transmit a TTL logic-transition through Phi1 and listening forthe signal to echo back through the write-protect sense.

Let's construct a monitor command to do that:

*C0EE C0E9 C0ED C0E3 I C0E2 C0E2 N

Here's an explanation of each part of that command:

• C0EE sets Q7 to low, disables accidental writing, and prints a random byte (ignore it)
• C0E9 sets Q4 to high, sends an enable-signal to the drive, and prints a random byte (ignore it)
• C0ED sets Q6 to high, enables write-protect sensing, and prints a random byte (ignore it)
• C0E3 sets Q1 to high, turns on Phi1, and prints a random byte (ignore it)
• I enables "inverse" printing to help highlight the next bytes to be printed
• C0E2 sets Q1 to low, turns off Phi1, and prints the contents of the data register (Disk II) or status register (any other controller)
• C0E2 leaves Q1 at low, leaves Phi1 unchanged, and prints updated contents of the data register or status register
• N enables "normal" printing again

Below is a screen capture of using that command with an original Apple Disk ][ controller with an empty disk drive attached.  I typed the command twice to demonstrate that it printed the same results each time: in inverse, it printed the bytes 7F followed by 00.

capture328.png

That command gives different results if used with a different disk controller that doesn't duplicate the P6 ROM state-machine of the Disk II.  For example, below is a screen capture of using that command with a Micro Sci's A2 controller, which replaces Wozniak's P6 ROM state-machine with TTL circuitry.  The A2 controller printed the bytes 80 followed by 00.

capture332.png

I didn't test the IWM controller, employed in the Apple //c, because I don't have such a machine.  But it should print another distinct pattern of bytes because it employs a status byte with an additional "drive enabled" status bit. 

So an Apple //c would probably print the bytes A0 followed by 20.  An Apple //c Plus would probably print AF followed by 2F because its mode register would be configured for a 3.5 drive by default.

Clones and derivatives that employ the same state machine as the Disk II controller should print the same results, such as Apple's later 5.25 IO Controller