• Please review our updated Terms and Rules here

XTIDE Universal BIOS v2.0.0 beta testing thread

the missing checksum was a problem for me as I mentioned before. It is not obvious that its needed from reading over the site page. Why not just build them with the checksum?
otherwise there should be something in bold that states the roms will not work without it and they need to either be built again using the makefile checksum option or using XTIDECFG in dosbox or with a idext card.
 
maxtherabbit said:
I agree with glitch's response. Additionally, the sign on text of the XUB could very easily point the user in the right direction regarding why it's not working properly, whereas nothing at all is extremely ambiguous.
Click to expand...

The system BIOS won't initialize an option ROM BIOS such as the XUB if the checksum is incorrect (the checksum byte is "missing"). So that's why you don't get to see the sign on text or anything at all XUB-related. Anyway, the issue of checksum byte or no checksum byte is actually a moot point. The take away from the post I linked to is that everyone must configure the BIOS for their machine anyway and the problem at its core is that people are too lazy or too stupid to read up on the subject.
 
Krille said:
The system BIOS won't initialize an option ROM BIOS such as the XUB if the checksum is incorrect (the checksum byte is "missing"). So that's why you don't get to see the sign on text or anything at all XUB-related.
Click to expand...
I know that, you clearly didn't understand my point.

Krille said:
Anyway, the issue of checksum byte or no checksum byte is actually a moot point. The take away from the post I linked to is that everyone must configure the BIOS for their machine anyway and the problem at its core is that people are too lazy or too stupid to read up on the subject.
Click to expand...
And the take away from my post was that getting a sign-on message that says port 300h or whatever when you're using 16-bit IDE is a good clue that you need to configure something. Getting nothing at all is not.
 
Maybe we can suggest a best of both worlds? Default images have a config flag set so the bios displays a "not configured" message, then continues the boot process without doing anything. Images would have a valid checksum so the message appears at boot up, but nothing actually happens to risk locking up the machine and prevent it from booting.

As the project has matured and the userbase grown, the knowledge level of the common/least skilled user has dropped significantly to the point that this is almost a retail product.

Some allowances may be needed now for users where 5 years ago everyone involved would know things. EEPROM flashing on board was for convenience, but it took away the entry requirement of owning certain equipment, as an example.
 
Last edited:
srm said:
thats exactly the case.
on the webpage it is explicitly stated that i need to fill up the image with zeros, which i did.
Click to expand...
Reading that now I realize that sentence is incorrect. What matters is that the blocks occupied by the BIOS (as defined by the block count in the third byte of the BIOS) matches the checksum. The rest of the ROM could just as well be filled with junk and it shouldn't matter.

It is not stated anywhere on the official site, that its necessary to run xtidecfg before being able to build this.
Maybe this has been mentioned before, but no one is looking up 60 pages in the forum before downloading and installing it.
Click to expand...
It's obvious that you're supposed to use XTIDECFG since a large part of the front page describes the use of the configurator and all of its options. Another hint is that there's a file called XTIDECFG.COM together with the BIOS binaries in the download section.

Have you ever installed a DOS game? Then there's a good chance that you had to run some kind of setup program to configure the sound etc. This is not that different in my opinion.

All this being said, I know the official site and documentation is far from perfect. However, it is possible to register as a user on the site and make improvements if one so wishes - it is a wiki after all.

maxtherabbit said:
And the take away from my post was that getting a sign-on message that says port 300h or whatever when you're using 16-bit IDE is a good clue that you need to configure something. Getting nothing at all is not.
Click to expand...

I don't know what you mean by "Getting nothing at all". In that scenario you'll get this;
Code: 
Master at 300h: not found
Slave  at 300h: not found
 
TheDrip said:
Maybe we can suggest a best of both worlds? Default images have a config flag set so the bios displays a "not configured" message, then continues the boot process without doing anything. Images would have a valid checksum so the message appears at boot up, but nothing actually happens to risk locking up the machine and prevent it from booting.

