• Please review our updated Terms and Rules here

XTIDE and Windows 95 issues

CrazyChris

New Member
Joined
Feb 29, 2016
Messages
7
Hi,

i use XTIDE with latest Build r588 (12kb atl version) and 3com 509b Ethernet card for the Bootprom. (486 System) XTIDE is running at address C800 and detects my harddisk successfully.

Now i have a MS-DOS and a Windows 95b installation. DOS runs fine, Windows 95 had some issues:

first, the harddisk is running in "dos compatibility mode" I think the protected mode driver is not loaded. Is it possible to fix this issue?

second, it is not possible to install the networkcard drivers for the 3com 509b ISA Ethernet Card. During the installation process, the system crash
with an bluescreen:

Errorcode 6 with an address: C800:00002046

looks like the XTIDE address space... :wow::bigups:

With enabled 3com drivers, windows crashes during bootprocess.

Any suggestions how to fix this issues? thx :)



P.S. Whats happing with the "official" XTIDE Beta testing thread?
 
I would guess that, because you're using the network card to host your boot ROM, the Windows driver thinks a network boot ROM is installed in the card and is trying to read it to help configure the card. Since it's an XT-IDE ROM instead, the data the driver is reading off it is invalid and it crashes.

As for why the hard drive drivers don't work, I'm guessing you're using the XT-IDE ROM with a controller that's not an XT-IDE controller? I'm not really sure how or if that issue can be fixed, but I'm guessing you're using the XT-IDE ROM because your motherboard's BIOS doesn't support your drive size or something, in which case the Windows driver for your controller probably doesn't know how to handle your drive size either and falls back on using DOS calls to access it.

If it is the case that you're using something that's not an XT-IDE controller with an XT-IDE ROM just in order to get around a BIOS drive size limit, it might be possible to get around these issues by removing the XT-IDE ROM and installing Dynamic Drive Overlay software like EZ-Drive or something similar. Note that that will probably involve re-partitioning and reformatting your hard drive, though.
 
first, the harddisk is running in "dos compatibility mode" I think the protected mode driver is not loaded. Is it possible to fix this issue?
It might be but I don't know why this happens, I've personally never done any testing under Windows 9x.

second, it is not possible to install the networkcard drivers for the 3com 509b ISA Ethernet Card. During the installation process, the system crash
with an bluescreen:

Errorcode 6 with an address: C800:00002046

looks like the XTIDE address space... :wow::bigups:

With enabled 3com drivers, windows crashes during bootprocess.

The BSOD with error 6 means "Invalid Opcode Fault". My guess is that the NIC drivers, when detecting an enabled ROM, assumes that the ROM contains a 3Com specific binary and just blindly calls that address for some reason. Unless there's a way to prevent this behaviour somehow, the only solution is to find another driver that doesn't do this.

P.S. Whats happing with the "official" XTIDE Beta testing thread?

Nothing much. You probably should have posted this in that thread. :)
 
The NIC driver shouldn't be scanning the ROM at all, its only used for PXE booting normally. If you can, disable PnP mode on the NIC and manually set resources. Windows 9x is likely doing something silly in the UMB area and crashing as usual. If disabling PnP mode on the NIC doesn't work, try adding "LocalLoadHigh=0" to the [386enh] section of system.ini.

As long as your IDE controller is at the normal hardware locations, the built in driver should work. There is a quirk where Windows reads the EBDA to check for the existence of a IDE hard drive. If you have an option ROM controlling your IDE drive and the drive is set to "disabled" in the BIOS, the protected mode driver will not load. Set your drive up in the BIOS with dummy CHS parameters (1024/16/63 usually works).
 
Thanks for your help. Sounds good, i will try it.

It´s an old 486 systemboard, made by siemens-nixdorf with opti 495 chipset and custom bios from late 93. 504MB barrier... :roll:


Maybe i have to go the junkyard and get one of those crabcards...:bigups:
 
I just remembered someone having a similar problem with Invalid Opcode Fault and IIRC that was solved by enabling shadowing of the ROM in the system BIOS setup. Might be worth trying if it's not already enabled.

