• Please review our updated Terms and Rules here

8-Bit IDE Controller

Would be cool if we could make a hardcard out of one (basically mount a HD on the end with some metal brackets). yea, I know thats not going to happen.

Hi! Whether this is feasible depends on what it means to the design. If its just a matter of adding some holes and minor rearrangement of the existing design it might be possible. If its a major redesign and/or drives an increase in PCB area its probably not feasible.

I really don't know what this means to the PCB layout so I can't really answer. Please post some examples to illustrate the effect on the PCB design. (not just pictures of a hard card as I know what those look like)

Thanks and have a nice day!

Andrew Lynch
 
Hi Hargle! Tonight I did some testing with the new PCB prototype on my XT test station. After some reconfiguring, I got the latest BIOS (oprom ver 003) installed. I can boot from the floppy drive and use fdisk and format to install MSDOS 5.0. I can see the controller IO ports and ROM from DEBUG. If I boot with the floppy drive, I can see the C: is present and appears to work. I can even see the BIOS boot screen identify my WDC IDE drive for an instant before it disappears.

The bad news is that when it tries to boot from the IDE drive, the LED flashes a couple of times and the XT goes off to la-la land. Not terribly descriptive but the XT ends up hanging hard with an apparent 40 column mode cursor flashing in the upper right hand corner.

I think there is a problem with the BIOS on my XT. Its a generic clone, made by MCT. I am running at 4.77MHz with a VGA card, one of those JDR multifloppy cards, a serial and parallel board and regular XT keyboard. Everything seemed to be working with the Seagate MFM hard drive & controller. I removed the Seagate MFM controller to preclude a clash between the controllers.

Would it be possible to make a test version of the BIOS with prompts for each stage like the earlier versions had? That was really helpful in debugging. All I can say for sure now is that it crashes on boot but appears to be OK otherwise.

Now I have two controllers working; the wire wrap prototype board version running the earlier version of the BIOS which works great and the new PCB prototype running the latest BIOS with some type of problem.

Suggestions on how to move forward appreciated.

Thanks and have a nice day!

Andrew Lynch
 
Was this a drive that you fdisk+formatted using an older rev of the BIOS, or was this drive prepped on another machine?
If you used an older bios to do fdisk, you should redo it using the 003 build and see if that helps. I fixed a bug in the parameter table stuff that impacted certain drives at some point before the 003 build came out.


If this drive was prepped in another machine, then there's certainly something wrong. Let me know the model number/size of the drive you're working with and I'll see if I have anything similar in my stockpile.


The best way to test the BIOS compatibility is to build the drive on a different machine using a "normal" IDE controller/BIOS and then move it to the XT and vice-versa. Ideally your "normal" controller and BIOS would be using BIOS that doesn't have any of the barriers at 520MB, or 8.4G.

Would it be possible to make a test version of the BIOS with prompts for each stage like the earlier versions had? That was really helpful in debugging. All I can say for sure now is that it crashes on boot but appears to be OK otherwise.

The current problem is that that during POST, the XT has the keyboard disabled. I tried that prompty version on my machine and I couldn't ever find the "any key" to continue. ;) Your clone may be different though.

I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.
You could always move the card to your Pentium machine, and the prompts will work there, but I'd prefer to move to XT only testing if possible.

Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.

---------
Ordered more parts from Jameco last night. I'll be building up more of the prototype cards this weekend and then we'll start distributing them to testers and see if we can get the BIOS wrung out this month.
 
Was this a drive that you fdisk+formatted using an older rev of the BIOS, or was this drive prepped on another machine?
If you used an older bios to do fdisk, you should redo it using the 003 build and see if that helps. I fixed a bug in the parameter table stuff that impacted certain drives at some point before the 003 build came out.

Hi! Thanks! That's probably the problem since I just reused the results of the previous fdisk for partition table setup. I used fdisk to verify partition 1 was set up properly and left it alone. Tonight I will delete the partition and rebuild it from scratch to see if that helps.

If this drive was prepped in another machine, then there's certainly something wrong. Let me know the model number/size of the drive you're working with and I'll see if I have anything similar in my stockpile.


The best way to test the BIOS compatibility is to build the drive on a different machine using a "normal" IDE controller/BIOS and then move it to the XT and vice-versa. Ideally your "normal" controller and BIOS would be using BIOS that doesn't have any of the barriers at 520MB, or 8.4G.



The current problem is that that during POST, the XT has the keyboard disabled. I tried that prompty version on my machine and I couldn't ever find the "any key" to continue. ;) Your clone may be different though.

I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.
You could always move the card to your Pentium machine, and the prompts will work there, but I'd prefer to move to XT only testing if possible.

Well, even just printing out debug messages as you go and short pauses would be useful. Maybe set them as conditional assembles for a verbose debug version versus a regular version?

Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.

