XTIDE Universal BIOS

[maferv]

Thanks for posting this! I always find benchmarks interesting, especially since I'm not able to test and benchmark as much as I'd like to do myself.

A lot of people assume that the processor specific builds were created to improve performance for those types of CPU:s. For the most part, that's not true. Most of the time the higher level CPU instructions are just used to optimize for size so that we can save ROM space which allows us to pack more functionality into the BIOS. The biggest exception to this rule is the string I/O instructions available from the V20/V30/188/186 CPU:s which makes a huge difference when doing port I/O.

Is "Enable interrupt" set to Yes for the IDE controller in the 386L build? It is set to Yes by default, so if you haven't changed that you will get lower performance in DOS because polling is faster than using interrupts in a single tasking OS like DOS. The XTPL build on the other hand is always using polling as it doesn't even have MODULE_IRQ included.

You're welcome! I'd gladly do more tests if you give me more instructions.

You were right about disabling the "Enable interrupt" option. Now the performance is almost the same as the XTPL rom. There's only a very minor difference that I'll highlight in the following chart:

XTIDE​	r624​	​	​
​	​	​	​
XTPL​	​	​	​
DRAM 2 W.S.​	AT CLK 40/4​	3170.4 K/s​	0.2 ms, 0.2 ms​
DRAM 0 W.S.​	AT CLK 40/4​	3263.7 K/s​	0.1 ms, 0.1 ms​
DRAM 2 W.S.​	AT CLK 40/3​	3698.9 K/s​	0.2 ms, 0.2 ms​
DRAM 0 W.S.​	AT CLK 40/3​	3698.9 K/s​	0.1 ms, 0.1 ms​
386L No interrupt​	​	​	​
DRAM 2 W.S.​	AT CLK 40/4​	3170.4 K/s​	0.2 ms, 0.2 ms​
DRAM 0 W.S.​	AT CLK 40/4​	3263.7 K/s​	0.1 ms, 0.1 ms​
DRAM 2 W.S.​	AT CLK 40/3​	3608.6 K/s​	0.2 ms, 0.2 ms​
DRAM 0 W.S.​	AT CLK 40/3​	3698.9 K/s​	0.1 ms, 0.1 ms​

One further clarification about my tests: I'm always "shadowing" the XTIDE rom to ram.

Is "Enable interrupt" set to Yes for the IDE controller in the 386L build? It is set to Yes by default, so if you haven't changed that you will get lower performance in DOS because polling is faster than using interrupts in a single tasking OS like DOS. The XTPL build on the other hand is always using polling as it doesn't even have MODULE_IRQ included.

So would Windows 95 run better with the 386L with the Interrupt enabled or would the XTPL still be faster? Would you please elaborate more on this? I could try this on a 386 and on a 486 to see if there's any difference but I have never loaded Windows using XTIDE. Are there any incompatibilities with Windows 9x?

Another quick question, is 128GB the size limit for a hard drive with XTIDE?

Cheers!

 

[Krille]

You're welcome! I'd gladly do more tests if you give me more instructions.

I would recommend making a custom build if you want to maximize the performance. Only including the required modules will make the BIOS a bit smaller so there's a chance more of the code will fit in whatever cache you've got in the machine. I'm not sure how much of a difference that would make but that's one thing that would be interesting to know.

You were right about disabling the "Enable interrupt" option. Now the performance is almost the same as the XTPL rom. There's only a very minor difference that I'll highlight in the following chart:

Was this difference consistent over several runs? If so, I don't know what the cause is. If it was just a single benchmark then I guess it might be the difference of a single timer tick.

One further clarification about my tests: I'm always "shadowing" the XTIDE rom to ram.

So would Windows 95 run better with the 386L with the Interrupt enabled or would the XTPL still be faster? Would you please elaborate more on this? I could try this on a 386 and on a 486 to see if there's any difference but I have never loaded Windows using XTIDE.