The dummy drive workaround is a bad idea that will likely lead to data corruption sooner or later.

EDIT: Yep it was Malc who had this same problem: http://www.vcfed.org/forum/showthread.php?17986-XTIDE-Universal-BIOS&p=321385#post321385

EDIT2: Actually, it wasn't Malc: http://www.vcfed.org/forum/showthread.php?43410-XT-IDE-BIOS-in-BOOT-ROM-socket&p=332921#post332921
 
Last edited:
The "dummy drive" configuration shouldn't cause any problems. The XT-IDE ROM should hook Int 13h in real mode bypassing the BIOS routines. In Windows, the protected mode driver will bypass Int 13h completely. Just about every disk overlay and IDE option ROM card recommended doing it back in the day, likely because of this "bug" in Windows.
 
Thx. :)

I have only the option to enable BIOS and Video BIOS shadowing (which is already enabled). There is an option to enable "Shadow RAM Caching" (set to Video BIOS only) but i don´t think this solve anything.

Meanwhile i think the problem is the 3com NIC. Malc has the same card...
 
The "dummy drive" configuration shouldn't cause any problems. The XT-IDE ROM should hook Int 13h in real mode bypassing the BIOS routines. In Windows, the protected mode driver will bypass Int 13h completely.

XTIDE Universal BIOS doesn't bypass anything. It will handle calls meant for the drive it's been configured to handle and pass calls meant for other drives to the previous Int13h handler in the chain. In this case, the system BIOS. So you will have two drives in DOS, both of which are accessible for writes, each with its own set of buffers and caches. Not to mention they will also very likely be using different drive geometries.

In Windows, you will have the "dummy drive" accessed only by the protected mode driver as you say, but, unless Windows can magically figure out that all drives are actually the same physical drive, you will also have the drive handled by XTIDE Universal BIOS in "DOS compatibility mode". Again, each drive with its own cache and possibly with differing drive geometries ("possibly" because Windows might be smart enough to ignore the drive geometry used by the system BIOS).

I don't see how this can be safe since there is no way (AFAIK) to prevent the OS from caching or writing to specific drives.

Just about every disk overlay and IDE option ROM card recommended doing it back in the day, likely because of this "bug" in Windows.
Do you have a link to one of these recommendations?
 
Pre-PCI systems are VERY touchy regarding option ROMs that hook Int 13h, only reason why I know this is that my 486 really hated having a SCSI card and a LBA BIOS card with both ROMs enabled. By default they usually register the first drive they find as unit 80h over-riding the BIOS and any other option ROMs that precede it during POST. EX: Install a ISA SCSI card with HD and enable its ROM alongside of the XT IDE ROM and watch what happens. Whatever card is scanned last by the BIOS usually lands up as the boot drive at 80h. There is usually no chaining of Int 13h on these systems.

