Dennis Nedry wrote:I must say that I don't fully-understand the UART theory. From what I understand of what you're saying, you think that the IWM in the Mac may encode data into IWM signals, and the IWM in the HD-20 basically decodes them back to the original signals. Is this correct?
I can see how you would cross the serial transmit and receive lines, but the control signals must either be bi-directional or not used, because they are both the same IWM chip (presumably). i.e. Normally, with a floppy drive, the Mac's IWM sends out control signals, sends out serial data, and receives serial data. I'm not aware of the Mac's IWM ever receiving control signals from a drive, maybe I'm wrong...
So... obviously I can't know for sure, but I'd be willing to bet a nice shiny nickel on the read/write lines being crossed so the two IWMs act like a pair of UARTs, yes. If you look at that page about programming the IWM (on the Apple IIGS) the IWM essentially acts just like a UART (or at least a parallel-in-serial-out shift register... it's a pretty dumb UART) so there really shouldn't be a barrier to wiring two together, and if you did that a data byte fed into one side *should* be clocked out the other...
Before continuing it's worth noting that the IWM is *the* prime example of Apple's use of clever software to compensate for a lack of discrete hardware, thus resulting in a fairly incomprehensible design despite being electrically "simple". Google for the PDF "Beneath Apple Dos" and read it. You'll see in graphic, horrid detail how the IWM (which is essentially a slightly-enhanced single-chip implementation of the Apple ][ disk controller) requires *software* to imbed the synchronization bits into the data stream bytes. (This document is mentioned in that IIgs IWM programming page.) When you're writing a disk buffer you don't just throw the data at the IWM and it writes it, automatically padding it with sync bits like a "real" disk controller does. No, you get to rewrite the data yourself, aka, "nibble-ize-ing" it, and throw those modified bytes at the controller. Also note there's no interrupts indicating when it has a valid byte/needs the next one. You loop and poll until you're done, period.
(One question that this raises is if communication to the HD-20 likewise has to be nibble-ized, or if they just throw raw bytes at each other. I suppose it has to get clocking information somehow so there's probably *some* massaging of data...)
Anyway, yes, you have a valid point about handshaking/flow control. Because of the "load-select-read" way the IWM communicates with the "smart" 400/800k drive registers there doesn't seem to be a simple way you could just raise and lower a line and have it detectable on the far end. (If it were a pair of PC-style floppy controllers perhaps you could use a status line... do something skanky like tie "motor on" to "write protect" in both directions? Here we don't have that option.) My guess is what Apple did is tie the control register lines from the Mac to an input/output port on the Z8. That would let the Mac twiddle the control lines in whatever way is necessary to get the HD-20's attention, and then the Mac would send a control byte out through the IWM's UART once the Z8 has indicated it's ready. (As indicated through a read of a "control register" in the drive similar to the floppy drive mediated by the Z8. Note that the control lines on the HD-20's IWM aren't connected to anything in this scenario.) When the HD-20 sends something back through its own IWM/UART there won't be any flow control, but... there's no flow control when a spinning disk is shoving bytes at the host computer anyway. You'd work around this by again using a twiddle of the control lines to ensure that the HD-20 doesn't send any data until the Mac indicates it's ready for it. (At which point it would start running an appropriate tightly-coded polling loop.)
Again, this is all 100% speculation. I'm just trying to think like a demented 1985 Apple engineer here.
