• Please review our updated Terms and Rules here

Utility for MFM/IDE/ESDI/CF Drives

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
44,533
Location
Pacific Northwest, USA
It occurred to me after a couple of posts that many people with XTA (8-bit IDE) controllers aren't aware that most most CF cards support 8-bit transfers. I suspect this is because that the old XTA drives just worked in 8-bit mode by default, but CF cards and ATA2 drives need to be told to get into 8-bit mode.

So I took my 17-year old drive sniffing program and modified it to tell you if your drive will work in 8 bit mode. Find it as an attachment--run it under DOS or shutdown Windows 9X to MS-DOS mode. You can't run it on Windows NT, 2K, XP, Vista or 7--and it will tell you that. It works only on controllers on standard primary ports (32x for the XT MFM controllers and 1Fx for AT MFM, IDE and ESDI controllers). Sorry, no SCSI support.

So if IDESDI tells you that your drive (and this includes most CF drives) will work in 8 bit mode, how do you put them in that mode?

Well, you can patch your hard drive BIOS to issue the following command sequence:
Code:
 BAF101        MOV     DX,01F1
 B001          MOV     AL,01
 EE            OUT     DX,AL
 B0EF          MOV     AL,EF
 BAF701        MOV     DX,01F7
 EE            OUT     DX,AL
 BAF101        MOV     DX,01F1
 EC            IN      AL,DX

If AL comes back 00, the drive is in 8-bit mode. If AL comes back as 04, then the drive doesn't support 8-bit commands.

This should give some folks something to chew on at any rate.
 

Attachments

  • IDESDI.ZIP
    9.2 KB · Views: 15
It occurred to me after a couple of posts that many people with XTA (8-bit IDE) controllers aren't aware that most most CF cards support 8-bit transfers. I suspect this is because that the old XTA drives just worked in 8-bit mode by default, but CF cards and ATA2 drives need to be told to get into 8-bit mode.

XTA isn't the same thing as ATA with 8-bit transfers selected; the registers and command set are different.
 
Also whilst looking at something else (and very related!) I'm working on, I came across this:

