Malvineous wrote:

Any IDE interface can support ATAPI as it's just a way of encoding commands over the IDE bus, so you don't need a special ATAPI IDE controller, any IDE controller will work.

I really wish that this statement were true, but it's just not.

* You can't use an ATAPI ZIP drive with a FastTrak TX2000 IDE/RAID card, for instance. Ordinary IDE drives work fine, and the metadata for an array is stored on the card or cleverly on the disk somehow, because I've transferred drives between the TX2000 and other IDE controllers with no issue. (So it's not that it rejects ZIP drives because of the RAID features of the card.)
* Mentioned here: https://www.pcreview.co.uk/threads/promise-co … -aargh.1951329/

* You can't use an ATAPI ZIP drive with an XT-IDE card.
* Mentioned here: http://www.vcfed.org/forum/archive/index.php/t-52541.html

I happen to know about those 2 counter-examples because I independently discovered the miserable truth about this little corner of the vintage hardware space over the last few days. The only Sound Blaster card that I have that has an interface that IS compatible with my ATAPI[2] ZIP drives is a CT2890, but the card itself doesn't seem to work at all in either my 386DX40 system or my 486DX2/66 one. (I'm guessing this is because those systems are too old to use ANY PnPISA or quasi-PnPISA cards...)

Frustrated, I gave up and ordered a couple of Z100IDE drives. I was trying to maintain my personal standard of having color-matched ZIP 250 drives on all of my systems, but it doesn't look like Iomega ever released a Z250IDE model at all.

To be fair, many RAID cards aren't true IDE. They use a subset of the IDE protocol to talk to the host, and a subset to talk to the drive, acting as a translator in between. But they don't connect the device directly to the host bus with no translation in between, which is necessary for ATAPI to work. So the advice has always been to avoid RAID cards if you want to attach something other than hard drives (and this holds true for IDE, SCSI and SATA for the same reasons.) A recent experience on a modern server with SAS drives running Linux, required special driver tricks in order to pass SMART commands directly to the attached drives without the commands getting eaten by the RAID controller, so the advice even holds true today and for hard drives!

As far as I know, the XT-IDE card uses a rare IDE transfer mode in order to work with 8-bit systems. I guess you have a point here because technically it's part of the IDE standard, but it was rarely used back in the day so I guess some manufacturers didn't bother to implement it. On 16-bit systems and higher it should be fine however, with any ATAPI driver working with any (true/non-RAID) IDE controller. Out of curiosity, have you tried a 16-bit IDE controller in your XT, instead of the XT-IDE? Not sure if it will make any difference but perhaps if you can find a controller that talks to the drive as 16-bit but the host as 8-bit then it might work? This is well beyond my experience though so I have no idea if it's even plausible. I just remember seeing a special mode in the XTIDE BIOS for a 16-bit controller in an 8-bit system.

I have successfully gotten an ISA PnP card working in a 486 without PnP BIOS support by installing Intel's PnP manager, as well as using Creative's own PnP driver (I preferred the Intel one as it gave me more control and supported some other PnP devices in the system beyond the sound card). There's even a program someone wrote fairly recently and mentioned on this forum that allows PnP cards to work on 286 machines IIRC, so you should be able to use your Creative PnP card as an IDE interface in both your 386 and 486 systems without any trouble.

chrisNova777 wrote:

yea but i have a big stack of zip disks i wanna actually use;) seems appropriate to me.. surely someone else has done this?

I am the same - I have like 20 of those drives here. Almost each one of my machines has one too, and if not I have two LPT drives and a USB ZIP.

The driver you need is called guest.exe - I have an original IOMEGA CDROM if you want I can make an image for you.

alexanrs wrote:

ZIP drives need a driver to be loaded from CONFIG,SYS. I do not remember the specifics right now, but those drivers aren't hard to find. And yeah, just put it as a slave to the HDD.

Btw booting from ZIP drives is another beast, as it requires BIOS support and I doubt the 386 has that.

I have a ZIP 100 drive in several 386s, and a 286. BIOS doesn't need to support anything.