Yes, I am using VGA on this system. The current system crashes into what appears to be a 40 column mode but I am not sure exactly what its doing.

---------
Ordered more parts from Jameco last night. I'll be building up more of the prototype cards this weekend and then we'll start distributing them to testers and see if we can get the BIOS wrung out this month.

Excellent! Thanks and have a nice day!

Andrew Lynch
 
I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.

It is dissabled in the interrupt controller.

Maybe because of laziness, or because they didn't asume that some BIOS Extensions wans user input. The tests done before was the timer test (time critical) and the main memory R/W test (if the KB was enabled here, you could just have skipped the test by pressing Ctrl+Alt+Del). The test done afterwards is the diskette tests (also time critical). After the diskette tests, the keyboard is enabled.

As long as the keyboard is disabled after the initalizion, it should be all rigth.

Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.

I've set up my XT for testing. Unformally, the EGA drive I got from the school got a bad power supply (see my other post), so I have to use VGA too. I have a Mono monitor, but only one avalible right now (and I have to use that with my other XT).

My test station:

One Early-model IBM XT with 256Kb RAM.
One DD DS 5.25" floppy disk drive.
One (maybe nonstandard) DD DS 3.5" floppy disk drive with drivers.
200W modded PC/AT PSU.
One IBM Floppy disk adapter.
One SoundBlaster Pro II.
One Trident TVGA graphics card.
DOS 5.0 installation disks.

And of course, A pile of IDE drives ranging from 2 to 40 gb!
 
Last edited:
Hi! Please check out the new PCB layout. If there are any changes or new features needed please let us know. I'd like to start the PCB respin process.

Thanks and have a nice day!

Andrew Lynch
 
Hi Hargle! Thanks for the help. Still no luck getting it to boot though. I tried booting from the MSDOS 5.0 floppy and I deleted all the partitions on the disk. Then I created a 32MB primary DOS partition (#1) and set it active. I rebooted and formatted the disk but still no luck.

I tried again with a maximum size (2047MB) partition but that didn't work either. I will try swapping the BIOS on the XT motherboard and also see if the hard disk works on another controller.

Thanks and have a nice day!

Andrew Lynch
 
Hi Hargle! Here is another update. I swapped the motherboard BIOS with another one and it seemed to work better but still has the same problem.

I also put the drive on the other test station with the wire wrap prototype and it booted normally so I think the drive, partitioning, formatting, etc is good.

When I boot the XT clone with out a boot floppy, I noticed the XT-IDE flashes twice and then beeps to boot. Then it hangs.

I also was able to make it hang differently by doing a "fdisk /mbr" where as before it would switch to 40 column mode, blanks the screen, and hangs, now it just stays in the 80 column mode and silently hangs. At least I can see the boot messages though.

Thanks and have a nice day!

Andrew Lynch
 
Hi Hargle! Here is another update. I swapped the motherboard BIOS with another one and it seemed to work better but still has the same problem.

I also put the drive on the other test station with the wire wrap prototype and it booted normally so I think the drive, partitioning, formatting, etc is good.

When I boot the XT clone with out a boot floppy, I noticed the XT-IDE flashes twice and then beeps to boot. Then it hangs.

I also was able to make it hang differently by doing a "fdisk /mbr" where as before it would switch to 40 column mode, blanks the screen, and hangs, now it just stays in the 80 column mode and silently hangs. At least I can see the boot messages though.

Thanks and have a nice day!

Andrew Lynch

Maybe it's an I/O conflict?

Try the usual "remove-all-other-cards-except-the-absolute-needed-ones" tecnique, if it still doesn't work, try to get the referance for your XT-clone, or get a revision of the BIOS patched for another I/O Port base.
 
Hi Per! The XT-IDE clearly works. I can boot the system from floppy and see the partition with fdisk. I can format it and see the C: drive as per normal. I just can't boot from it. I suspect there is a BIOS bug but I will remove all the extraneous boards to minimize the chance of a conflict.

My FDC board has a BIOS on it which may be confusing things too. More in a little while.

Thanks and have a nice day!

Andrew Lynch
 
Hi! OK, I think I've found the problem. If I remove the FDC BIOS chip (CE000-CFFFF) then the XT-IDE BIOS boots from the attached drive normally. Apparently there is a conflict between the FDC BIOS and the XT-IDE BIOS.

My test XT contains one of those JDR/MCT high density FDCs with its own BIOS for supporting 1.4M 3.5" and 1.2M 5.25" floppy drives. Without the FDC BIOS, the card appears to be a regular XT floppy controller and I cannot boot from 1.4M 3.5" floppy disks.

Is there some way to update the XT-IDE BIOS to coexist peacefully with the FDC BIOS?

Thanks and have a nice day!

Andrew Lynch
 
Hi! I just noticed that I can boot from the other motherboard BIOS but not the original one if I remove the FDC BIOS. Apparently whatever the problem is the other motherboard BIOS can work around it but the original motherboard BIOS can't even with the FDC BIOS removed.

Thanks and have a nice day!

Andrew Lynch
 
Hi! OK, I think I've found the problem. If I remove the FDC BIOS chip (CE000-CFFFF) then the XT-IDE BIOS boots from the attached drive normally. Apparently there is a conflict between the FDC BIOS and the XT-IDE BIOS.

My test XT contains one of those JDR/MCT high density FDCs with its own BIOS for supporting 1.4M 3.5" and 1.2M 5.25" floppy drives. Without the FDC BIOS, the card appears to be a regular XT floppy controller and I cannot boot from 1.4M 3.5" floppy disks.

Is there some way to update the XT-IDE BIOS to coexist peacefully with the FDC BIOS?

there are 3 things that I can think of:
1) IO conflict.
Our card is hard coded (at the moment) to using ports 300-308.
I know on my XT, if I pull out our card and read in from ports 300 through 308, something is there responding, and I wouldn't be surprised if an upgraded floppy controller may be using some of those too.

