8-bit IDE

From: allisonp <allisonp_at_world.std.com>
Date: Mon Apr 17 20:07:00 2000

>But if you want an IDE interface for the S100 bus that will work with
>just about any IDE drive that you throw at it, then you should only
>depend on whatever features are required for the drive to work in a
>normal PC. Because you can bet that some drive (or most drives!) won't
>implement anything else.


I'd agree from my experience. I'd add the 2.5" drive are less likely too.

>> willing to believe that the interface will not assert IOCS16- if the
drive's
>> interface is programmed to operate in 8-bit mode. I would expect that if
I
>
>The term 'interface' is ambiguous here. IOCS16/ is asserted by the drive,
>not by the bus adapter card.


True! I built the interface on the assumption it would be asserted to
save logic.

>The bus adapter simply buffers the signal (most of the time) and sends it
>to the ISA slot. In particular, note that the address decoder logic on
>the bus adapter is not what asserts IOCS16/


Correct, those assert CS lines.

>AFAIK, a standard IDE drive only asserts IOCS16/ for accesses to the data
>register. Not for accesses to any of the control/status registers. Which
>means all of those are seen as 8-bit registers.


Yep. That mas a 8<>16 adaptor simpler as it's only reads and writes to one
address that need folding.

>> MSI-implemented IDE channels don't have the means to operate in that
mode.
>
>See above. The bus adapter should do the right thing provided the drive
>asserts IOCS16/ at the right time. The TTL bus adapter cards are just a
>couple of buffers and an address decoder (normally a PAL, but it doesn't
>have to be).


Actually this is only important to obscure hardware as the software knows
a data register read/write is 16bit (word) and that all other registers are
byte.
I think the idea was that IOCS16 was to notify byte oriented logic to handle
the 16bit transfer (ISA-8).

Allison

>
>-tony
>
Received on Mon Apr 17 2000 - 20:07:00 BST