creepingnet wrote:

Funny anecdote, I once put an IDE HDD on a SoundBlaster AWE32 IDE port - Windows 95 actually picked it up at correct CHS/Capacity, 🤣.

This - this might be the answer I was looking for for a little project I am doing. Were you able to access your drive?

https://www.youtube.com/watch?v=Ka0T6DkBz48
Seems like with a hacked ROM, the XT-IDE can use even ZIP-250 ATAPI drives in a 8088/8086 machine 😀.

Malvineous wrote:

Makes me now wonder whether you can load drivers for an ATA ZIP drive and restore full functionality on it, in DOS mode.

This can only be done for non-bootable secondary drives, with Iomega's ASPIIDE.SYS. For configured bootable primary units, the nature of being the main system drive will not allow ASPIIDE to take on them. Them will keep as "fixed" hard disks with the disk locked on it, until the next reboot to BIOS Boot Menu.

Malvineous wrote:

To be fair, many RAID cards aren't true IDE. They use a subset of the IDE protocol to talk to the host, and a subset to talk to the drive, acting as a translator in between. But they don't connect the device directly to the host bus with no translation in between, which is necessary for ATAPI to work.

Makes perfect sense. But then why would a Z100IDE also not work with such a RAID/IDE card? The TX2000 recognizes my Z100IDE on bootup but says "NOT SUPPORT" in one of the menus.

Malvineous wrote:

So the advice has always been to avoid RAID cards if you want to attach something other than hard drives (and this holds true for IDE, SCSI and SATA for the same reasons.) A recent experience on a modern server with SAS drives running Linux, required special driver tricks in order to pass SMART commands directly to the attached drives without the commands getting eaten by the RAID controller, so the advice even holds true today and for hard drives!

Again, this makes perfect sense. The reason *I've* avoided RAID cards whenever possible, though, is because they tend to use proprietary metadata encoding schemes that interfere with other controllers / OSes / drivers / whatever recognizing the partitions. As I said before, the TX2000 must be writing its metadata about the drive arrays in its own memory somehow, because when I create a "stripe" (of 1 disk), it retains knowledge of that fact between bootups, and yet I can pop that drive into another system, on a real IDE controller, and it has no problems. Every time I've tried this with a server RAID controller, it has made it impossible to transfer the disks to other systems unless they have EXACTLY the same RAID controller as the first machine, and even then, an array rebuild is typically necessary. Kind of a digression from the ZIP Drive topic, but pertinent to this little tangent.

Malvineous wrote:

As far as I know, the XT-IDE card uses a rare IDE transfer mode in order to work with 8-bit systems. I guess you have a point here because technically it's part of the IDE standard, but it was rarely used back in the day so I guess some manufacturers didn't bother to implement it. On 16-bit systems and higher it should be fine however, with any ATAPI driver working with any (true/non-RAID) IDE controller.

I believe you, but I've had a Hell of a time trying to get any IDE controllers to work other than my atypical examples: TX2000, CT2890 IDE Interface, and my XT-IDE. It's like there's a blood pact between eBay sellers to break any true IDE controllers before they are shipped out. I've received 4; all 4 broken or otherwise not working in any of my systems.

Malvineous wrote:

Out of curiosity, have you tried a 16-bit IDE controller in your XT, instead of the XT-IDE?

You made a natural but incorrect inference. Originally I did get my XT-IDE card for my XT machine, but I've actually been using it in my 386 and 486 machines because I COULDN'T GET ANYTHING ELSE TO WORK. =) That is, until my TX2000 card came in, but that has its limitations as we've already discussed. What I really want is something that could be called the AT-IDE...same tech as the XT-IDE but expanded to a 16-bit bus with better performance. The BIOS on the XT-IDE is incredibly cool and the main reason, I think, why the card is so useful.

Malvineous wrote:

I have successfully gotten an ISA PnP card working in a 486 without PnP BIOS support by installing Intel's PnP manager, as well as using Creative's own PnP driver (I preferred the Intel one as it gave me more control and supported some other PnP devices in the system beyond the sound card). There's even a program someone wrote fairly recently and mentioned on this forum that allows PnP cards to work on 286 machines IIRC, so you should be able to use your Creative PnP card as an IDE interface in both your 386 and 486 systems without any trouble.

Ugh...now you're making me want to go back and see if I can get that CT2890 to work in that 486DX2/66 machine. I had abandoned hope for making it a multimedia/gaming rig because of the difficulties with the drives. Was planning on putting my old BBS on it and building a gaming machine out of one of two different 486 motherboards I just ordered on eBay to "replace" it. ...I think I will stick with my plan, though. It's just too painful. The underlying reason is that it's an "IBM PC Server" 8640-0N0, and it was definitely targeting server rooms / data centers with its design. It just makes a lot more sense to keep that TX2000 card in there, get a serial port to work with an external modem (or just use an internal one), and let it be a "server" running a BBS. Dial-up only, btw. I'm *that* kind of oldschool.

Nothing wrong with that kind of old school - I recently bought a new small business PABX from China so all my old computers could dial up and call each other without needing a real phone line 😀

I'm not sure why the Z100iDE wouldn't work with the RAID controller. Possibly it reports itself as a removeable device, which the controller doesn't support? That'd be odd though because hotswapping drives is kind of a big point of RAID controllers. I presume you booted the machine with a ZIP disk present? I imagine an empty drive would certainly not be supported. I take it none of your RAID cards have any options for any sort of pass-through IDE support? While not ideal sometimes this can work.

The RAID controllers I have used often write their metadata to some part of the disk. Linux software RAID writes it at the start of the device, IIRC the MegaRAID controllers write it on one of the last sectors of the drive so that it doesn't interfere with the partition table. Most of them write it somewhere on each disk so that a failed RAID controller can be swapped out with the replacement requiring no configuration.

The "AT-IDE" you want is just a normal bog standard ISA IDE controller. On those machines of mine that lack IDE support (or use the wrong CHS translation) I put the XTIDE BIOS onto a flash chip and set it up as a boot ROM on the machine's network card. It adds full bootable IDE support just fine. That's a shame all yours have arrived broken though. What exactly was wrong with them? I only ask because in my own personal experience I have never come across a failed IDE controller. All of the ones I have work, although of course those machines without BIOS support for IDE drives need the XT-IDE BIOS loaded in order to see the drives. It would be extraordinarily unfortunate to get four failed IDE controllers! Have you tried booting the machine with the controllers and then running diagnostic software to report any IDE devices found, just in case the problem is a lack of BIOS support?

Malvineous wrote:

Nothing wrong with that kind of old school - I recently bought a new small business PABX from China so all my old computers could dial up and call each other without needing a real phone line 😀

Awesome!

Malvineous wrote:

I'm not sure why the Z100iDE wouldn't work with the RAID controller. Possibly it reports itself as a removeable device, which the controller doesn't support? That'd be odd though because hotswapping drives is kind of a big point of RAID controllers.

I concur. The only thing I haven't tried yet with the Z100IDEs is to figure out the proper CHS parameters and then try to have DOS work with one of the drives directly. If the stupid things really are "IDE", that *should* work. I highly suspect it will not work. 😉

Malvineous wrote:

I presume you booted the machine with a ZIP disk present?

Of course -- I've tried it both ways.

Malvineous wrote:

I imagine an empty drive would certainly not be supported. I take it none of your RAID cards have any options for any sort of pass-through IDE support? While not ideal sometimes this can work.

I've used many, many RAID controllers over the years, and I've never seen this fabled pass-through option. In my experience, they've all insisted on creating a degenerate(meaning only 1 drive) mirror or stripe.

Malvineous wrote:

The RAID controllers I have used often write their metadata to some part of the disk. Linux software RAID writes it at the start of the device, IIRC the MegaRAID controllers write it on one of the last sectors of the drive so that it doesn't interfere with the partition table. Most of them write it somewhere on each disk so that a failed RAID controller can be swapped out with the replacement requiring no configuration.