As the project has matured and the userbase grown, the knowledge level of the common/least skilled user has dropped significantly to the point that this is almost a retail product.

Some allowances may be needed now for users where 5 years ago everyone involved would know things. EEPROM flashing on board was for convenience, but it took away the entry requirement of owning certain equipment, as an example.
Click to expand...

I like the way you put it :)

A notice on the " Pre Built Binaries " download pages should suffice, Something along the lines of " All binaries MUST be properly configured using the XTIDECFG.COM configuration tool FIRST before flashing / Burning to Eprom / EEprom ".

Probably easier to implement rather than adding more code to the binaries. Checksumming non-configured binaries is pointless IMO.
 
Krille said:
I don't know what you mean by "Getting nothing at all". In that scenario you'll get this;
Code: 
Master at 300h: not found
Slave  at 300h: not found
Click to expand...
Right and when I see that I'm going to think to myself: "why is it looking at port 300h when my drives are at 170h... hmm maybe I need to change a setting." Versus no sign on which could mean bad flash, bad hardware, anything at all really.

Additionally what about the scenario where you do use the configuration tool, open up the binary, see it's already configured properly for your use case, and then don't bother to save it? It needs to be made explicit in the docs that the config tool is responsible for checksumming the binary, especially since the older official releases were pre checksummed which adds even more confusion if you are upgrading
 
Is there a way to download the entire full source? There's a link at the bottom of the page for downloading only the changes, but I'd like to grab the full source.
 
Trixter said:
Is there a way to download the entire full source? There's a link at the bottom of the page for downloading only the changes, but I'd like to grab the full source.
Click to expand...

Yes of course. Point your subversion client to http://www.xtideuniversalbios.org/svn/xtideuniversalbios/trunk and then do a checkout. If you don't have a client then I'd recommend using TortoiseSVN (assuming you're using Windows). The instructions at https://code.google.com/archive/p/xtideuniversalbios/wikis/BuildInstructions.wiki might also be useful even though that page is a bit outdated.
 
I would like to add detection of ATAPI devices at some point just to show that the device is detected at boot. Anything more than that is going to take serious effort because it would require El Torito and/or ARMD support.
 
XUB r606 is out!

Thank you Montecarlo4tony for reporting the problems with 32-bit disk access drivers under Windows 3.x! RESERVE_DIAGNOSTIC_CYLINDER is now completely removed so your patch should not be needed anymore. Thank you Pickle for providing the BIOSDRVS output that lead to the discovery of the CHS translation bug!

Please note that this revision involves changing the CHS translation for some drives - affected drives must be repartitioned and reformatted after upgrading to this revision of XUB! See the link for more info!
 
Native support for QDI Vision QD6500 and QD6580 VLB IDE controllers
Click to expand...

1) Does it mean that is not necessary to change 32bit device type (as default is 16b) ?
2) I tested it with other VLB cards (not QD, not promise) and works. Does it mean that the best performance is with QD6580 card?
 
Upgraded my V20 XT clone, V30/8086 IBM and 286 IBM, no issues except for forgetting that I run the XTP image on the 286 instead of the AT image because I have an xt-lite card in there. Not ideal for speed I know.
 
mt777 said:
1) Does it mean that is not necessary to change 32bit device type (as default is 16b) ?
2) I tested it with other VLB cards (not QD, not promise) and works. Does it mean that the best performance is with QD6580 card?
Click to expand...

1. Yes.
2. Other VLB cards will still work as regular ISA 16-bit IDE controllers with no performance improvement. So yes, you will get the best performance with a QD6580 card.

TheDrip said:
Upgraded my V20 XT clone, V30/8086 IBM and 286 IBM, no issues except for forgetting that I run the XTP image on the 286 instead of the AT image because I have an xt-lite card in there. Not ideal for speed I know.
Click to expand...

XTP vs AT images shouldn't matter regarding performance. Or were you referring to running an 8-bit controller in a machine with 16-bit bus?
 
You must log in or register to reply here.
Back
Top