In True IDE Mode, all Task File operations occur in byte mode on the low order bus D[7:0] while all data transfers are 16 bit using D[15:0]. (source: https://engineering.purdue.edu/ece477/Webs/S04-Grp07/documentation/cfspc2_0_compact_flash.pdf)

So although all CF cards do support 8-bit transfers, seemingly not in IDE mode! But I'll check some out anyway :)

On all of the CF cards that I tried, 8-bit mode followed the ATA2 spec--all data transfers were conducted over the low-order 8 bits. A lot of devices, such as digicams depend on that, I think.

Try executing the code above on a CF installed in an IDE adapter and then attempt to do a read--you'll find that the card will hang because only half the data will have be transmitted.

I suspect your cite is merely copying the ATA3 or later spec, which does say that.
 
XTA isn't the same thing as ATA with 8-bit transfers selected; the registers and command set are different.

How different, John? Can you point me at a spec for XTA? In any case, since you'll be patching for the initialization code, you could probably patch the rest fairly easily.

What I propose is a way out of the conundrum of dead XTA drives on gear where replacing the controller isn't desirable or possible.
 
Last edited:
XT-IDE

Before the 16-bit ATA/IDE interface, there was an 8-bit XT-IDE (also known as XTA) interface for hard disks, though it was not nearly as popular as ATA has become, and XT-IDE hardware is now fairly hard to find (for those vintage computer enthusiasts who may look for it). Some XT-IDE adapters were available as 8-bit ISA cards, and XTA sockets were also present on the motherboards of Amstrad's later XT clones. The XTA pinout was very similar to ATA, but only eight data lines and two address lines were used, and the physical device registers had completely different meanings. A few hard drives (such as the Seagate ST351A/X) could support either type of interface, selected with a jumper.

Long time ago I had a ST351A/X which was probably out of order and kept only its PCBs...
 
How different, John? Can you point me at a spec for XTA? In any case, since you'll be patching for the initialization code, you could probably patch the rest fairly easily.

What I propose is a way out of the conundrum of dead XTA drives on gear where replacing the controller isn't desirable or possible.

Just as the ATA registers and command set are based on the WD1003 controller in the PC/AT, the XTA registers and commands are based on the Xebec 1210 controller in the PC/XT, so I'd suggest the IBM PC technical reference, pages 1-187 to 1-201. The Interrupt List gives an outline:
Code:
----------P03200323--------------------------
PORT 0320-0323 - XT HDC 1   (Hard Disk Controller)
SeeAlso: PORT 01F0h-01F7h

0320  RW  data register
0321  -W  reset controller
0321  R-  read controller hardware status (see #P0574)
0322  R-  read DIPswitch setting on XT controller card
0322  -W  generate controller-select pulse
0323  -W  write pattern to DMA and INT mask register

Bitfields for XT hard disk controller hardware status:
Bit(s)  Description     (Table P0574)
 7-6    always 0
 5      logical unit number
 4-2    always 0
 1      error occurred
 0      always 0

Since XTA only uses two address lines rather than the three used by ATA, it's quite possible that some or all XTA machines don't connect the third one, meaning any rewritten firmware would only be able to access half the registers on an ATA device.
 
Thanks, John--I discovered the differences by disassembling a WD XTIDE ROM. Basically, XT port assignments and function. Although the connector pinouts are very similar, the A2 pin is missing on the XTA interface--it's ground instead. I suppose if an XTA controller decoded the extra address bit, or you could "borrow" it from somewhere, you might stand a chance at getting the thing to work.

Better still is to take a standard AT IDE controller and just write some BIOS ROM code for it so that a CF in 8-bit mode is handled. Since a lot of AT IDE controllers included a floppy controller, this might be a way to get high-density floppy capability along with hard disk on the same card.

Sounds like work to me.

What this does suggest is that a stripped-down CF version of the XTIDE might be possible. You could do away with the extra latches to handle the upper 8 bits on data transfers.

Again, it sounds like work...
 
I'm still working on CF too. I've very nearly completed an XT/IDE board design with both 40-pin and CF on it - will post up the design tomorrow.
 
Hi, will I be able to access my Seagate ST351a/x 45MB hdd in my Windows 7 machine with this tool? How about with Linux? Thanks. Anyway I might as well give it a try.
 
I usually try to avoid threads with the 'W' word in them, but I gotta know:
Why would you want to access a ST351 in Windows 7, *nix, or anything (modern os's) for that matter ?
It can't be for data recovery, since there's still plenty of 386 & 486 stuff out there perfectly happy with a 351 (even *nix, if you find an old enough version).
Is it just for the perverse pleasure derived from cajoling Windows 7 into doing something it doesn't really want to ?
If it really is for data recovery, just post a plea for help, I'm sure there's plenty of folk here willing to dump a 351 to file.

This isn't meant as criticism, I'm just trying to wrap my head around it all.
patscc
 
...take a standard AT IDE controller and just write some BIOS ROM code for it so that a CF in 8-bit mode is handled. Since a lot of AT IDE controllers included a floppy controller, this might be a way to get high-density floppy capability along with hard disk on the same card.

Chuck, I think we should re-visit this idea. The XTIDE Universal BIOS will have the capability to do this very soon, albeit that the dots aren't joined up yet.

What this does suggest is that a stripped-down CF version of the XTIDE might be possible. You could do away with the extra latches to handle the upper 8 bits on data transfers.

I agree. The board would have two 74521s, a dual OR gate, an inverter and a 39SF flash chip. If assemblers could be persuaded to try SOIC (which are easy with a blob of flux and wick) and the CF header (again easy since it's mechanically aligned by locating lugs) then the board should hopefully fit in 100x100mm footprint.
 
I'm game. It'd be pretty simple to do.

Maybe Hargle could chime in on this, but I wonder if most of the XTIDE kits are purcased assembled, rather than as a kit. It seems that fewer people are interested in soldering...
 
It occurred to me after a couple of posts that many people with XTA (8-bit IDE) controllers aren't aware that most most CF cards support 8-bit transfers. I suspect this is because that the old XTA drives just worked in 8-bit mode by default, but CF cards and ATA2 drives need to be told to get into 8-bit mode.

Maybe a dumb question. Does that mean, that computers that originally have built-in XTA controller, could be adapted to using CF cards just by minor change in BIOS ? Like this one for example http://www.vintage-computer.com/vcforum/showwiki.php?title=Systems:Commodore+PC10-III I actually already tried a CF card, but the computer complained ;)
 
Unfortunately not, because an address line is missing (DA2 on the CF card is ground on the XTA interface).
 
Maybe Hargle could chime in on this, but I wonder if most of the XTIDE kits are purcased assembled, rather than as a kit. It seems that fewer people are interested in soldering...
I'd say 1 out of 3 cards were assembled before shipping. I think the majority of our crowd here are up for some soldering.
 
Sorry to resurrect this after 16 years but, i have a failed IBM WDL-330P from a PS/1 2011, and was wondering... was anyone successful with this hack?
 
Back
Top