Tony, your bracketed heading says it all! I'm NOT trying to "fake" 8-bit
I/O on the IDE interface. The published standards specify a valid 8-bit
data transfer mode for the data port (the other ports are already 8-bit).
This is described rather minimally in chapter 6 wherein the registers are
defined. There's an 8-bit enable bit which, when properly conditioned, will
cause the data port interface to transfer 512 bytes as bytes rather than as
256 words. There are LOTS of ways to "fake" it, but I'm trying to determine
whether anyone has actually operated an IDE interface normally used in
16-bit mode in this obscure and, possibly, scantily supported mode.
I know bigger drives are cheap. I just bought a 15 GB DRIVE for $99
yesterday. One of my colleagues just had someone ship him a new 20GB drive
in place of a 13.2 GB drive, which is what he ordered, charging him only
$100 for the drive they shipped because they'd sold out of 13 GB drives. I
agree, these drives are cheap.
What I want is information from people who've actually read the standard and
attempted to use a normally 16-bit drive in 8-bit mode. This is not
particularly easy with the existing hardware. I'll be surprised if anyone
has built interface hardware that is actually capable of this. It's
possible, though.
You seem to have a good grasp of what some of the IDE signals do. I'd be
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
initialize that interface in a 16-bit-capable interface, I'll see the
IOCS16- go away. Unfortunately, the vast majority of the old TTL
MSI-implemented IDE channels don't have the means to operate in that mode.
They hardly have need, however.
Dick
----- Original Message -----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 17, 2000 2:32 PM
Subject: Re: 8-bit IDE
> [faking 8 bit IDE]
>
> > > Actually, although it pains me to say this, IDE drives are so cheap
per
> > > megabyte now that you could probably get away with wasting every other
> > > byte... Just use a 3-state buffer to always write the top 8 data lines
as
> > > 0 (or FF or...) and ignore them on read. After all, people give away
1Gb
> > > IDE drives these days (or so I've heard), and 500M of storage (i.e.
> > > wasting every other byte) is massive for S100 systems.
> >
> > Quite an inriguing idea. You also will get 256 Byte records ...
> > a more common size back then. Well, what about commands etc. pp ?
>
> I seem to remember that the IDE standard that I read said that the
> command/status registers were all 8 bits (and mapped to the lower 8 data
> lines). Only the data register was 16 bits, and the drive would assert
> I/OCS16 when that was accessed and at no other time. Of course I have no
> idea how modern drives handle this...
>
> -tony
>
Received on Mon Apr 17 2000 - 18:18:28 BST