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
>> interface is programmed to operate in 8-bit mode. I would expect that if
>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
>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
I think the idea was that IOCS16 was to notify byte oriented logic to handle
the 16bit transfer (ISA-8).


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

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:41 BST