• Please review our updated Terms and Rules here

XTIDE Universal BIOS v2.0.0 beta testing thread

r625 is out!

For those of you with XT class machines with RAM available in the UMA - this revision gives you another configuration option so you can avoid the software compatibility problems of Lite mode without sacrificing any conventional memory. In short, XUB can now store its variables in an UMB.

BTW, I'm saying XT class because I'm assuming that most AT class machines require some kind of chipset programming to be able to write to memory in the UMA. I hope I'm wrong about this.

There's also a couple of new builds for PS/2 machines specifically. This is for the new McIDE adapters.

Finally a horrible bug fixed. Horrible as in horribly stupid. I'm still kicking myself for not finding this sooner - I should have seen it at least back when I did r621 because I fixed another very similar bug then. Apologies to anyone affected by this.
 

:-D

For those of you with XT class machines with RAM available in the UMA - this revision gives you another configuration option so you can avoid the software compatibility problems of Lite mode without sacrificing any conventional memory. In short, XUB can now store its variables in an UMB.

How much RAM does it need? If it's only a few dozen bytes or so, isn't there plenty of room in the unused areas of the BDA?
 
How much RAM does it need? If it's only a few dozen bytes or so, isn't there plenty of room in the unused areas of the BDA?
It's more than a few dozen bytes but less than 1 kiB. I don't know exactly. Lite mode uses the area at 30:0h but, as it turns out, it's not really unused.
 
I'm having issues in getting the latest versions of XUB running.
I'm getting the official builds here, tried with both ide_atl.bin and ide_386l.bin
Then I pad the file as described on this page:

Bash:
(for ((I=12288; $I<16384; I=$[$I+1])); do echo -en "\xFF"; done) > pad.bin
cat ide_atl.bin pad.bin > xtide-16k.bin
cat xtide-16k.bin xtide-16k.bin xtide-16k.bin xtide-16k.bin > xtide-64k.bin
cat xtide-64k.bin xtide-64k.bin xtide-64k.bin xtide-64k.bin > xtide-256k.bin

Since the file lengths are respectively 9222 and 10651 bytes, I adjust the 1st command accordingly.

Then I write the output file on a 256k EEPROM with a TL866 which I therefore plug into the socket of the NIC.

Upon start, XTIDE is not detected and no menu or hotkey bar are spawning.

It I do the same steps with XTIDE from 2013 which is found on Google Code, it works fine.

What's wrong with the current versions?
 
It I do the same steps with XTIDE from 2013 which is found on Google Code, it works fine.

What's wrong with the current versions?
Welcome to these forums.

See note #3 at [here]. I.e. In your situation (XUB to go into a ROM on a NIC), normally, one imports the downloaded BIN file into XTIDECFG.EXE, does any required changes, then exports a new BIN file. And by default, XTIDECFG.EXE will adjust the 8-bit checksum.
 
Thank you @modem7, In the end I was able to program the chip with the file exported with XTIDECFG.EXE in dosbox.
It took many hours of unsuccessful attempts prior to that
I see now it's all described in incipit of the project's main page, but I think it's not stressed enough. I totally skipped that part, my bad.
 
By the way, next beta will have native support for QDI Vision QD6500 and QD6580 VLB IDE controllers. Read rates were 1.9 MB/s with beta 1 and now they are nearly 7 MB/s on my 486. I'd like to know if there is need for supporting other VLB or PCI controllers as well.

Another way is to place the ROM on a network controller card (I recommend 3Com). There are also some VLB multi I/O cards with ROM socket. I have one but it requires two additional support chips so network cards are easier. Note that you cannot flash the BIOS when using NIC or I/O card (you can flash it on the XTIDE and then move the EEPROM to the NIC or you need to use external EPROM writer).

I have a 486 motherboard (PX486 P3 with OPTi 495SLC chipset and AMI BIOS [the sticker on the BIOS chips says 486DX ISA BIOS (C)1993 AB0251175]) and even though the BIOS can detect the full size of my CF card (4066 cylinders / 2,001 MB), DOS, fdisk, and Windows can only see 1024 cylinders (504 MB), so I guess my BIOS doesn't do any translation.

I was reading a thread on a different forum about that particular issue (and I already know about the drive overlay solution, such as EZ Drive, which I've used before, but I don't really like it), and someone mentioned that some cards, such as HDD controllers, have a BIOS socket, so I went looking through my old computer parts and found a Vision QD6500 VLB card with a BIOS socket and doing an internet search for the name of the card led me to this thread.

This is a big thread that will take a lot of time for me to read completely through, so I hope I'm not asking questions that have already been answered:

1. In your post from 2012 that I quoted above, you mentioned that the next beta of will have native support for QDI Vision QD6500 and QD6580 VLB IDE controllers. Now that it's 2023, was that native support ever implemented, and if so, is there anything specific I need to do in the current version of ide_386.bin to enable it?

2. My QD6500 card's BIOS socket calls for a 27C512 EPROM, which is 512 kilobits / 64 kilobytes, which is 8 times the size of the 8 KB ide_386.bin file. Normally I would just concatenate 8 copies of the .bin file to program the oversized EPROM with (doing that works for using 27256 EPROMs in place of 2764 EPROMs in one of my arcade machines), but is that the right thing to do in this case? What EPROM programming method did you use for your QD card, and what brand of EPROM did you use?

3. The two additional support chips that you mentioned; those are a 74LS244 and a 74LS138 TTL chip, right?
 
