16 Apr
2000
16 Apr
'00
5:18 a.m.
Recently, as part of my effort on an S-100 "hard-card" using a 2-1/2 inch ide
drive, I've been revisiting the 1994 standard for the ATA interface. There's a
not-too-detailed mention of an 8-bit mode which is set up using a bit in register. This
feature was apparently obsoleted as of 1996's standard.
Have any of you folks had contact with this feature as part of one or more of the
standards? I know the original version of IDE as implemented on Compaq drives was 8-bits
wide. However, once the ATA approach to HD interfacing became popular the 16-bit version
won out.
Has anyone on this list dealt directly (not through the BIOS) with 8-bit IDE drives of
2-1/2" size? ... Any size at all?
Dick
16 Apr
16 Apr
7:21 a.m.
On Sun, Apr 16, 2000 at 08:18:51AM -0600, Richard Erlacher wrote:
Has anyone on this list dealt directly (not through
the BIOS) with 8-bit
IDE drives of 2-1/2" size? ... Any size at all?
No, I haven't heard of any 8-bit IDE models since the very ancient Seagate
ST___X drives. But I gotta ask, why even bother looking for them, when
using a 16-bit IDE drive on an 8-bit bus is *SO* easy? Two 373s, a 244,
a 245, and a PAL for the selects (plus a flip-flop if you want to be cute
and have the even and odd bytes go through the same I/O port address).
And then you can use any old drive, no need to get addicted to rare models.
John Wilson
D Bit
2:04 p.m.
Frankly, the reason I'm exploring this is because with the 8-bit mode, I
don't have to buffer the data at all beyond the on-board data-in and data
out buffers at the bus interface. The board I'm using to host the thing is
one equipped with buffers on the low-order address, data in, and data out.
It also produces a suitable select, read, and write strobe. If I were
willing to add any components at all, which would be the case if I had to
use the 16-bit interface I'd certainly not fiddle with the TTL MSI. I'd be
inclined to use a CPLD since they can drive the cable.
From what I read in the standard, this is a normally
selectable operating
mode for the interface. What's more, only the smallest of
drives would be
appropriate for CP/M on the S-100, since CP/M supports, at most, 120 MB, and
that only at the expense of having any FDD's. I've got floppy drives that
handle that much. Back when I used CP/M every day, I owned the largest hard
disk system on CP/M that I'd ever seen, at 44MB.
I bought a 15 GB drive this afternoon that cost only $99. The small
notebook drives should cost about $5-10, which is acceptable. Clearly,
lower capacity drives, less common, of course, would probably cost about
that much as well.
Dick
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: calassic computer mailing_list <classiccmp(a)classiccmp.org>
Sent: Sunday, April 16, 2000 10:21 AM
Subject: Re: 8-bit IDE
On Sun, Apr 16, 2000 at 08:18:51AM -0600, Richard
Erlacher wrote:
models.
Has anyone on this list dealt directly (not
through the BIOS) with 8-bit
IDE drives of 2-1/2" size? ... Any size at all?
No, I haven't heard of any 8-bit IDE models since the very ancient Seagate
ST___X drives. But I gotta ask, why even bother looking for them, when
using a 16-bit IDE drive on an 8-bit bus is *SO* easy? Two 373s, a 244,
a 245, and a PAL for the selects (plus a flip-flop if you want to be cute
and have the even and odd bytes go through the same I/O port address).
And then you can use any old drive, no need to get addicted to rare
John Wilson
D Bit
4:12 p.m.
On Sun, Apr 16, 2000 at 05:04:18PM -0600, Richard Erlacher wrote:
If I were
willing to add any components at all, which would be the case if I had to
use the 16-bit interface I'd certainly not fiddle with the TTL MSI. I'd be
inclined to use a CPLD since they can drive the cable.
Well you do what you gotta do. IMHO this job is just too easy to waste a
CPLD on it, I felt a bit funny about even using a PAL for the decode but
I was just building one board so I would have spent more time wiring than
I spent burning PALs. Anyway the loose parts will cost less than the CPLD
and they're less likely to get discontinued in a year. If you're tight for
space you can use the SOIC versions...
John Wilson
D Bit
8:43 p.m.
The reason for using CPLD's rather than the TTL MSI parts is that the CPLD's
drive harder and better (symmetrical outputs) and don't require changing the
wiring when the logic has to be fiddled with. The board, of course, has the
0.10" wirewrap matrix, so a package that will fit on that will be a
requirement. I figure a SMALL CPLD, e.g. EP 1800 will fill the bill.
However, I hope to get by using the 8-bit channel if that's for real. There
are some small (68-pin) CPLD's that cost about what the TTL would cost, i.e.
about $9, including the socket. SO packages are out of the question since
I'm not making a new PCB, but rather using unpopulated boards that already
exist. At present it looks like I can use the resident buffers and logic to
decode space for a SCSI (NCR53C80) a WD100x-series board, and this 8-bit IDE
would get all its signals from the same place as the WD100x channel, since
they're very similar. All this for swapping an 'LS682 comparator with a
GAL16V8.
Dick
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 16, 2000 7:12 PM
Subject: Re: 8-bit IDE
for
On Sun, Apr 16, 2000 at 05:04:18PM -0600, Richard
Erlacher wrote:
> If I were
> willing to add any components at all, which would be the case if I had
to
> use the 16-bit interface I'd certainly not
fiddle with the TTL MSI. I'd
be
inclined to
use a CPLD since they can drive the cable.
Well you do what you gotta do. IMHO this job is just too easy to waste a
CPLD on it, I felt a bit funny about even using a PAL for the decode but
I was just building one board so I would have spent more time wiring than
I spent burning PALs. Anyway the loose parts will cost less than the CPLD
and they're less likely to get discontinued in a year. If you're tight
space you can use the SOIC versions...
John Wilson
D Bit
18 Apr
18 Apr
9:44 a.m.
"Richard Erlacher" <edick(a)idcomm.com> wrote:
Frankly, the reason I'm exploring this is because
with the 8-bit mode, I
don't have to buffer the data at all beyond the on-board data-in and data
out buffers at the bus interface.
However, it doesn't matter if 8-bit IDE was standardized (at one time,
but not any more), if there aren't any available disk drives that do it.
It seems much more worthwhile to add the extra latch, buffer, and logic
to make 16-bit IDE work, since then you can use readily available
drives.
This reminds me a little bit of the story of the main memory for the
IBM 704 and 705 computers, as given in the book _IBM's Early Computers_
(regrettably out of print). IBM had previously shipped the 701 and 702
computers using electrostatic (Williams tube) memory, but it was found to
be unreliable, so IBM was in the process of replacing it all with new
core memory.
Meanwhile, the product teams for the replacement computers, the 704 and 705,
decided to use electrostatic storage rather than core because it was cheaper.
The decision was overruled by Tom Watson Jr., who said something to the
effect that choosing something that didn't work because it was cheaper than
something that did was the damndest business decision he'd ever heard of.
Of course, if IBM was structured into separate profit centers for new
computer sales vs. repair, you can see why the managers for new computer
sales would make that decision. Pacific Bell does the same sort of stupid
stuff. Installers will routinely steal working and in-use pairs from one
customer for new service for another. It makes their statistics look good,
and repair service is stuck with fixing the original service, which isn't
the installer's problem.
Eric
12:16 p.m.
You're correct all right, Eric, but I'm not interested in making ANY IDE
drive work. I'm interested in the ones too small to bring even $10 at the
flea market, i.e. the ones that are 10x what I need but only cost $6 or so.
I'm not headed for production, and I'm not getting paid, so I want it to be
simple to build. I can hunt a little for the appropriately optioned drives,
if they exist in the form factor I need.
It takes more than a latch, by the way, since you have to latch and hold the
low byte on writes, and the high byte on reads, in order not to screw up the
order of the bytes. Consequently, you need not only the two latches, but a
bit of logic to effect the byte steering on reads and to perform the write
after the CPU does the write, since the only time you can guarantee data
valid is at the very end of the write strobe.
The reason I'm whoring after the few drives with this feature included is
that when this feature was available, if at all, the popular drives were of
about the "right" capacity for the typical application of CP/M.
Dick
----- Original Message -----
From: Eric Smith <eric(a)brouhaha.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, April 18, 2000 12:44 PM
Subject: Re: 8-bit IDE
705,
"Richard Erlacher" <edick(a)idcomm.com>
wrote:
> Frankly, the reason I'm exploring this is because with the 8-bit mode, I
> don't have to buffer the data at all beyond the on-board data-in and
data
out buffers at
the bus interface.
However, it doesn't matter if 8-bit IDE was standardized (at one time,
but not any more), if there aren't any available disk drives that do it.
It seems much more worthwhile to add the extra latch, buffer, and logic
to make 16-bit IDE work, since then you can use readily available
drives.
This reminds me a little bit of the story of the main memory for the
IBM 704 and 705 computers, as given in the book _IBM's Early Computers_
(regrettably out of print). IBM had previously shipped the 701 and 702
computers using electrostatic (Williams tube) memory, but it was found to
be unreliable, so IBM was in the process of replacing it all with new
core memory.
Meanwhile, the product teams for the replacement computers, the 704 and decided to use electrostatic storage rather than core
because it was
cheaper.
The decision was overruled by Tom Watson Jr., who said
something to the
effect that choosing something that didn't work because it was cheaper
than
something that did was the damndest business decision
he'd ever heard of.
Of course, if IBM was structured into separate profit centers for new
computer sales vs. repair, you can see why the managers for new computer
sales would make that decision. Pacific Bell does the same sort of stupid
stuff. Installers will routinely steal working and in-use pairs from one
customer for new service for another. It makes their statistics look
good,
and repair service is stuck with fixing the original
service, which isn't
the installer's problem.
Eric
16 Apr
16 Apr
9:05 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1295 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000416/cc6095e4/at…
2:19 p.m.
Those "special" drives are not what I meant to ask about. I want to know
more about the 8-bit mode described in the ATA Interface Specification as
published in 1994 and 1996. This is apparently a "standard" feature.
It appears that there's a control bit in one of the control registers that
allows the interface, which defaults to 16-bit mode, to be configured for
8-bit data width.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 16, 2000 12:05 PM
Subject: Re: 8-bit IDE
> Recently, as part of my effort on an S-100
"hard-card" using a 2-1/2 =
> inch ide drive, I've been revisiting the 1994 standard for the ATA =
> interface. There's a not-too-detailed mention of an 8-bit mode which is
=
set up using a
bit in register. This feature was apparently obsoleted =
as of 1996's standard. =20
I remember _special_ 8 bit IDE drives. The model numbers usually had an
'X' (for XT, I guess) in them, and they were used with special 8-bit
controller cards in PC/XT systems. I have no idea how compatible the rest
of the interface was with the PC/AT IDE drives. These drives are almost
impossible to find now, at least in any quantity.
It's actually not that hard to use a normal 16 bit IDE drive in an 8 bit
system (like an S100 card). You need a few buffers/latches to convert
between 8 and 16 bits on read/write, that's about it.
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.
-tony
17 Apr
17 Apr
5:23 a.m.
> Recently, as part of my effort on an S-100
"hard-card" using a 2-1/2
> inch ide drive, I've been revisiting the 1994 standard for the ATA
> interface. There's a not-too-detailed mention of an 8-bit mode which is
> set up using a bit in register. This feature was apparently obsoleted
> as of 1996's standard.
It's actually not that hard to use a normal 16 bit
IDE drive in an 8 bit
system (like an S100 card). You need a few buffers/latches to convert
between 8 and 16 bits on read/write, that's about it.
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 ?
Gruss
H.
--
VCF Europa am 29./30. April 2000 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
5:39 a.m.
While I appreciate all the suggestions I've been getting, what I'm after is
an answer to the question I've put forth. The 8-bit interface feature is
written in the purported ANSI standard for ATA interfacing, yet nobody seems
to have experience with it. I was hopeful that someone would know about
this.
No, I'm not interested in the older "pre-standard" 8-bit standard which was
referred to in the proposed v.1 standard in the following remark from the
standards committee meeting notes prior to the release of the initial
standard.
"I recommend that Section 6.2.5 be replaced with the following:
The data register is either 8-bits or 16-bits depending on the
interface width currently selected and/or the type of data
being transferred by the current command. This register is
used only by PIO data transfer commands."
it goes on in reference to another feature-related command . . .
"8.22. SEEK
TYPE - Manadatory.
PROTOCOL - Non-data.
INPUTS - The Cylinder High, Cylinder Low, head portion of the
Device/Head register and the Sector Number register contain the
logical sector number in CHS or LBA mode to which the device
should move the read/write heads.
OUTPUTS - Same as the input registers.
PREREQUISITES - None.
DESCRIPTION - This command initiates a seek operation to the
physical cylinder and head that contains the target logcial
sector. If the device supports the indication of seek in
progress and seek complete by clearing and setting the DSC bit in
the Status register, then the device shall set DSC=0 when the
seek operation is started and shall not set DSC=1 until the seek
operation has completed. The device may clear BSY and generate
an interrupt before the seek is completed.
Devices that implement power management may not perform the seek
operation if the current power state is Idle or Standby.
If another command is issued to the device while BSY=0 but DSC=1,
the device sets BSY=1, waits for the seek to complete, and then
begins execution of the command.
ERRORS - ID Not Found and Command Abort.
8.23. SET FEATURES
TYPE - Optional.
#############################################################
#
#Hale's note: Oh, come on now, we all know that Set Features
#really isn't optional any more!
#
#############################################################
PROTOCOL - Non-data.
INPUTS - The Feature register contains a subcommand code as
described in table 14. Some subcommands use other registers,
such as the Sector Count register to pass additional information
to the device.
OUTPUTS - See the subcommand descriptions.
PREREQUISITES - None.
DESCRIPTION - This command is used by the host to establish the
following parameters which affect the execution of certain device
features as shown in table 14.
+=====+=============================================================+
| 01h | Enable 8-bit data transfers (see 6.2.5) |
| 02h | Enable write cache * |
| 03h | Set transfer mode based on value in Sector Count register |
| 33h | Disable retry * |
| 44h | Length of vendor specific bytes on READ LONG/WRITE LONG cmds|
| 54h | Set cache segments to Sector Count register value * |
| 55h | Disable read look-ahead feature |
| 66h | Disable reverting to power on defaults (see 8.23) |
| 77h | Disable ECC * |
| 81h | Disable 8-bit data transfers (see 6.2.5) |
| 82h | Disable write cache * |
| 88h | Enable ECC * |
| 99h | Enable retries * |
| AAh | Enable read look-ahead feature |
| ABh | Set maximum prefetch using Sector Count register value * |
| BBh | 4 bytes of vendor specific byts on READ LONG/WRITE LONG cmds|
| CCh | Enable reverting to power on defaults (see 8.23) |
|-----+-------------------------------------------------------------|
| | *These feature definitions are vendor specific |
+=====+=============================================================+
Table 14 - Set Features register Definitions
All values not contained in Table 14 are reserved for future
definition.
At power on, or after a hardware reset, the default mode is the
same as that represented by values greater than 80h. A setting
of 66h allows settings of greater than 80h which may have been
modified since power on to remain at the same setting after a
software reset.
A host can choose the transfer mechanism by Set Transfer Mode and
specifying a value in the Sector Count register. The upper 5
bits define the type of transfer and the low order 3 bits encode
the mode value.
PIO Default Transfer Mode 00000 000
PIO Default Transfer Mode, Disable IORDY 00000 001
PIO Flow Control Transfer Mode x 00001 nnn
Single Word DMA Mode x 00010 nnn
Multiword DMA Mode x 00100 nnn
Reserved 01000 nnn
where "nnn" is a valid mode number for the associated transfer
type.
(Editor's note: It is intended that the reserved values be used
for future specification of an alternative flow control
mechanism.)
If a device supports this specification, and receives a SET
FEATURES command with a Set Transfer Mode parameter and a Sector
Count register value of "00000 000", it shall set its default PIO
transfer mode. If the value is "00000 001" and the device
supports disabling of IORDY, then the device shall set its
default PIO transfer mode and disable IORDY.
See vendor specification for the default mode of the commands
which are vendor specific.
Devices reporting support for Multi Word DMA Transfer Mode 1 must
also support Multi Word DMA Transfer Mode 0.
Support of IORDY is mandatory when PIO Mode 3 is the current mode
of operation.
ERRORS - If the device does not support the command or if any
input value is is not supported or is invalid, the device posts
an Aborted Command error."
and is referred to in the meeting notes prior to release of the 1996
standard in the context of being discontinued.
In the 1994 standard, which is the main one I've been studying, the 8-bit
mode is handled as just another feature.
Clearly this is a standard feature, but I'm not comfortable that it was
actually implemented as a standard.
Any light that could be shed on this matter in specific terms, would be
helpful.
Dick
----- Original Message -----
From: Hans Franke <Hans.Franke(a)mch20.sbs.de>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 7:24 AM
Subject: Re: 8-bit IDE
as
> > Recently, as part of my effort on an S-100
"hard-card" using a 2-1/2
> > inch ide drive, I've been revisiting the 1994 standard for the ATA
> > interface. There's a not-too-detailed mention of an 8-bit mode which
is
> set up
using a bit in register. This feature was apparently obsoleted
> as of 1996's standard.
It's actually not that hard to use a normal
16 bit IDE drive in an 8 bit
system (like an S100 card). You need a few buffers/latches to convert
between 8 and 16 bits on read/write, that's about it.
> 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 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 ?
Gruss
H.
--
VCF Europa am 29./30. April 2000 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe 
7:33 a.m.
an answer to the question I've put forth. The
8-bit interface feature is
written in the purported ANSI standard for ATA interfacing, yet nobody seems
to have experience with it. I was hopeful that someone would know about
this.
Very simply. I tried that and it's bogus! It does not work. Therefor
expereince with it is limited to trying to make it work.
It may be proposed and would be nice but it's a no-op as far as I can test
it.
features as shown in table 14.
+=====+=============================================================+
| 01h | Enable 8-bit data transfers (see 6.2.5) |
Allison
8:10 a.m.
I didn't follow this too closely but there were a couple of 8-bit IDE
interface boards in terms of "ISA 8 bit" vs "ISA 16 bit". JDR used to
sell
one as an "upgrade" option for the XT and its ilk. However, it was only IDE
(no EIDE) and generally some BIOSes couldn't boot from it (it had BIOS boot
roms but not all systems (I think Leading Edge were a big problem here)
actually used them.)
Now as far as talking to a drive across the 40 pin cable in "8 bit mode",
that I've no clue on.
--Chuck
At 12:33 PM 4/17/00 -0400, you wrote:
an answer to
the question I've put forth. The 8-bit interface feature is
written in the purported ANSI standard for ATA interfacing, yet nobody seems
to have experience with it. I was hopeful that someone would know about
this.
Very simply. I tried that and it's bogus! It does not work. Therefor
expereince with it is limited to trying to make it work.
It may be proposed and would be nice but it's a no-op as far as I can test
it.
features as shown in table 14.
+=====+=============================================================+
| 01h | Enable 8-bit data transfers (see 6.2.5) |
Allison
8:38 a.m.
I've gotten little information from the drive makers so far, regarding how
extensively this feature was pursued in the drives. The intefaces certainly
existed, and, if you built an 8-bit interface on the ISA, the motherboard
hardware would steer the bytes correctly for you so the software essentially
was the same, though it talked in 16-bit mode to the drive channel. The
assertion that the standard provides for an 8-bit mode is not in dispute.
From where I sit, one should be able to condition the
interface during setup
to function in 8-bit mode and then, when the data channel is
accessed, the
interface should NOT assert the IOCS- signal when accessed. I've yet to try
this, but it seems reasonable. I'll probably get to it later in the week.
It's tax week, after all.
Dick
----- Original Message -----
From: Chuck McManis <cmcmanis(a)mcmanis.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 11:10 AM
Subject: Re: 8-bit IDE
I didn't follow this too closely but there were a
couple of 8-bit IDE
interface boards in terms of "ISA 8 bit" vs "ISA 16 bit". JDR used to
sell
one as an "upgrade" option for the XT and its ilk. However, it was only
IDE
(no EIDE) and generally some BIOSes couldn't boot
from it (it had BIOS
boot
roms but not all systems (I think Leading Edge were a
big problem here)
actually used them.)
Now as far as talking to a drive across the 40 pin cable in "8 bit mode",
that I've no clue on.
--Chuck
At 12:33 PM 4/17/00 -0400, you wrote:
>> an answer to the question I've put forth. The 8-bit interface feature
is
>> written in the purported ANSI standard for
ATA interfacing, yet nobody
seems
>> to have experience with it. I was hopeful
that someone would know
about
>> this.
>
>Very simply. I tried that and it's bogus! It does not work. Therefor
>expereince with it is limited to trying to make it work.
>
>It may be proposed and would be nice but it's a no-op as far as I can
test
it.
features as shown in table 14.
+=====+=============================================================+
| 01h | Enable 8-bit data transfers (see 6.2.5) |
Allison
8:26 a.m.
Do you mean you checked the standard and subsequently fiddled with the
software so it set the mode to 8-bit? That's part of what I wanted to
establish.
Dick
----- Original Message -----
From: <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 10:33 AM
Subject: Re: 8-bit IDE
> an answer to the question I've put forth.
The 8-bit interface feature
is
> written in the purported ANSI standard for ATA
interfacing, yet nobody
seems
to have
experience with it. I was hopeful that someone would know about
this.
Very simply. I tried that and it's bogus! It does not work. Therefor
expereince with it is limited to trying to make it work.
It may be proposed and would be nice but it's a no-op as far as I can test
it.
features as shown in table 14.
+=====+=============================================================+
| 01h | Enable 8-bit data transfers (see 6.2.5) |
Allison
9:10 a.m.
On Mon, 17 Apr 2000, Richard Erlacher wrote:
Do you mean you checked the standard and subsequently
fiddled with the
software so it set the mode to 8-bit? That's part of what I wanted to
establish.
How would I know the 8bit mode where there otherwise? the books
(standard) said it was there, didn't work as advertized. I suspected
it was optional.
Allison
9:33 a.m.
----- Original Message -----
From: <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 12:10 PM
Subject: Re: 8-bit IDE
On Mon, 17 Apr 2000, Richard Erlacher wrote:
It was optional after the 1996 standard became the norm. I'm just not
certain any mfg actually put it in his drives after '91. I would like to
avoid having to check each drive individually, but if I do, I'll just put a
"fixture" in one of my S-100 boxes and run a test there.
There's physical room for a SCSI, WD100x-05, and an 8-bit IDE on the 12 x 40
hole wirewrap layout on the card I'm using. IF I can find two or three
drives that work in 8-bit mode, that will be enough. They want to be thin
2-1/2" drives, though, else they'll stick too far out from the board.
Do you mean you checked the standard and
subsequently fiddled with the
software so it set the mode to 8-bit? That's part of what I wanted to
establish.
How would I know the 8-bit mode was there otherwise? the books
(standard) said it was there, didn't work as advertized. I suspected
it was optional.
10:56 a.m.
On Mon, Apr 17, 2000 at 12:33:04PM -0600, Richard Erlacher wrote:
There's physical room for a SCSI, WD100x-05, and
an 8-bit IDE on the 12 x 40
hole wirewrap layout on the card I'm using. IF I can find two or three
drives that work in 8-bit mode, that will be enough. They want to be thin
2-1/2" drives, though, else they'll stick too far out from the board.
Just stating the obvious: the 2.5" 44-pin connector uses a 2mm metric
grid, so if your WW area uses a regular 2.54mm grid it'll need some drilling.
John Wilson
D Bit
12:20 p.m.
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com
To: <classiccmp(a)classiccmp.org
Sent: Monday, April 17, 2000 1:56 PM
Subject: Re: 8-bit IDE
drilling.
Yes, it surely is the obvious. I have a couple
of adapters from standard
40-conductor IDE cable + Power to 2.5" standard 44-conductor 2mm connector.
I shortened it from about 3" length with two IDE cables to about 1/2" with a
single IDE cable such that it can fit directly into one of the two wirewrap
areas. Coincidentally, the cable connector points downward, thereby
allowing the adapter to be soldered into the wirewrap area with the pins
protruding onto the wiring side of the board. This enables me to attach
power directly to the adapter and attach signals there as well. This also
permits me to install a normal cable adapter in the other wirewrap area,
which is close to the top of the board, thereby giving me a place for the
standard IDE cable so it can be brought to where the drive sits. This then
is wired in parallel with the adapter's 40-conductor connector, thereby
producing the signals to the 44-pin 2.5"disk drive connector. That then
requires NO DRILLING. (I hate drilling!) If I decide to build a 16-bit IDE
interface channel, I'll build it on a proper wirewrap board rather than
trying to use this bare board.
Dick
> John Wilson
> D Bit
On Mon, Apr 17, 2000 at 12:33:04PM -0600, Richard
Erlacher wrote:
> There's physical room for a SCSI, WD100x-05, and an 8-bit IDE on the 12
x
40
> hole wirewrap layout on the card I'm using.
IF I can find two or three
> drives that work in 8-bit mode, that will be enough. They want to be
thin
2-1/2"
drives, though, else they'll stick too far out from the board.
Just stating the obvious: the 2.5" 44-pin connector uses a 2mm metric
grid, so if your WW area uses a regular 2.54mm grid it'll need some 
1:14 p.m.
I've seen straight IDE 40pin to 44pin adaptors
(the power leads being separated out)
So using a standard header an 40pins flatcable to te adaptor
might solve that problem.
I had them with a 2.5" to 3.5" slidemount but the adaptor
was kinda removable. I don't think i still have it but they
do exist out there.
Sipke
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 9:56 PM
Subject: Re: 8-bit IDE
On Mon, Apr 17, 2000 at 12:33:04PM -0600, Richard
Erlacher wrote:
There's physical room for a SCSI, WD100x-05,
and an 8-bit IDE on the 12 x 40
hole wirewrap layout on the card I'm using. IF I can find two or three
drives that work in 8-bit mode, that will be enough. They want to be thin
2-1/2" drives, though, else they'll stick too far out from the board.
Just stating the obvious: the 2.5" 44-pin connector uses a 2mm metric
grid, so if your WW area uses a regular 2.54mm grid it'll need some drilling.
John Wilson
D Bit
11:32 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 935 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000417/ff179b3f/at…
2:18 p.m.
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(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 2:32 PM
Subject: Re: 8-bit IDE
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
[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 ?
2:33 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3282 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000418/d0e254bd/at…
4:13 p.m.
You're right in both of the points you raise, Tony, but I'm not interested
so much in verifying that standards are often ignored as I am in making the
interface work in a very specific way if it is at all possible. The
difference between the way in which the WD100x-05 boards worked, for
example, as compared/contrasted with the WD1003-WAH, is quite minimal.
Likewise, the difference between the WD1003-WAH and the IDE is quite
minimal. The only REAL difference between the IDE and the 100x-05 in its
operating mode (in general terms) is quite minimal as well. That's only
true if the IDE will, as the standard states, work in 8-bit mode.
8-bit).
now.
From the standpoint of my S-100 application, the
difference between the two
40-conductor cable interfaces is a little more crucial.
If the IDE can be
muscled into its purported 8-bit mode, it is strictly software. The board I
want to use has an address comparator, a low-byte address buffer/latch, and
a latch (373) for the DATA OUT bus and one for the DATA IN bus, though it's
used strictly as a buffer, i.e. the gate is tied high. The Data OUT bus is
always enabled, but latched at the end of the OUT strobe developed on the
board so it remains stabile until the next local OUT. If I have to
propagate data in words, it still takes two bytes, but because of the nature
of the available adequate latches, I have to provide a sequencer to write
the data to the IDE after, not during, the OUT cycle. This has to enable
both output bytes on an OUT. It has to snag both bytes in the other
direction, and then has to sequence the enables to the two bytes in the
appropriate order AFTER the write from the IDE is complete. This, again, is
because of the nature of the best suited registers, i.e. '646's, which,
sadly. don't seem to come in a latched version. They are edge triggered,
hence you don't dare look at the data until the entire transaction on the
IDE side is over. I had the notion that the '652 or one of the other
members of that family would be a transparent latch, but apparently not . .
. <sigh>.
Doing all that is pretty simple, but it would be so much simpler in 8-bit
mode, where the card-local bidirectional data bus can serve with no latches
or buffers at all.
What that accomplishes is it makes the interface more general. For the IDE
or for the WD100x-05, I need only a connector, as all the required signals
are available on the card already. For SCSI, using either an NCR 5380 or a
WD 33C93, either of which will fit easily on the available 12x20 wirewrap
area at the top of the board. For the case in which I want to attach a
notebook drive to the board I need simply attach the fraction of a notebook
drive adapter to the IDE channel, and that's done. The only cut-n-paste I
have to do is to replace the address comparator with a GAL16V8A or faster,
and we're on our way. If I have to build the word-wide interface and the
support logic, it takes more cuts and wires, and requires a second GAL. For
that reason, I'd prefer a 68-pin CPLD and then leave the TTL component sites
vacant, using only their pads for connection points.
I find the latter approach somewhat uglier in view of the age of the S-100
and the age of these boards I want to use.
Making an S-100 interface, even making a relatively sophisitcated one, is
actually quite simple. What I would prefer is to use the TTL for which
sites are provided on the board already and make it work with hardware from
the period when the system was designed. The fact that the board is using a
disk drive fully twenty years younger is excusible only because it's to be
use mainly as a develpment tool.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 5:33 PM
Subject: Re: 8-bit IDE
>
> 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
This, IMHO, depends on what you're trying to do.
If you're trying to get a drive to work in 8-bit mode as an interlectual
exercise, fine. You'll learn something about the IDE interface, and how
PC parts rarely adhere to published standards.
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.
> data transfer mode for the data port (the other ports are already > 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.
My guess is that most drives do _NOT_ implement this bit, at least not
One thing I've learnt over the years is that a lot of 'PC hardware' will
work in a PC when used with the standard OSes and programs but it as sure
as heck doesn't meet any published specs. I've had printer port cards
that don't use open-collector drivers on the control lines (even though
IBM specified that somewhere). I've had floppy drives that don't
implement any parts of the SA400-like interface other than those needed
for the PC (some of them don't even have drive select jumpers). Keyboards
that don't implement all the modes that IBM described in the TechRef.
Floppy controller chips that won't do single density properly. Etc, Etc,
Etc
> You seem to have a good grasp of what some of the IDE signals do. I'd
be
Well, I had to modify the IDE card in this PC....
> 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.
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/
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.
mode.
initialize that interface in a 16-bit-capable
interface, I'll see the
IOCS16- go away. Unfortunately, the vast majority of the old TTL
Well, for an 8-bit interface, IOCS16/ doens't have much meaning...
> 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).
-tony
4:22 p.m.
I don't know a hoot about this, but I wonder if taking a look at the
Sequential Systems Focus card for the Apple II might be instuctive. Its a
controller and notebook IDE drive that all fits on a Apple II slot card.
5:43 p.m.
Fact is, any idiot with a databook and a standard can devise a suitable
interface in a half a day. This thing's really simple. There's never been
any question about HOW to make a physical interface that works. The
question is (again)
"Has anyone got sufficient experience with the IDE in non-PC-compatible
applications to say, unequivocally, whether the 8-bit operating mode
described in section 6 of the standard for the ATA (IDE) interface, yes
SPELLED OUT, actually exists in drives of the pre-1996 vintage?" It was
dropped from the standard in 1996. There seem to be many folks with
suggestions about how to implement this extremely elementary interface.
There seem to be few who know whether the standard was every full
implemented.
Allison seems to be the only one who's tried this, and, I fear, it may be in
a PC-compatible, where all bets are off as to what really happens.
Dick
----- Original Message -----
From: Mike Ford <mikeford(a)socal.rr.com>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 17, 2000 7:22 PM
Subject: Re: 8-bit IDE
I don't know a hoot about this, but I wonder if
taking a look at the
Sequential Systems Focus card for the Apple II might be instuctive. Its a
controller and notebook IDE drive that all fits on a Apple II slot card.
8862
days inactive
8864
days old
25 comments
9 participants
participants (9)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
cmcmanis＠mcmanis.com -
edick＠idcomm.com -
eric＠brouhaha.com -
Hans.Franke＠mch20.sbs.de -
mikeford＠socal.rr.com -
sipke＠wxs.nl -
wilson＠dbit.dbit.com