Makes sense...but as I said before, when I've done similar things on actual server hardware, it's never been possible to transfer drives between systems and read the drives at all. CERTAINLY not transferring a drive that's part of a RAID array from one system and putting it in another as a non-RAID drive. That's just not how it works. So it's a pleasant surprise in the case of the TX2000. =)

Malvineous wrote:

The "AT-IDE" you want is just a normal bog standard ISA IDE controller. On those machines of mine that lack IDE support (or use the wrong CHS translation) I put the XTIDE BIOS onto a flash chip and set it up as a boot ROM on the machine's network card. It adds full bootable IDE support just fine.

This is sort of self-contradictory. Pairing a standard ISA IDE host adapter with the XTIDE BIOS is not the same thing as just using a standard ISA IDE host adapter. 😉... but yes, that is what I ended up doing. Took me a while to get it all working correctly, but I have triumphed and I have no more drive woes on any of my vintage builds.

Malvineous wrote:

That's a shame all yours have arrived broken though. What exactly was wrong with them? I only ask because in my own personal experience I have never come across a failed IDE controller.

So as it turns out, I only had one controller that was straight up *broken*. That card was simply DOA. It caused some confusion for a while but I did sort it all out. The other 2 ISA cards work perfectly, but they're fussy about drive cable lengths and what types of drives can be plugged into them. The key to figuring it all out was getting an old IBM spinning platter IDE drive that was within the size range recognizable by these early system BIOSes. Once I started from that reliable configuration point, I was able to branch out in my troubleshooting logic and determine what combinations worked. Some of the drives work with 40-wire cables; some don't. Some work with 80-wire cables; some don't. Some controllers are friendly with SSDs; some aren't.

The only cards that I haven't gotten to work at all yet are:

* Adaptec PCI cards -- UltraDMA/133. Might just be too new. The bus mastering might be done differently on these guys than how the 486 that I have with PCI slots is expecting. I've abandoned hope on these and I'm either going to return them to the seller or re-sell them. I'll have to verify if they work or not in my most modern system that had PCI slots, of course.

* BusLogic SCSI card -- I only wanted to use the floppy header on this originally, but now I want to use it as a SCSI host adapter. I think the terminators and/or lack of SCSI drives hooked up to the card is preventing anything on the card from working, which is unfortunate. I ended up getting a SCSI CD-ROM drive in the hopes that I could get it to work with that, and provide an easy(?) solution for getting a CD-ROM drive working in a system which doesn't have 2 IDE host adapters or whatever.

Malvineous wrote:

All of the ones I have work, although of course those machines without BIOS support for IDE drives need the XT-IDE BIOS loaded in order to
see the drives.

See, I've had some weird results in this area. My 386 system just would not work with SSDs when plugged into an ISA IDE host adapter, unless the XT-IDE BIOS was employed. But I just got this slightly newer 486 system, and despite the fact that the CHS parameters in the CMOS are incorrect, my 30GB Kingston SSD boots and works perfectly! It's unreal how some of this stuff works.

Malvineous wrote:

It would be extraordinarily unfortunate to get four failed IDE controllers!

Indeed. As I said, it turned out that I only had 1 failed one. The statistics just weren't matching reality, so I figured there was something else going on. I was mature about all this and waited until the very end of my troubleshooting to return anything to eBay sellers. I don't want to be one of those buyers that returns items because they can't get them to work, instead of them actually being DOA.

Malvineous wrote:

Have you tried booting the machine with the controllers and then running diagnostic software to report any IDE devices found, just in case the problem is a lack of BIOS support?

I never did try this, because it never occurred to me that such diagnostic software would exist for DOS. I never saw such programs back in the day, so I wouldn't know what to look for. I did stumble across a nice diag program that PhilsComputerLab included in his DOS Benchmark suite. Was pretty useful!

My own experience with the Z100iDE drives is that they report the correct CHS/LBA values so the BIOSes that support autoconfiguration can support them, if they can talk directly to the drive.