What I'd do is load up debug. pick a number, say 400h and issue the following command:
-i 400
and see what value comes back. If it's FF, then no one is there using that IO address. Do the same from 401 through 408. If all 9 ports come back as FF, then we've found a spot we can use. If something exists there, try 410, or 310 or 200 or anything else where we can get 9 consecutive IO ports to all come back as FF. Then change your dipswitches to decode at that address and let me know what address you decided to use. I will have to build you a new bios that uses your new settings. (we'll make this autodetect soon enough)


2) ROM address conflict
It's possible that both the floppy controller and the XT-IDE cards are bumping into each other at D000 segment. Relocating the option rom to a different address may solve the problem. There was some utility released by microsoft (MSD.exe or something?) that shows free memory addresses that you could use to locate where a free 8k of space may be. Changing the option rom address on your dipswitches will not require a new BIOS change.

3) reserved memory conflict.
Our card looks at the top of base memory pointer and then subtracts 1k off the top. so on a 640k machine, the XT-IDE is claiming 639-640k for itself and then changing the top of base memory pointer to claim there's only 639k total. In that 1k of space, I store the drive parameter tables and a few other bits that we need to keep track of. It's possible that other cards in the system may be blindly taking that same address range and stomping over our parameter tables. That would make the option ROM still ID the drive properly, but cause it to hang at boot if someone else changed the tables I was expecting to use to know how to boot.


Now that I've written these up, I realize that none of these explain how it would work if you boot to a floppy drive and then read the drive that way...
Hmmmm.
 
Hi Hargle! I've confirmed that the XT-IDE has clear access to the IO ports at $300-$30F. Also the ROM is present at $D000:0-$D1FF:0

The FDC has a ROM at $CE00:0-$CFFF:0 and the VGA card is at $C000:0-$C7FFF:0. I placed the XT-IDE ROM at $C800:0-$C9FF:0 and it seems to work OK there. At least its recognized and identifies the IDE hard drive but it still does not boot.

Really the lack of IDE drive booting is not a big deal for me. I can boot from the 1.4M floppy just as well. I think there is some competition going on between the FDC BIOS and the XT-IDE BIOS.

Adding some diagnostic messages for each stage of the XT-IDE boot might give us some clues as to what's happening and where things are going wrong.

Thanks and have a nice day!

Andrew Lynch
 
there are 3 things that I can think of:
snip]

3) reserved memory conflict.
Our card looks at the top of base memory pointer and then subtracts 1k off the top. so on a 640k machine, the XT-IDE is claiming 639-640k for itself and then changing the top of base memory pointer to claim there's only 639k total. In that 1k of space, I store the drive parameter tables and a few other bits that we need to keep track of. It's possible that other cards in the system may be blindly taking that same address range and stomping over our parameter tables. That would make the option ROM still ID the drive properly, but cause it to hang at boot if someone else changed the tables I was expecting to use to know how to boot.

[snip]

Item #3 sounds possible. The FDC BIOS may be doing something along those lines and interfering with the XT-IDE BIOS. Would you like a ROM dump of the FDC BIOS?

Thanks and have a nice day!

Andrew Lynch


PS, I uploaded the FDC-BIOS to the wiki if anyone would like to see it. I noticed one other thing. It appears the XT-IDE BIOS is running first after the motherboard BIOS and then the FDC BIOS. Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?
 
Last edited:
Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

The IBM XT BIOS will search from C8000h to F4000h in 800h increments, and does far-calls to the code as it finds valid extensions. To make the XT-IDE BIOS the last to be called, you have to put it as high in RAM as possible.

I don't know if this is the cause with your XT clone.
 
Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

yep, if you can swap the locations of the ROMs in memory, it should reverse the order in which they get called. So just dipswitch the xtide card as high up as possible, like maybe even at E000.
 
Back
Top