• Please review our updated Terms and Rules here

XT-IDE tech Support

Boot from slave drive was successful with v0.10 BIOS. So it is a new bug in v0.11.

I tried to remove CF card and here is a picture of what happened. First i typed dir. After that i removed and reinserted the CF card. When i tried to start the game, thats all what happened. So it is not possible to remove and reinsert CF cards while computer is running.

I tried DOS 3.31 on 286. I used 540MB Quantum and set CHS parameters to 1006/16/63, same to what the 512MB CF card uses. I was able to create, format and boot to full sized partition. So DOS 3.31 does work with large partitions.

The question is why doesn't it work with XTIDE and 512MB CF card. I think that the same thing prevents to boot Tandy DOS 3.2 to partitions larger than 25MB. Then again, XTIDE did boot successfully when 512MB CF card was formatted with DOS 6.22.

Edit:
One more thing. I tried to create, format and boot to a full sized DOS 3.31 partition with BIOS v0.10. It didn't work so it is not some v0.11 bug.
 
Last edited:
I now know for sure that DOS 3.31 boot problems are some bug in XTIDE BIOS. I created, formatted and successfully booted to 500MB DOS 3.31 partition with my BIOS. I flashed XTIDE 0.11 bios and boot failed as usual. Then i tried the same hard disk on a 286 and it booted fine. So something in XTIDE BIOS prevents to boot large DOS 3.31 partitions.

I have an idea what the problem might be (just a guess). You don't seem to have any protection for offset overflows when transferring more than one sector. I have a check in my bios that normalizes a far pointer so that offset can never overflow.
 
I now know for sure that DOS 3.31 boot problems are some bug in XTIDE BIOS. I created, formatted and successfully booted to 500MB DOS 3.31 partition with my BIOS. I flashed XTIDE 0.11 bios and boot failed as usual. Then i tried the same hard disk on a 286 and it booted fine. So something in XTIDE BIOS prevents to boot large DOS 3.31 partitions.

I have an idea what the problem might be (just a guess). You don't seem to have any protection for offset overflows when transferring more than one sector. I have a check in my bios that normalizes a far pointer so that offset can never overflow.

That's excellent news for DOS 3.31 users!
I'm curious as to why DOS would be issuing a transfer request that might overflow an offset though? One would think that whatever DOS would be doing, it should be "safe" and not require any checking on boundaries.
 
One would think that whatever DOS would be doing, it should be "safe" and not require any checking on boundaries.

I think earlier DOSs (DOSen?) made a lot of assumptions about hardware. A 10 MB hard drive was HUGE. A 32MB (at the time of DOS 2.1) was probably even considered pretty darned big. No one anticipated the need or desire to run DOS 2.1 on a 500MB hard drive. It was inconceivable.
 
I think earlier DOSs (DOSen?) made a lot of assumptions about hardware. A 10 MB hard drive was HUGE. A 32MB (at the time of DOS 2.1) was probably even considered pretty darned big. No one anticipated the need or desire to run DOS 2.1 on a 500MB hard drive. It was inconceivable.

yeah, I can see that. what aitotat is getting at (or I think so) is that when DOS is loading, it's loading data into weird places of memory. Ie, it may be loading 40k of data at the end of a segment of memory, and wrapping back to the start of a segment during the transfer. the XTIDE bios isn't doing any checking on things like that, because DOS at a minimum shouldn't be loading chunks of memory in to places where wrapping could occur.

Unless the amount of, or locations of, chunks of code that DOS needs is dependent on the drive size, it shouldn't be doing something that would cause the controller itself to have to question/fix the location as to where the data was going to end up after reading it off the drive.

Not saying that putting some protection in isn't a good idea, just saying that it's weird that DOS is even trying to do something edgy like that in the first place.

Either way, this is all excellent news that we have proven that it's a BIOS issue making it not work, and it sounds like we have some new BIOS that it works on, so the future is very bright indeed.
 
Unless the amount of, or locations of, chunks of code that DOS needs is dependent on the drive size, it shouldn't be doing something that would cause the controller itself to have to question/fix the location as to where the data was going to end up after reading it off the drive.

Cluster size seems to be 4kB for 128MB-256MB partitions. Larger partitions up to 512MB use 8kB clusters. Since DOS 3.31 was the first DOS to support over 32MB partitions, it is possible that it uses the same boot loading code that DOS 3.30 uses. If i remember correctly, DOS always loads at least one complete cluster at a time.
 
Ok, so I finally managed to get my proto card up to version 11, and I am playing with 4 drives, 2 work, 1 does not boot and 1 is very odd.

My WD Cavier (205BA) is detected, allow for parition and format but will not boot.

