Thomas J:
possible to detect whether two devices are simultaneously jumpered as device 0 or 1.
Detectable?
Often? Yes. Reliably? No.
I'm told a virtue of SATA is that it is jumper-free, the same virtue PCI gave us over ISA. Meanwhile, back in PATA:
By definition PATA writes & resets are broadcast, reads are multiplexed. The multiplexing works only under ideal conditions: when both devices claim to own different ID's and then also the one host and both devices agree over the value of the x1F6 DeviceHead & x10 DEV bit.
If first we arrange for two devices to share an ID, then both devices try to respond when DEV = ID. When they disagree over what bit should be read, then the host sees whichever bit was driven more strongly. Indeed, the result may not be consistent, if in combination at the specified sample time the two devices drive a middling or changing voltage, rather than a plain hi or lo.
The results may also not be random: people make not-random choices of driving circuitry. (Anybody here informed enough to \walk us thru those implications? (I'm not.))
In case of an ATA and ATAPI unit, issuing a command EC and getting the status 0x59 does the trick.
Yes we get that result when the ATAPI device drives x01 and the ATA device drives x58 and the host and both device circuitry involved favours hi bits such that the host actually samples x59.
Not reliable in theory, as above, though practice I haven't surveyed.
But what if two ATA/ATAPI units are used. I know the ID data checksum (if supported) will probably fail
True.
but that can be caused by other reasons as well. but that can be caused by other reasons as well. but that can be caused by other reasons as well.
True. (: As you can see, for you I have said that again and again and again. :)
I have been playing with the thought to count the asserted IRQs but when both devices fire their interrupts almost simultaneously I assume I'll detect only one.
Yes. The second IRQ will be invisible unless you get the first acked. And acking the first could kill the second so you never see it.
This lead two the following question ...
How does the service interrupt handle this?
Typically, it doesn't handle it. What Software doesn't handle, Marketing explains. If you don't like jumpers, buy SATA.
Assuming device 1 asserts the interrupt line exactly at the same time device 0 asserts it.
Here you say "exactly". Above you said "almost simultaneously". I liked that better. I guess here you mean both within the small window of time that appears simultaneous to the host under test.
Does device 1 sample the interrupt line to check whether it's already asserted?
Probably not. By spec the device only has to drive that pin and never sample it, therefore obsessively overoptimising, umm, whoops I mean to say brilliantly economical silicon designers tend to design that pin to drive only, not sample, so device firmware rarely has the option of sampling.
Fun idea, all the same.
What would you like the device to do if it discovers someone else is driving that pin lo?
I imagine by design today's devices ignore that input. If I host wishes to tie that pin lo, that's its privilege, the rest of the protocol still works fine, arguably by spec.
If so, what if two devices want to assert their service interrupts at exactly the same time? (somewhat like a network collision)
Our (t13) English pretends this doesn't happen.
Somehow, magically, the world should prevent two devices from ever having the same ID.
When two devices do share an ID, the result looks like an undetected network collision. The host unknowingly samples the wrong bits. In the worst case, this means miscompare (i.e. reading something other than what was written), since PATA has no parity/ CRC/ etc. except for UDMA data, not counting the stunningly weak optional byte sum of op xEC/ A1 Identify.
Pat LaVarre