Now that you mention it, I can't specifically recall whether I've seen a passthrough option in a RAID controller, but I have on a few occasions used Linux software RAID with a hardware RAID controller precisely so that I could move the drives to another machine and recover them in the event that the controller failed, as I didn't have a spare available. It's been a while but I think this was down to driver support, in that I configured no drives at all in the RAID BIOS, and then the Linux driver presented the unattached disks as individual devices. However this would've been SCSI at the time, which seems to have more design effort put into it than much cheaper IDE RAID controllers. I know a Gigabyte motherboard I have with on-board IDE RAID has an option in the normal BIOS where you can set those ports to be off, RAID or normal IDE, so the options do exist at some level.

I've successfully moved drives between machines before, but sometimes the metadata one controller writes to the drive will get picked up by another and cause issues. Usually it works best if you remove the drive from the array on the original machine before you transfer it. In my case I used a non-RAID controller and Linux to zero out the first few and last few sectors on the drive and it showed up in the target system as a brand new drive.

At the hardware level, a standard AT IDE controller is no different whether it's the system BIOS or the XTIDE BIOS controlling it. The XTIDE board itself is quite different and I believe won't work even in an AT with IDE support in the BIOS, as apparently it uses the much rarer XTA protocol rather than ATA. In my own experience, I have a 486 board with onboard IDE, however it uses an older CHS translation algorithm which is incompatible with modern machines. This means when I use an SD card via an IDE adapter, the machine can format, read and write to the card just fine, but when I move the card to a different PC everything is corrupted as the LBA sectors appear out of order, corrupting the filesystem. The only solution (if I want to be able to move the SD card between computers) was to load the XTIDE BIOS and have it replace the IDE support in the system BIOS for the onboard controller. XTIDE uses the same CHS->LBA translation algorithm that modern computers use, so with XTIDE controlling the onboard IDE ports it becomes possible to transfer files to and from other machines via the SD card. So in this case it's very much a normal IDE controller (it's part of the motherboard), just with the XTIDE BIOS providing additional functionality.

The issues you describe about the IDE controllers being fussy does mirror my own experience. They all work with hard drives from the era but are hit-and-miss with more modern devices. I found the SD card adapters above were the most compatible modern devices so I bought a bunch of them and haven't looked back!

SCSI always involved a bit of voodoo even back in the day. I never had any issues with PCI controllers but I've got a couple of ISA ones, one of which doesn't seem to let the system POST if the BIOS chip is present. I dumped the contents of the chip and it seems fine, so not really sure what's going on there, but need more time to investigate. There should be no problem running with no SCSI devices present as the bus termination on the controller's end would cover the entire bus. Usually the floppy controller is a completely separate chip run by the system BIOS so it would be odd if that didn't work either.

Be careful with the incorrect CHS values in your 486 with the SSD if that's a long-term setup. As mentioned above, the BIOS uses them to translate to LBA sectors so even if the values are wrong it will still work, however it changes the order that the sectors end up on the disk. It means you need to write the values down somewhere because if the CMOS settings ever get wiped, the disk will appear corrupted until you put exactly the same CHS values back into the BIOS. Also don't expect to be able to move the SSD to another machine and be able to access the data unless a) you can enter the same CHS settings into the target machine, and b) it's using the same CHS->LBA algorithm as the original PC. Modern PCs use LBA directly so the drive will only be readable in a modern PC if the 486 is using the newer CHS translation algorithm *and* the CHS settings match what the algorithm requires. It all gets pretty complicated to be honest, but it's doable. You can find online calculators that let you put in the LBA sector count and they will spit out CHS values that hopefully won't be too large to fit in the CMOS fields.

after some research im pretty sure i need to get either an ATAPI capable addon card for my 386dx40 -- OR find a REAL 100% IDE non-atapi zip drive
i am trying to pursue both of those options - just to finally get all my systems zip-capable

it seems to me that systems prior to 1994 need the IDE versions but from mid-94 onward the ide controllers pretty much all support ATAPI