I honestly don't know. I've never tried it either.

Are there any incompatibilities with Windows 9x?

As far as I know, none other than the ones mentioned in the documentation.

Another quick question, is 128GB the size limit for a hard drive with XTIDE?

With MODULE_EBIOS the BIOS supports 48-bit LBA so that's 2^48 sectors, or put another way, 281474976710656 sectors. That's 128 petabytes. Without MODULE_EBIOS the drive size limit is just over 8 gigabytes.

 

[jskyboo]

Hello, first off thank you so much for this amazing project and all the hard work. I was quite excited to see the new revision 625 this week and even more excited when I saw the new "Use UMB for variables" option. Unfortunately I can't seem to get it to work. If I use the same configuration as with 624 everything works fine as always but if I try to set an address for the UMB it always fails to boot. Sometimes it stops while probing the first drive and sometimes it fails to find any devices and then hangs after the menu. On my system I have empty space between DB00-F7FF so I thought I could use basically any 1k in that range but even when I tried E000 what I thought would be the safest location it still won't boot. I also tried both ide_386.bin and ide_386l.bin in case that made a difference but both failed. If it matters I am using this on a 486 system and have XUB loading from a qd6580 card. Is this option meant to work for 386 and up class systems?

 

[Krille]

@jskyboo

Thanks for the feedback and welcome to the forum! As I wrote in the other thread and in the commit message, this is primarily for XT class machines. For this to work, you need to have some kind of RAM available and writable in the Upper Memory Area without any prerequisite chipset programming. I imagine that most AT class machines won't have that, but then again, I don't know everything about every hardware combination out there. So bottom line is; I don't know!

BTW, (for anyone else trying this) I would recommend using DEBUG to check if RAM is writable before doing the reconfigure and flash procedure with XTIDECFG. Assuming you do know how to use DEBUG of course, I realise that not everyone does.

 

[jskyboo]

@jskyboo

Thanks for the feedback and welcome to the forum! As I wrote in the other thread and in the commit message, this is primarily for XT class machines. For this to work, you need to have some kind of RAM available and writable in the Upper Memory Area without any prerequisite chipset programming. I imagine that most AT class machines won't have that, but then again, I don't know everything about every hardware combination out there. So bottom line is; I don't know!

BTW, (for anyone else trying this) I would recommend using DEBUG to check if RAM is writable before doing the reconfigure and flash procedure with XTIDECFG. Assuming you do know how to use DEBUG of course, I realise that not everyone does.

I figured that might be the issue, thank you for confirming. If I could move the variables and recover that 2k hole in conventional memory I would be so happy. I wonder if a helper driver could be used later at boot time for other hardware classes.

Probably not much help for me but for others that want to check before giving it a try and don't already know how to use DEBUG, how would they check if the RAM is writable with DEBUG?

 

[Krille]

I figured that might be the issue, thank you for confirming. If I could move the variables and recover that 2k hole in conventional memory I would be so happy. I wonder if a helper driver could be used later at boot time for other hardware classes.

Was that a typo or do you really have a 2 kiB hole? XUB only requires 1 kiB so you must have something else using memory in that case (could be a virus for example).

Probably not much help for me but for others that want to check before giving it a try and don't already know how to use DEBUG, how would they check if the RAM is writable with DEBUG?

Use the Dump and Enter commands. Let's say you want to check if segment D000h can be used as an UMB.
You would then use the Dump command by typing;

D D000:0 L1

This will display the first byte in segment D000h. Let's say the value is FF. Then use the Enter command to change that byte to some other value (in this case 0);

E D000:0 0

Use the same Dump command again and if it's now changed then you know it is writable. BTW, all this must be done without any memory managers such as EMM386 loaded.

 

[jskyboo]

Was that a typo or do you really have a 2 kiB hole? XUB only requires 1 kiB so you must have something else using memory in that case (could be a virus for example).