My Toshiba MK6014MAP (6gb laptop drive, Hargle this is the drive that would only come up as slave on previous BIOS versions) does not detect by the card, and when I hit esc to bring up the menu I get "Non XT-IDE Device" scolling on the screen. If I don't hit esc it boots to the floppy and is unable to fdisk or anything.

The other 2 laptop drives format and boot just fine.

Any ideas?
 
My WD Cavier (205BA) is detected, allow for parition and format but will not boot.
what DOS version? DOS 6.22 seems to be a good starting point to verify functionality, then you can try branching out from there.
You might also need to do a "fdisk /mbr" after booting to a floppy.
What error messages are you getting when it doesn't boot, or is it just hanging as it is trying to boot?

My Toshiba MK6014MAP (6gb laptop drive, Hargle this is the drive that would only come up as slave on previous BIOS versions) does not detect by the card, and when I hit esc to bring up the menu I get "Non XT-IDE Device" scolling on the screen. If I don't hit esc it boots to the floppy and is unable to fdisk or anything.

So the IDing of this drive has changed between BIOS versions?
1st obvious question: you know this is a good drive?
2nd obvious: check master/slave/cable select jumpers on the drive to make sure they are set properly.

Honestly, I'm not sure what to do there. However, if there was a change between 10 and 11, then maybe a diff between those code bases will expose something. very strange though. Getting the ID off the drive is about as simple as it gets. you could always mail it to me I guess, if you wanted to risk it in shipping.


the scrolling boot menu is of course a bug. If it didn't detect any drives, it should not have incremented the drive count #, and the drive count # is how it figures out how to display the menu. maybe i'm not taking a zero count into consideration...

my weekend to work on anything is blown already, so it will probably be monday before I can do any looking.
 
what DOS version? DOS 6.22 seems to be a good starting point to verify functionality, then you can try branching out from there.
You might also need to do a "fdisk /mbr" after booting to a floppy.
What error messages are you getting when it doesn't boot, or is it just hanging as it is trying to boot?

I am using DOS 6.22.

I did a few things:
1. FDisk /MBR
2. Replaced the 40pin cable with and 80 pin cable
3. Recreated a partition (1gb this time)

And boom it booted just fine. So I will do more investigation to work out which of these 3 fixed it.


So the IDing of this drive has changed between BIOS versions?
1st obvious question: you know this is a good drive?
2nd obvious: check master/slave/cable select jumpers on the drive to make sure they are set properly.

1. Yes, it is a good drive. Works fine in my other machine and in my IDE to USB adapter.
2. Its set to master, but the jumper setting seems to do nothing.


you could always mail it to me I guess, if you wanted to risk it in shipping.

Since this seems to be the one total odd ball drive we have encountered I can ship it to you, I have enough padding for it and I think I have your address somewhere. I'll PM you later about it.

my weekend to work on anything is blown already, so it will probably be monday before I can do any looking.

No worries, there is no rush on it. I just think its a pretty good drive to play with to help better the project.
 
OK, so I finally got my Rev. 3 BIOS in for the 5150 and plugged in the XT-IDE card for testing.