Newer machines have a BIOS that conforms to the BIOS Boot Specification and likely have the double drive problem. One thing that may need to be addressed in the XT IDE AT versions is if it properly updates the BDA (see except below of page 20 of the above PDF). If not, Windows 9x might not think any IDE drives are present in the system (I don't think my LBA card properly updates the BDA, it assumes a drive is set in the BIOS).

5.2.5 Controller Installation Guidelines
· Each controller may install INT 13h support for one or more drives.
· When INT 13h is hooked, the old vector will be saved.
· A controller will only respond to requests which specify the drive number for
which it has control, and will pass on requests to other drive numbers to the old
vector.
· A controller may not know if it has any drives attached until it is called to install.
If no drives are attached, then the controller should not hook INT 13h.
· The number of hard drives currently installed is stored in the BDA at address
0040:0075. When a controller installs support for additional drives, this location
must be incremented by the number of drives that are to be added.
· A controller must install INT 13h support by using sequentially increasing drive
numbers starting after the drives previously installed. For example, if two drives
are already installed when the controller gets called, they will occupy drive
numbers 80h and 81h. The next available numbers for the controller to occupy
would be 82h, 83h, etc.
· A controller checks if the location at 0040:0075 is zero to determine if it is the first
to install. If it is first, the controller must copy the INT 13h vector over the INT
40h vector so that floppy services are handled properly.
· The first controller to install will get drive number 80h. The controller then knows
that it controls the hard drive boot device.
21
· Once a controller has hooked+ into INT 13h services, it can never unhook, since
controllers hooked in after it would be lost.
· Any controllers such as Legacy cards which hook INT 18h or INT 19h may end up
taking over the boot process and may possibly reduce the capability of the BIOS to
control the boot order.
 
The NIC driver shouldn't be scanning the ROM at all, its only used for PXE booting normally. If you can, disable PnP mode on the NIC and manually set resources. Windows 9x is likely doing something silly in the UMB area and crashing as usual. If disabling PnP mode on the NIC doesn't work, try adding "LocalLoadHigh=0" to the [386enh] section of system.ini.

Disable PnP mode fixed the 3com driver crash during installation. Now the network card with XT-IDE rom works under windows 95. :D

As long as your IDE controller is at the normal hardware locations, the built in driver should work. There is a quirk where Windows reads the EBDA to check for the existence of a IDE hard drive. If you have an option ROM controlling your IDE drive and the drive is set to "disabled" in the BIOS, the protected mode driver will not load. Set your drive up in the BIOS with dummy CHS parameters (1024/16/63 usually works).

Did not work with my system. If i set some parameters in the BIOS, the bootmanager on my hdd won't load properly. XT-IDE detects the disk but XFDisk bootmanager failed with 'invalid operation system' :oops:
 
One thing that may need to be addressed in the XT IDE AT versions is if it properly updates the BDA (see except below of page 20 of the above PDF). If not, Windows 9x might not think any IDE drives are present in the system (I don't think my LBA card properly updates the BDA, it assumes a drive is set in the BIOS).

XUB adds in the drive count in the BDA so this is not the problem.
 
Whay using the XT-IDE with a 486 system? You can simply use any normal 16 Bit ISA IDE controller there, Vesa-Local-Bus, MCA (if it's a PS/2), EISA and PCI IDE controllers are also supported by Windows. With such generic IDE card, with an adapter für less than 2 dollars you can even attach (small) compact flash cards to such controllers. I am running several computers of the AT class with Compact Flash cards that way.

XT-IDE was designed specially for XT class computers (8088/8086) and they are a kind of waste in an AT or better, they even slow down such a machine. I also don't think that there will be a dedicated driver for Win 9x and newer.
 
Whay using the XT-IDE with a 486 system? You can simply use any normal 16 Bit ISA IDE controller there, Vesa-Local-Bus, MCA (if it's a PS/2), EISA and PCI IDE controllers are also supported by Windows. With such generic IDE card, with an adapter für less than 2 dollars you can even attach (small) compact flash cards to such controllers. I am running several computers of the AT class with Compact Flash cards that way.

XT-IDE was designed specially for XT class computers (8088/8086) and they are a kind of waste in an AT or better, they even slow down such a machine. I also don't think that there will be a dedicated driver for Win 9x and newer.

As far as I can tell, he is not using an XT-IDE card (or any other 8-bit harddisk controller) in his 486. He is using XTIDE Universal BIOS.
 
Yes, I am using the standard Onboard IDE ports provided by the 486 mainboard. Previous i tried to use Ontrack DDO to bypass 528MB limit but this did not work properly in a dualboot environment. (lot of issues with bootmanagers etc.) So i chose XTIDE Universal BIOS. :)
 
IIRC I had to install drivers for the onboard ide controller on one of my 486 board (I don't have it anymore) which cured the 'dos compatibility mode' problem.
 
first, the harddisk is running in "dos compatibility mode" I think the protected mode driver is not loaded. Is it possible to fix this issue?
I had exactly the same problem last week when trying to get a multiboot system working on my Toshiba T5200 orange gas plasma portable running DOS versions from 3.3 to 6.22 and Windows from 3.0 to 95osr2
This machine has only 3 drive types in the BIOS with a maximum of 100MB although I did manage to patch the BIOS to support 504MiB.

I then tried using several different drive overlay programs to support an 8GB compact flash card but although they mostly worked they all stopped Windows 3.0 from running in 386 Enhanced mode, it just exited back to the C: prompt during startup with no error message.

Looking for an alternative solution I came across the XTIDE universal bios so I programmed a copy of the AT version into an EPROM configured to control the main IDE interface of the T5200 and put it in my network card and that worked with windows 3.0 running just fine but then Windows 95 was stuck in MSDOS compatibility mode.

I tried re-enabling the drive in the CMOS as suggested by njroadfan and that resulted in two copies of the drive being detected, the first (drive 0x80) was unbootable as it was detected by the Toshiba BIOS and the second copy (drive 0x81) would boot if the boot priority was changed in the XTIDE settings and that resulted in Windows 95 running with the 32 bit protected mode driver but also gave an unformatted ghost drive as drive D.

I then tried patching the XTIDE BIOS to zero out the BDA drive count (the value mentioned by njroadfan) before it detected the drives. As the drive was also enabled in the CMOS, this meant that both the Toshiba BIOS and the XTIDE BIOS detected the drive as 0x80 but as the XTIDE BIOS was first in the chain, it had control of the drive and the Toshiba BIOS would never receive any commands for the drive.

This patch seems to work OK and Windows 95 boots with the 32 bit protected mode driver and no ghost drive.

One problem still remains and that is I can't get 32 bit drive access in windows 3.1 so that is still using the BIOS. The default Microsoft driver only supports drives up to 504MiB and the 3rd party drivers I have fail to load during startup as they detect a problem with the drive. Perhaps they are doing a more detailed check of the CMOS settings compared to the values reported by the drive and failing because they don't match.
 
Search the internet for MH32BIT.EXE. It is a universal Windows 3.1x Microhouse 32-bit IDE driver that works with drives over 504MB to the Int 13h limit of 8.4GB.

Windows 9x's esdi_506.pdr driver appears to be really really brain dead when it comes to detecting drives properly. As expected, there is something it doesn't like about the XT-IDE BIOS. One of these days I'll have to try the UniATA driver on Win9x. Windows NT SCSI miniport drivers are said to work without too many changes.
 
Search the internet for MH32BIT.EXE. It is a universal Windows 3.1x Microhouse 32-bit IDE driver that works with drives over 504MB to the Int 13h limit of 8.4GB.
I already tried that one but it hangs windows 3.1 on startup. The OnTrack one complains about the drive and refuses to run.
Windows 9x's esdi_506.pdr driver appears to be really really brain dead when it comes to detecting drives properly.
It looks like esdi_506.pdr checks CMOS location 0x12 which contains drive type info for the primary master and slave drives. If each nibble is non-zero then the appropriate drive is enabled for 32 bit access.
I did the following test to confirm this:
I disabled the drive in the BIOS so location 0x12 was zero and the Toshiba BIOS didn't detect anything, then booted into windows 95 using XTIDE Bios which resulted in MSDOS compatibility mode.
I then exited windows to MSDOS 7 only and used a CMOS editor to change CMOS location 0x12 top nibble to 0x90 which meant the master was set as drive type 9 (any non-zero value seems to work).
I then restarted windows (without rebooting) and this time the 32 bit drivers worked so they must be checking that location is non-zero for the master and slave drives.

So it looks like the only way to get 32 bit drivers in windows 95 on the primary IDE interface using XTIDE BIOS is to enable the drive in the main BIOS and then use a modified version of XTIDE which replaces any drives detected by the original BIOS (like the patch I did) rather than detecting drives as additional drives. Perhaps a configurable option could be added to XTIDE to support this mode of operation.
 
Last edited:
Mystery solved. I bet the Microhouse IDE driver for 3.1x checks location 0x12 too. As far as I can tell, both my SIIG I/O card with LBA BIOS and my Promise EIDEMAX II LBA BIOS don't update the CMOS drive type when they are controlling onboard IDE drives.

A preferred fix on the XT-IDE BIOS would just have it set the primary CMOS drive type to Type 47 if it detects a drive at primary master and CMOS location 0x12 is set to 0.
 
Last edited:
Back
Top