• Please review our updated Terms and Rules here

"rigging" a 16-bit IDE controller to XT

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
with my 22 year old miniscribe just about dead, i've been looking at this SIIG 16-bit ISA IDE controller as a way to replace it with a more modern and much faster IDE drive. it has a jumper on it to modify the controller IRQ to either 14 or 15.

since an XT's IRQ limit is at 9, that obviously won't work right out of the box. i googled the ISA slot pinout, and saw that the connections for selecting IRQ's 14 and 15 are (of course) on the little extended 16-bit section which doesn't have anywhere to plug in on an 8-bit slot in an XT.

i have successfully used this card in an XT before just as a floppy controller and it worked fine with 1.44 MB drives, but seeing that the FDD controller IRQ is within an XT's range that shouldn't be surprising.

what i was considering trying is jumping the connection from the IRQ 14 or 15 pin over to the IRQ 5 pin which is what an XT uses to access hard drives. i am no electronic engineer, and you guys are all smart. does anybody think this will or will not work? would it cause any damage to the motherboard or controller card?

if nobody knows, i will probably just try it and let you guys know how it goes. theoretically i think i would only be able to address between cylinders 0 to 1023, heads 0 to 15, and sectors 1 to 63 from an 8-bit ISA bus. (8-bit ISA has a 20-bit wide addressing ability)

it'll for sure be smaller than what the drive i'd put in can handle. 1024*16*63*512 = 528,482,304 bytes but that sure beats the heck out of a 20 MB MFM! :eek:
 
Don't bother ..

The IRQ limit on an XT is actually 7, not 9. When the AT was introduced 8 more IRQs were added, but they were cascaded from IRQ 2. This effectively removed IRQ 2 from ATs. On an XT IRQ2 is still available.

Next, a 16 bit controller wants to transfer data 16 bits at a time. The XT bus is only 8 bits. Unless you trace all of the lines on the card you won't be able to tell if it will work in an XT with all of the extra address and data lines not connected. Chances are that it won't. Some ISA VGA cards and Ethernet cards have the ability to work in either an 8 bit or 16 bit slot, but most drive controllers do not.

Lastly, do not confuse ISA memory addressability with hard drive cylinder addressing. Two entirely different domains. Accesses to hard drives are done by I/O ports, and the reason behind limited addressing for large hard drives has to do with the assignment of bits in the BIOS calls and data structures that control hard drives.

Mike
 
I think it's quite likely that the card uses more than just the IRQ lines on the 16-bit portion of the card. Maybe if you can re-write the BIOS (assuming it has one) you might be in luck. Though, since you don't have the source code and probably won't have access to documentation for the proprietary ASIC on the card, it's probably not possible.
 
Last edited:
well, if the card has it's own BIOS it will be at C8000h. i might just try it, and if it doesn't work i can try writing a tiny little program on a floppy to jump the program counter to that address... if it DOESN'T have one, well maybe i could write a prog to manually stick all the hard drive information that DOS would use to access it into the proper locations in memory. then i could have the prog copy the MBR sector to 0000:7C00 and jump there to force an HDD boot.

let me know if that is also a bad idea. :-|
 
btw mbbrutman, in the IDE specifications it says that all IDE controllers WILL be in 8-bit access mode unless the IOCS16:

Data bus lines D8...D15 are valid only when IOCS16- is active and the drive is transferring data. The transfer of ECC information occurs only on data bus lines D0...D7 and data bus lines D8...D15 are invalid during such transfer.