No that wasn't a typo I mean a 2k hole. I too thought it was a virus when I first noticed it but I ran MSAV and F-Prot with latest definitions and they found nothing. I've come to learn it seems to be the combination of 1k from XUB and 1k for an Extended BIOS Data Area for my ps2 mouse. When I use the Win 98 Boot Floppy I still have a 2k hole. If I remove the XUB ROM and use a smaller boot drive it gets the full 640 conventional. As I understand it XUB gets loaded right next to the XBDA and whatever is responsible for moving the XBDA (Win/the memory manager??) if it finds the XBDA to be larger than 1k it doesn't move it. Also if I unplug my mouse then the hole is only the 1k from XUB it seems to not mistake just the XUB as an XBDA and try to move it.

I tried the DEBUG lines for E000 and yep looks like my RAM does not seem to be writable.

 

[FreddyV]

Hi there.

I have a question for XTIDE Specialist.

I am working on my Pi Pico based memory and Disk board (For XT Computers)
I did implement a BIOS in this board and even if it is located After the XTIDE Bios, it seems that XTIDE Start After my Board BIOS.
Then, I suppose that the XTIDE BIOS int9h (Disk Boot) is not only used to Boot, but to initialize completely the XTIDE. Am I right ?

A Problem with XTIDE is that as it start all the time after my BIOS, it is not possible to boot anymore on an Disk "Controlled" by XTIDE and have a disk emulated by my board at the same time.
My Board will map the disk to 80h, and XTIDE add its disk just after.

For info, my board will be able to load ROM Images, so the XTIDE BIOS can also be included as a .bin file on the MicroSD, this may simplify the XTIDE BIOS Test

 

[modem7]

I did implement a BIOS in this board and even if it is located After the XTIDE Bios, it seems that XTIDE Start After my Board BIOS.
Then, I suppose that the XTIDE BIOS int9h (Disk Boot) is not only used to Boot, but to initialize completely the XTIDE. Am I right ?

See the first paragraph of post #15 at [here]. I think there is a 'late initization' configuration item in the XUB that can be changed.

 

[FreddyV]

See the first paragraph of post #15 at [here]. I think there is a 'late initization' configuration item in the XUB that can be changed.

Thanks, so it confirm what I did think.

 

[modem7]

A Problem with XTIDE is that as it start all the time after my BIOS, it is not possible to boot anymore on an Disk "Controlled" by XTIDE and have a disk emulated by my board at the same time.
My Board will map the disk to 80h, and XTIDE add its disk just after.

So, your board will be 80h, and the XT-IDE's drive be 81h.
The XTIDE Universal BIOS (XUB) on the XT-IDE will by default attempt to boot from 80h.

I see two possible answers:

1. Reconfigure the XUB, changing the boot drive from 80 to 81; or

2. When the XUB's hotkeybar menu appears, press the D key. The XUB will swap 80 and 81, then boot from 80, which is now the XT-IDE's drive. In DOS, XT-IDE's drive (partition actually) will appear as logical drive C:, and your drive (partition actually) will appear as logical drive D:

The situation is similar to that described in the 'IBM 5170 (IBM AT) example #2 of 2' section of [here].

 

[Yoghoo]

Today I burned and installed the XTIDE Universal BIOS on a 3Com 3C509B-COMBO network card using the IDE_386.BIN pre-built binary. This is on a 386DX PC with a Miata PCB-306 motherboard.

It works perfectly but there is one annoying problem that it restarts the harddisk (a 20 Gb Fujitsu MPF3204AT) 3 times during a warm or cold reboot. You can clearly hear the hard disk stops and starts very briefly 3 times. First time probably during the discovery by XTIDE and then a second time soon after but before the OS starts. The last time is when Qemm starts. This is during running DEVICE=C:\QEMM\DOSDATA.SYS.

Without XTIDE this problem does not occur. I used the default options with xtidecfg.com as well as the default address inside the network card configuration utility (which was not in use).