I concatenated 8 copies of the 8 KB .bin file to make it 64 KB and burned it to a 27C512 (ST brand) and I put a 74LS244 and 74LS138 in their respective sockets, and at first it didn't seem to do anything. I suspected that maybe I needed to change a jumper setting on the QD6500, so I looked online for jumper settings, and indeed, my card's jumper setting was in the BIOS disabled position. So I changed that and it worked. DOS and fdisk are now able to see the full 2 GB on my CF card and Windows 95 installed to it fine, and can also see the full 2 GB.

Is there any way to configure the Xtide BIOS to use the boot order A:, C: like you can in the motherboard's BIOS if you're not using Xtide? The way it is now, it defaults to booting to C: and only boots to A: if you press the "A" key. Also, what's the purpose of the "boot to ROM" (F8) option? I tried it and it just said "No ROM BASIC, System Halted."

By the way, I didn't get much of an increase in speed, certainly not anywhere near 7 MB/s. Using a small HDD benchmark program that was included with my DTC drivers (for the DTC 2278-E card I was using previously) called "DTCSPEED.EXE," the fastest "before" read result with the QD6500 about about 2.5 MB/s and the fastest "after" result was about 2.8 MB/s. That's not as fast as my DTC was with its drivers installed (about 3.9 MB/s), though its faster than the DTC was without drivers (about 1.3 MB/s).

Is there something I need to configure to get "nearly 7 MB/s" like aitotat got?
 
Is there any way to configure the Xtide BIOS to use the boot order A:, C: like you can in the motherboard's BIOS if you're not using Xtide? The way it is now, it defaults to booting to C: and only boots to A: if you press the "A" key.
I found the setting to change the boot order so changed it and burned a new EPROM and that's fixed.

A different problem has arose though. I have a CD drive attached as a slave on my primary (and only) IDE channel. On the startup screen it always says:

Master at 1F0h: SILICONSYSTEMS INC 2GB
Slave at 1F0h: not found

Sometimes it spends 10 or 15 seconds trying to detect the slave, and when it does that, even though it says "not found," both DOS and Windows can see my CD drive so it's not a problem. But other times it just instantly says "not found," and in that case, neither DOS nor Windows can see my CD drive.
 
Lots of info at https://xtideuniversalbios.org/
what's the purpose of the "boot to ROM" (F8) option?
F8 calls software interrupt 18h. This starts IBM ROM Basic, ROM DOS or displays an error message from the motherboard BIOS when there is no ROM to boot from.
Sometimes it spends 10 or 15 seconds trying to detect the slave
You can disable Slave detection in the XUB, Primary IDE Controller / Slave Drive and set disable detection to YES
Disable Detection [default=No]
This menu option is only available for slave drives. Setting this to Yes allows the BIOS to skip detection of this drive and the computer will boot slightly faster as a result. You will probably want to do this for IDE controllers that don't support slave drives at all.
 
You can disable Slave detection in the XUB, Primary IDE Controller / Slave Drive and set disable detection to YES
Won't that make it so DOS and Windows can't see my slave CD drive though, like it has sometimes done already even with detection enabled? I need the slave drive to work.

Also, do you know why I only got slightly higher speed with the QD6500 card rather than ~7 MB/s like aitotat got in 2012?
 
Won't that make it so DOS and Windows can't see my slave CD drive though, like it has sometimes done already even with detection enabled? I need the slave drive to work.
The XUB has no support for CD-ROM, Try it and see, Sometimes mixing drives on the same cable just doesn't work eg: Master = CF adapter + CF Card, Slave = CD-ROM or Spinning HD or SD adapter + SD card.
Also, do you know why I only got slightly higher speed with the QD6500 card rather than ~7 MB/s like aitotat got in 2012?
Dunno, Maybe because of CF and CD-ROM on same cable ??, Have you tried it with just CF attached.
 
The XUB has no support for CD-ROM, Try it and see, Sometimes mixing drives on the same cable just doesn't work eg: Master = CF adapter + CF Card, Slave = CD-ROM or Spinning HD or SD adapter + SD card.

I burned another EPROM with slave detection disabled. It does make it boot faster and the CD drive still shows up in Windows (for now) and works fine, so that's awesome if it stays working like that.

Dunno, Maybe because of CF and CD-ROM on same cable ??, Have you tried it with just CF attached.

I just did the HDD benchmark on it both with and without the CD drive plugged into the IDE cable, and the results were pretty much identical; it was actually ever so slightly faster with the CD drive plugged in, but that's just due to normal variance. So whatever the reason is that I'm not getting ~7 MB/s, it's not due to the CD drive.
 
CF cards almost never support multi sector transfers. VLB IDE cards usually rely on multi sector transfers for good performance. Try a mechanical HDD
 
CF cards almost never support multi sector transfers. VLB IDE cards usually rely on multi sector transfers for good performance. Try a mechanical HDD

I might try that, but keep in mind that, like I mentioned in post #710, my DTC 2278-E VLB card with its drivers installed was significantly faster than this QD6500 + Xtide BIOS (3.9 MB/s vs. 2.8 MB/s), using the same CF card. So if the CF card is a bottleneck preventing ~7 MB/s with the QD6500 + Xtide BIOS, it should still be at least as fast as the DTC + drivers was.
 
I did the HDD read test with a mechanical HDD (IBM 4.2 GB, made in 1997, a few years newer than my PC's hardware) and it was a little slower than the CF card (~2.4 MB/s vs. ~2.8 MB/s for the CF card). I also did a different benchmark which included a seek time test and the HDD was way slower than the CF card in that test.

CF card:

Average seek time = 0.16 ms
Track to track seek time = 0.11 ms

Mechanical HDD:

Average seek time = 8.29 ms
Track to track seek time = 3.44 ms
 
Back
Top