Nothing. :(

I tried several different configurations of the DIPs and IRQ, to no avail. ROM is enabled, Write Protect enabled (though I might have accidentally had it disabled the first time through).

The boot sequence is as follows:

1. Power up.

2. LED on card illuminates for differing times depending on what drive I have attached, but usually for around 5 seconds or so.

3. Nothing else happens, not even the usual 'underline cursor' that I see without the card installed.

Unplug the card, machine is back to working again.

I also tried stripping the machine down with nothing but the XT-IDE and mono graphics adapter, this didn't help.

Suggestions? Thanks!
 
Just to verify some things, Is this your first power up with the card?
Do you know the card itself works, or perhaps there is something wrong with the build of the card that is causing the 5150 to puke?
 
This is the first power-up of the card. The 5150 is my only machine with an ISA port, so I'm unable to verify proper operation of the card in another machine.

I double- and triple-checked my build. I sure wish it was that easy, but all is as it should be.
 
ok, put the card's IO space at 300h, as default.
Then disable the ROM with the jumper. (or pull the eeprom out)
Don't bother hooking up any drive.

If you can boot at this point, then there is something in the ROM that is keeping it from booting. We can check to see if it's decoding the IO space if you can get to a DOS prompt.

If that doesn't work, you can try other IO settings to see if the card is conflicting with something.

After that, one of the smarter hardware guys here might be able to instruct you on which teeth on the card you might be able to cover up with tape (or something) to stop the IO from decoding on the card altogether. If you can get the IO from decoding, then you could verify the eeprom section of the card is working.

that's all I can think of at the moment.
 
Hi! If the PC won't boot at all with the board installed that indicates a hardware problem to me. Especially if you've already disabled the ROM and tried various IO ports with no luck. In that case, I would probably start with the basics.

First, I'd pull the board and physically inspect it since the two most likely culprits are either a bridge or a cold joint. Remove all the chips and go over all the solder joints again. Remelt all the joints and remove as much excess solder as possible. Inspect your removed chips to ensure there are no bent pins. Clean the solder side of the PCB as best possible to allow thorough inspection.

Then use your VOM to inspect for hidden bridges looking for continuity where it shouldn't be and ensure those pins that are supposed to be connected are actually connected. You can walk through the design fairly quickly with a VOM.

With the chips all removed, install the PCB bare in your system and see if it boots. It should be "invisible" to the PC with no chips on the bus anywhere. If the PC won't boot you have a problem with the bare PCB.

Then remove the PCB and install just those chips which actually touch the bus. That would be the two 74LS688's, the ROM, and the 74LS245. They won't actually do anything but if you reinstall the PCB in the PC and it won't boot that says you have a bad chip.

Just build the board up one chip at time until you find the part that is causing the boot to hang. Be extra careful to power the system off completely between boot cycles and insert the board the proper way.

I hope this helps. Thanks and have a nice day!

Andrew Lynch
 
That most certainly does help. I will take some time troubleshooting and let you guys know what I find out. My solder job was actually pretty neat (I am used to putting together ham radio kits with way more joints) but it's certainly worth going over with the VOM.

Given my relative faith in my build, I may get some of the chips coming from Digi-key today just in case. I have a lot of 74* parts, but alas no comparators or bus transceivers.

If my ROM is toast, what's the best way to get a working one? I only have PIC programmers here, unfortunately. If somehow I get the board to boot with the ROM disabled, is there a way to program a new one with the board and flasher software?
 
If my ROM is toast, what's the best way to get a working one? I only have PIC programmers here, unfortunately. If somehow I get the board to boot with the ROM disabled, is there a way to program a new one with the board and flasher software?

Yes, but run SETUP.COM first to get the syntax to use.
 
I found an inexpensive source for smaller compact flash cards. I ordered 5 128 meg cards from http://www.memorysuppliers.com/

I've been playing around with partition sizes in DOS 3.2 on my Tandy 1000sx. Right now, 32 and 24 meg doesn't boot properly, 16 meg does. Going to try 20 meg next, but got bored yesterday after 3 fdisk, format, test cycles.
 
I found an inexpensive source for smaller compact flash cards. I ordered 5 128 meg cards from http://www.memorysuppliers.com/

I've been playing around with partition sizes in DOS 3.2 on my Tandy 1000sx. Right now, 32 and 24 meg doesn't boot properly, 16 meg does. Going to try 20 meg next, but got bored yesterday after 3 fdisk, format, test cycles.

my 1000TX and 1000RL both came with Tandy DOS 3.2 and 20MB hard drives, if i recall, that was the largest size that you could buy at the time so its possible that its the largest partition size available
 
It was very common back in the day to create the C: partition as 32MB and to dedicated the rest to extended drives. Depending on your version of DOS and utilities, there were some programs and parts of DOS that had trouble supporting partitions with more than 65K sectors.

An early workaround was to install a special driver that loaded before the OS and resided at the top of RAM that "blocked" 512 byte sectors into 1024, 2048 or 4096 byte "logical" sectors. Since the maximum number of sectors remained the same (65K), you could accommodate up to 256MB partitions.

But it was hugely inefficient--and it broke many applications that relied on a sector being 512 bytes. It was better than nothing, however. Ya do what ya gotta do.
 
DASP, CF cards and LEDs

DASP, CF cards and LEDs

I've been trying to figure out why I got such poor (i.e. it doesn't work) performance from the XTIDE LED connector when I use a CF card on it.

Digging through some CF datasheets, it turns out that some regulate down to 3.3V Vcc and many can't sink more than 4 ma. That's perhaps enough to light a small low-current LED, but not the larger front-panel indicator LEDs, particularly not with the on-board LED in parallel.

My thought is to use the spare (at least according to my schematic) LS04 U5F and drive the LED between the output and ground, instead of Vcc.

One could extend this to allow for off-board controller activity indicators by using a couple of diodes at the input to the LS04 to provide a negative-OR with the XTIDE DASP and the activity indicator from a separate controller (say a SCSI one) to provide a single activity LED.

I'll let you know how it goes.

(Aren't you sorry that you sold me the board? :) )
 
Back
Top