Anybody knows why it does that and how to avoid it? If more information is needed let me know.

 

[maxtherabbit]

Today I burned and installed the XTIDE Universal BIOS on a 3Com 3C509B-COMBO network card using the IDE_386.BIN pre-built binary. This is on a 386DX PC with a Miata PCB-306 motherboard.

It works perfectly but there is one annoying problem that it restarts the harddisk (a 20 Gb Fujitsu MPF3204AT) 3 times during a warm or cold reboot. You can clearly hear the hard disk stops and starts very briefly 3 times. First time probably during the discovery by XTIDE and then a second time soon after but before the OS starts. The last time is when Qemm starts. This is during running DEVICE=C:\QEMM\DOSDATA.SYS.

Without XTIDE this problem does not occur. I used the default options with xtidecfg.com as well as the default address inside the network card configuration utility (which was not in use).

Anybody knows why it does that and how to avoid it? If more information is needed let me know.

both my XUB machines do this as well, the hdd clunks like 3 times both at initial boot and also when shutting down windows

 

[Yoghoo]

If I look at the source code it seems it does multiple resets of controller and drives. So this is probably the cause. What I don't understand why they are not combined or why they are even necessary. To me it now seems XUB is more meant for CF cards and not for physical hard drives. To be honest I am a bit worried about he amount of restarts it does and the impact that it could have on those (older) harddisks.

Do the devs frequent these forums or should I mail them? They don't use github/gitlab or so so it's not easy to see if this is a known issue.

 

[Krille]

@Yoghoo @maxtherabbit
I think it might have something to do with the COMMAND_STAND_BY added in r615 since this appears to be a fairly recent problem. Or this has been a problem for a long time but no one is using actual hard drives anymore so it has not been reported before. BTW, I seem to recall a thread over at vogons where someone reported similar problems but he also mentioned a lot of other problems that ended up being caused by the IDE interface used or something like that (IIRC).

Anyway, try a custom build without MODULE_POWER_MANAGEMENT. I'll try to find the time to investigate this problem but it will probably take a while.

 

[maxtherabbit]

@Yoghoo @maxtherabbit
I think it might have something to do with the COMMAND_STAND_BY added in r615 since this appears to be a fairly recent problem. Or this has been a problem for a long time but no one is using actual hard drives anymore so it has not been reported before. BTW, I seem to recall a thread over at vogons where someone reported similar problems but he also mentioned a lot of other problems that ended up being caused by the IDE interface used or something like that (IIRC).

Anyway, try a custom build without MODULE_POWER_MANAGEMENT. I'll try to find the time to investigate this problem but it will probably take a while.

I can't say for certain but I'm fairly sure it was happening prior to r615. I've just been ignoring it for a long time

 

[maxtherabbit]

Just went back and checked my records, I can confirm that this has been happening for me at least as far back as r602

 

[Yoghoo]

Just went back and checked my records, I can confirm that this has been happening for me at least as far back as r602

Thanks for checking. Just compiled a custom build without MODULE_POWER_MANAGEMENT but it's of no use then.

Will probably try tomorrow one without MODULE_SERIAL* and MODULE_WIN9X_CMOS_HACK as I don't need them anyway and got MODULE_WIN9X_CMOS_HACK enabled atm. Can the MODULE_IRQ module be the cause @Krille. If so I can try to remove that as well.

 

[Krille]

@maxtherabbit @Yoghoo
Is the power management idle timeout value set to something or is it disabled? Do you know if this problem affects all hard drives or just some models?

 

[Yoghoo]

@maxtherabbit @Yoghoo
Is the power management idle timeout value set to something or is it disabled? Do you know if this problem affects all hard drives or just some models?

@Krille Power management is disabled. Tested it with another hard drive in the same PC. With this smaller hard disk (a Quantum Fireball 640 (640Mb)) I didn't get the delay and I couldn't hear any stop/start sounds from this one. So it seems it's hard disk related?