XTIDE Universal BIOS v2.0.0 beta testing thread

[MaximRecoil]

@MaximRecoil: To maximize performance, make sure ROM shadowing and caching is enabled for the XUB ROM segment.

According to the QD6500 manual, the BIOS address jumper position I used is C800h, so I enabled "Adaptor ROM Shadow C800,16K" in the motherboard's BIOS. It didn't make a difference in the HDD speed tests.

 

[Krille]

I see. Well, if the HDD is the bottleneck it won't make much difference to enable ROM shadowing.

BTW, have you tried using the drivers to see what performance you get with those? That would be the most fair comparison in my opinion.

Also, what kind of CPU do you have in that machine? I believe Aitotat was using a 100 MHz 486 CPU in his testing.

 

[MaximRecoil]

I see. Well, if the HDD is the bottleneck it won't make much difference to enable ROM shadowing.

The HDD isn't the bottleneck. Like I mentioned previously, I got 3.9 MB/s with the DTC card + drivers and the same CF card, which is about 1.1 MB/s faster than I'm getting with the QD6500 + XUB. I can't use the DTC card with XUB because it doesn't have a BIOS socket. Also, the DTC card had other problems. For example, it couldn't successfully install the drivers when using EZ Drive HDD overlay software, so if I wanted the speed that came along with using the drivers, I was limited to 504 MB of my 2 GB CF card. There were other problems with it too, which is why I decided to use the QD6500 + XUB.

BTW, have you tried using the drivers to see what performance you get with those? That would be the most fair comparison in my opinion.

No. I couldn't find any Windows 95 drivers for the QD6500; just DOS and Windows 3.1.

Also, what kind of CPU do you have in that machine? I believe Aitotat was using a 100 MHz 486 CPU in his testing.

AMD Am486DX2-66 (66 MHz).

 

[led178]

No. I couldn't find any Windows 95 drivers for the QD6500; just DOS and Windows 3.1.

Does it bother you to check under DOS HDDSPEED 2.1?
QD6580 gives up to 11.5mb/s with driver.

 

[DrJohnnyFever]

With a QD6580 and XTIDEUB I get about 4MB/s and the 6500 I get around 3.1 MB/s on my 486. Actually a little disappointed. Using an Appian ADI/2 VLB card and the latest Adaptec driver I could find using the same drive I get 5.8MB/s

 

[Krille]

With a QD6580 and XTIDEUB I get about 4MB/s and the 6500 I get around 3.1 MB/s on my 486. Actually a little disappointed.

Have you tried the driver? If so, what kind of speed did you get with that?

Do you have shadowing enabled for the memory range used by the XUB ROM?

 

[DrJohnnyFever]

Have you tried the driver? If so, what kind of speed did you get with that?

Do you have shadowing enabled for the memory range used by the XUB ROM?

I have used the driver, I get only slightly better speed (something like 0.2 MB/s). I could get exact numbers if you want me to test again.

I tried shadowing and it made no noticeable difference oddly.

 

[pearce_jj]

Just to note that the stability issues with the site (xtideuniversalbios.org) have now been fixed.

 

[modem7]

I see that XUB R628 was released in June. When I look in file ide_xt.bin, I see:

 

[Malc]

I see that XUB R628 was released in June. When I look in file ide_xt.bin, I see:

Yes i noticed that, A tad confusing but looking at the 'Changesets' i see there has been NO change in code, So essentially R628 is the same as R625 code wise.

I see: In R626 The old 1x configurator was removed for some reason.
I see: In R627 The old 1x configurator was put back again.
I see: In R628 There was a new 'copyrights' text file added
In each new revision there was no code changes made

Over the years any minor update which resulted in no changes to the code had the Revision # bumped up, Maybe this has changed now ?

 

[modem7]

Over the years any minor update which resulted in no changes to the code had the Revision # bumped up, Maybe this has changed now ?

I hope not. It causes confusion.

 

[Malc]

I hope not. It causes confusion.

While i understand it can cause confusion it actually makes sense to me not to change the Revision # of the XUB binary IF NO changes have been made to the code. It's easy enough to check the 'Changeset' to see what has changed, If no code changes have been made then i see no point in 'upgrading'.

In the code for the XUB i see: ' BIOS version string (supports up to r999) ', What happens when the Revision # hits R999 and over ?, I dunno, That is, if it ever does of course, I dunno how it works server side either, I assume server side it doesn't have that restraint and can go past r999.

Hopefully @Krille can enlighten us

 

[Malc]

In the code for the XUB i see: ' BIOS version string (supports up to r999) ', What happens when the Revision # hits R999 and over ?, I dunno,

Answering my own question I just did a custom build and raising the revision # to 999 the BIOS builds perfectly.
Raising the revision # to 1000 the BIOS failed to build with errors.

 

[modem7]

While i understand it can cause confusion it actually makes sense to me not to change the Revision # of the XUB binary IF NO changes have been made to the code. It's easy enough to check the 'Changeset' to see what has changed, If no code changes have been made then i see no point in 'upgrading'.

The date string in the binary got unnecessarily changed, but that is nitpicking.

Plenty of software has a release/package version, the release/package containing components of differing versions. E.g. Apple suite 4.2 contains Grumble version 7.6.0 plus Tiger version 1.3.0
That makes sense to me.
Make a modification of any kind to the contents, and the release/package version changes.
When dealing with the client, you may ask, "What version of the Apple suite do you have?" or "What version of Grumble do you have?", etc.

But where we are now with XUB, is: XUB package release R628 contains XUB binary release R625, plus xxx, plus yyyy. It is not user-friendly.

In my opinion, the simple act of reflecting the XUB package release version in the version of the XUB binary (irrespective of whether the binary changed or not) stops the subject confusion.

 

[pearce_jj]

This is a result of the server migration - I didn't realise that the displayed release number was hard-coded in Revision.inc.

This should now be sorted (everything should now say r629) - my apologies to the XTIDE Team for the unnecessary releases and the user-base for the confusion..