source: http://www.repairfaq.org/filipg/LINK/F_IDE-tech.html
(it's in section 5)

the IOCS16 pin is on the extended 16-bit section of the card according to the pinout, and will not be connected to anything in an XT thus this card WILL work in 8-bit mode.

i just need to get software to properly initialize the drives and load the MBR. i think this is very do-able, it'll just take a bit of tinkering.
 
I don't think that you have any idea of what you are messing with here.

If the card has a BIOS extension it will be found when the XT boots. You don't need a program to call it, nor would it work. Executing a BIOS extension is quite a bit different than calling arbitrary code that you compiled.

Trace the wires on the card. If it is using anything other than the high IRQ lines that the AT bus adds, then it's probably not going to work. I'd be looking for an old 8 bit SCSI card (Trantor T130B or Future Domain 85x series) with a bootable BIOS and a small SCSI drive instead.
 
if i pull off some sort of magic here and get it working, i'll make all the info available for others to do it... including special software if necessary. can't hurt to try it.
 
You are misreading the spec:

Data bus lines D8...D15 are valid only when IOCS16- is active and the drive is transferring data. The transfer of ECC information occurs only on data bus lines D0...D7 and data bus lines D8...D15 are invalid during such transfer.

This is merely saying that the upper 8 data lines are only active when IOCS16 is set correctly. It also says that ECC data only happens on the lower 8 data lines, and that the upper 8 data lines are invalid while ECC data is being transfered. It says nothing about the IDE spec being forced to support 8 bit transfers.

Read further:

-IOCS16
indicates to the host that the 16 bit data port has been addressed and the drive is prepared to send/receive a 16 bit data word. This signal is an open collector output. D8...D15 are only valid when -IOCS16 is active and the drive is transferring data. The transfer of ECC data occurs only on D0...D7 so D8...D15 are invalid during ECC transfers.

This signal comes from the card and is read by the machine, not the other way around. The poor card is going to be telling the machine to get ready for a 16 bit transfer, and the poor machine isn't going to be able to read the data.

Most drives and controllers don't support 8 bit transfers. You are going to have to find a fairly old IDE drive and a fairly old controller to do this.

There has been a lot of discussion about this in the past on the cctalk mailing list. I'd suggest checking our their archives and reading up.
 
i should start listening to you instead of wasting my time. i bridged the IRQ lines and installed it, set it to 170h base I/O. i've tried every jumper combination possible on the drive. when i read the I/O ports, these are the values that i should get. (the IDE controller is supposed to default it to these after it gets power or is reset:

Code:
REGISTER          VALUE
1F1 Error         : 01
1F2 Sector Count  : 01
1F3 Sector Number : 01
1F4 Cylinder Low  : 00
1F5 Cylinder High : 00
1F6 Drive / Head  : 00

however, every one of those values is just decimal 228 when i read the registers in qb. i don't even think the computer is seeing it there.

ah well, i guess i'll try to find an acculogic sIDE-1/16.... those are like 15 years old, it'll be hard. they are supposed to work with all IDE drives though, including 16-bit ones.

i'm assuming the card is not activating the IDE interface due to the 16-bit part of the card not being plugged in.

EDIT: another glaring difference is that an XT-compatible HDD controller will be either base 320h or 324h.
 
Last edited:
WHOA!! check this out. i dl'ed this little utility called ATAHD... i tell it to look at 170h master drive, and.... well, see for yourself.

oh-snap-xt-ide.jpg


^yes thats a shot of the XT's screen.

makes you wonder if just takes a little bit of creative programming to get DOS to recognize it. maybe by doing something similar to what a normal BIOS would have done as far as detecting the parameters, and putting that info into the memory so DOS can see it....

maybe... this is promising, if nothing else.

i didn't do anything special to get that, like i said i just bridged the IRQ 14 line on the card to the IRQ 5 line and set it to primary IDE 170h... then just a normal clean floppy boot of caldera dr-dos 7.02 and then ran atahd.

EDIT: i should probably talk to trixter. anybody who can write something like 8088 corruption might have some ideas... or if it's not even possible. from what it looks like, it can see 256 cylinders, 16 heads, and 63 sectors on the 8-bit bus... not a huge amount of capacity there, but again... beats the 20 MB :p
 
Last edited:
Reading the ROM in the HD vs transferring data stored on the HD, are different stories.

Wait a sec. A 125MB drive with SMART status?
 
The IDE spec is derived from the ST506 spec. It's possible to take an MFM controller out of an AT and replace it with a modern IDE controller and have the AT BIOS (not an onboard card BIOS) drive the new controller.

One of the reasons is that the commands and IO registers are still eight bits. So it is very possible to talk to an IDE controller using 8 bit IO transfers and get it to respond. But when the controller tries to move data to or from the drive, those are going to be 16 bit transfers. Reading the ROM and doing basic commands against the controller might be possible, but you still can't do the data transfer.

Find the SIDE controller with the 8 bit drive support - that is your best bet.
 
I've got a 16-bit IDE hard drive attached to my 8080 using 8-bit transfers. It halves the capacity of the drive but this isn't a huge issue in my opinion because hard drives are usually pretty big (relative to a usual XT hard drive).

The solution that immediately springs to mind is to use a ROM from an ESDI drive and use a microcontroller of some sort to 'emulate' the layer between the IDE drive and the ESDI interface. My Compaq Portable II did this, except the interface was from IDE to ESDI, not ESDI to IDE.
 
I think the approach used on the sIDE card was to accept a 16 byte transfer from the hard disk and latch the upper 8 bits so that it could be transferred to the host during another IO cycle.

When you talk about halving the capacity because you are not using the upper 8 bits, is it something goofy like only having 256 byte sectors because half of the data is being thrown away?
 
When you talk about halving the capacity because you are not using the upper 8 bits, is it something goofy like only having 256 byte sectors because half of the data is being thrown away?

There's at least one ATA interface for the Sinclair Spectrum which does this, running the drive at half capacity by only using the low 8 bits of each word. More sophisticated ones do the latching thing to use the full drive capacity.

If you did want to sit an ATA controller in an 8-bit ISA slot, I'd suggest using CompactFlash as the drive rather than a real hard drive. There's an optional ATA feature to use 8-bit transfers rather than 16-bit, which hardly any hard drives support but CompactFlash is required to. Still have to write your own BIOS, of course.
 
I'd tell you exactly what Mike Brutman was telling you: Stop wasting your time :) unless you're willing to rewrite and reburn the BIOS on the card.

:rofl: That was almost a perfect setup. Jim and I have spent a little bit of time discussing similar problems and doing high performance code. :rofl:
 
I'd tell you exactly what Mike Brutman was telling you: Stop wasting your time :) unless you're willing to rewrite and reburn the BIOS on the card.

dang. oh well. i guess i should just browse around the web until i can find an 8-bit acculogic IDE card or equivalent. they're not exactly easy to come by these days. i can go down to the basement dug up one of my 286 PC's. i could use the IDE card in them. the only problem is 286 chips are way too fast for me, and i need to use XT's so my brain can keep up.

the MFM HDD in mine is totally dead now just this morning it stopped loading QB at all, and when turning it on the chances of it actually booting into DOS are about 50%

talk about good timing on that FTP drive image backup app i whipped up. :)
 
talk about good timing on that FTP drive image backup app i whipped up. :)

Let's just hope you tested the restore code thoroughly! ;)

BTW that was a great idea for a utility, being able to image a drive over TCP/IP (and have it be compatible with XTs). Unlike my programming, which is mostly useless, you're starting to create quite a stable of useful utilities for old PC hobbyists. Great work!
 
Back
Top