• Please review our updated Terms and Rules here

XTIDE Universal BIOS

Not going to argue that it's a "user friendly" convention, but I took a look at the XTIDE docs and it does explicitly say when they use an address like "D000" they mean "Segment Address", and this is a product aimed at a technical audience. If you know the memory map of the PC you know that D000, aka, the 52k mark, isn't where an option ROM would go. RAM's on the bottom, after all.
 
Adding this simple case example to https://xtideuniversalbios.org/ might help others; if you don't care to, no problem. I've resolved my issue, added some feedback, and hope this post and the linked Vogons post might help others who run into the same issue with this convention.
 
Krille Ive updated to v617 and only thing i did was use the cfg tool to calculate the checksum. Everything seems to work as it did before, except one thing the EBIOS section isnt reporting.
I was also trying to get grub4dos to load the boot menu between these 2 drivers. I followed a process i used on another machine (although newer) and it also give an error about no EBIOS.
I thought i saw there is a compile option for EBIOS, would this be in the normal 8 kb 386 build?

These are identical 256 MB CF cards, but are different brand from what i posted before.
BIOS Drive Information Tool v1.0.3
(C) 2012-2021 by XTIDE Universal BIOS Team
Released under GNU GPL v2
http://xtideuniversalbios.org/

-= Drive 80h =-
ATA-information from AH=25h...
Name : Delkin Devices CFX256E2G1-DABEG00
Cylinders : 980 , Heads: 16 , Sectors: 32

Will be modified to:
Cylinders : 980 , Heads: 16 , Sectors: 32

CHS sectors: 501760
LBA28 sectors: 501760
Block mode : Set to 1 from max 1 sectors
PIO mode : Max 4, Min cycle times: 120 ns, with IORDY 120 ns
XTIDE Universal BIOS v2.0.0á3+ (2021-08-10) generates following L-CHS...
Cylinders : 980 , Heads: 16 , Sectors: 32 , Mode: NORMAL
Old INT 13h information from AH=08h and AH=15h...
Cylinders : 980 , Heads: 16 , Sectors: 32

Total sectors: 501760
EBIOS information from AH=48h...
BIOS returned error code 1h

Press any key to display next drive.

-= Drive 81h =-
ATA-information from AH=25h...
Name : Delkin Devices CFX256E2G1-DABEG00
Cylinders : 980 , Heads: 16 , Sectors: 32

Will be modified to:
Cylinders : 980 , Heads: 16 , Sectors: 32

CHS sectors: 501760
LBA28 sectors: 501760
Block mode : Set to 1 from max 1 sectors
PIO mode : Max 4, Min cycle times: 120 ns, with IORDY 120 ns
XTIDE Universal BIOS v2.0.0á3+ (2021-08-10) generates following L-CHS...
Cylinders : 980 , Heads: 16 , Sectors: 32 , Mode: NORMAL
Old INT 13h information from AH=08h and AH=15h...
Cylinders : 980 , Heads: 16 , Sectors: 32

Total sectors: 501760
EBIOS information from AH=48h...
BIOS returned error code 1h
Click to expand...
 
This is probably an out-there question, and I apologize if it has an answer that my Google-Fu has just utterly failed me at:

Is there any method for building from the XTIDE sources a binary that uses one of the configurable device types (I’m specifically most interested in 8-bit XT-CF) that instead of being a BIOS extension is a driver loadable from config.sys after booting from some other device? (Floppy or whatever.)

Reason I’m asking is I’m looking at trying to build some kind of mass storage for an extremely proprietary machine (IBM Convertible). There are some barriers to interfacing directly with the full expansion bus of the machine (the fact that matching connectors are apparently complete unobtanium is a very significant one) but I came up with a possible workaround for the I/O portion which involves targeting the internal modem header. This connector looks like it has all the signals necessary for an XT-CF port, but it can’t host a ROM. A config.sys loadable driver would thus be really useful to prove out the idea.

(This could potentially be useful for other ancient laptops/etc. that have similar I/O limitations.)
 
Eudimorphodon said:
....Is there any method for building from the XTIDE sources a binary that uses one of the configurable device types (I’m specifically most interested in 8-bit XT-CF) that instead of being a BIOS extension is a driver loadable from config.sys after booting from some other device? (Floppy or whatever.)
Click to expand...

Nope not that i know of

Reason I’m asking is I’m looking at trying to build some kind of mass storage for an extremely proprietary machine (IBM Convertible). There are some barriers to interfacing directly with the full expansion bus of the machine (the fact that matching connectors are apparently complete unobtanium is a very significant one) but I came up with a possible workaround for the I/O portion which involves targeting the internal modem header. This connector looks like it has all the signals necessary for an XT-CF port, but it can’t host a ROM. A config.sys loadable driver would thus be really useful to prove out the idea.

(This could potentially be useful for other ancient laptops/etc. that have similar I/O limitations.)
Click to expand...

Don't know about a loadable driver via Config.sys, But have a read of This thread,https://www.vcfed.org/forum/forum/co...tead-of-EPROM= Booting from floppy should be possible, IIRC the code needs work but i did get it working on an old dell laptop back then.
 
Thanks for the link. It looks like it’s kind of a hit and miss method but I can take a shot at it. Should be able to just yank/blank the flash chip on one of my existing XT-CFs to prototype it.
 
You'll need to work on the code, I remember i only got it working using 1.4M floppy disk's and only on a system with a HD floppy controller, It didn't work on my XT with stock controller and 720k disk, I can't see why it shouldn't be made to work though, But i'm no coder :-(
 
Pickle said:
Krille Ive updated to v617 and only thing i did was use the cfg tool to calculate the checksum. Everything seems to work as it did before, except one thing the EBIOS section isnt reporting.
I was also trying to get grub4dos to load the boot menu between these 2 drivers. I followed a process i used on another machine (although newer) and it also give an error about no EBIOS.
I thought i saw there is a compile option for EBIOS, would this be in the normal 8 kb 386 build?

These are identical 256 MB CF cards, but are different brand from what i posted before.
Click to expand...

MODULE_EBIOS is included in all the official BIOS builds except for the Tiny build. The drives you are using are small enough to be running in NORMAL mode, meaning they are using CHS addressing. This is why BIOSDRVS reports error 1 - EBIOS functions are not allowed on drives using CHS addressing. If you really need to get EBIOS support for these drives to get grub4dos going then I suggest you force the drives to use LBA addressing instead. This is done in XTIDECFG and will require a reflash of the BIOS.
 
On the Pre-built Binaries Download Centre page, I miss information about the differences between the particular builds.
For example, what is the difference between ide_386 and ide_386l?

And I have a request: could it be possible to pad the files to a power of 2 size?
This would be very convenient because in case you have only, say, 27256 or 27512 EPROMs handy, you could just concatenate copies of the binary to fill up the EPROM, so it can be used in place of a 2764 or 27128.

Thank you!
 
retardware said:
On the Pre-built Binaries Download Centre page, I miss information about the differences between the particular builds.
For example, what is the difference between ide_386 and ide_386l?
Click to expand...
There used to be a table on the front page listing builds and their build options but I removed it because it was outdated and was very hard to read anyway. I'll have to think of a way to add that back but without the clutter.

Anyway, builds with names ending with XT are for XT class machines with 8088 or 8086 processors. XTP (as in XT Plus) are for XT class machines with NEC V20 or V30 processors. Builds ending with AT are for AT class machines (286 and higher). Builds ending with 386 are for AT class machines with 386 (or higher) processors and also gives additional support for some VLB controllers.

If there's an L at the end of the name then that just means it's a Large build, meaning its size is 10 KB as opposed to just 8 KB. The difference between Large and Small builds is mostly that Large builds includes MODULE_BOOT_MENU (the module you need to have the boot menu), but also a couple of other modules that are deemed non-essential for most people having to use a particular Small build. For example, most people using a small AT build do not need support for the controllers that MODULE_8BIT_IDE_ADVANCED brings but if they have the ROM space to use a Large AT build then it is included. In short, the Large builds contain everything whereas in the Small builds we had to compromise in order to fit the modules that are useful to most people.

Finally, there's the 4 KB Tiny build which is just a no-frills version of the regular XT build. These are all the official builds and they are sufficient for most peoples needs. With that said, there are scenarios where none of the official builds are suitable (for example, if you want to have the boot menu in a 8 KB ROM) in which case I recommend making a custom build of the BIOS. See the build instructions linked in the wiki. You will also find info regarding modules and other build options there.

And I have a request: could it be possible to pad the files to a power of 2 size?
This would be very convenient because in case you have only, sbinay, 27256 or 27512 EPROMs handy, you could just concatenate copies of the binary to fill up the EPROM, so it can be used in place of a 2764 or 27128.

Thank you!
Click to expand...

I'm not sure what you're requesting here. The BIOS files needs to be configured for the machine (with XTIDECFG.COM) and that will pad it to its required multiple of 2 KB size (usually 4, 8 or 10 KB but can be 6 KB also). The reason Large builds are 10 KB and not 16 KB is to make it easier for people to have several option ROM BIOSes coexist in the same ROM. For example, some people use a floppy BIOS concatenated with XUB in the same ROM.

Keep in mind that when you've saved a BIOS file with XTIDECFG that means it's been padded and checksummed so you can quite easily pad it further (to a power of 2 size) with anything (zeros or junk data doesn't matter). Easiest way is actually to use DEBUG since it is usually present on DOS systems anyway. Just load the BIOS file in debug and change the file size in the BX:CX register pair. Then hit W to save and Q to quit debug.

Example with a Large 386 build (10 KB padded to 16 KB);
Code: 
A:\>debug ide_386l.bin
-r
AX=0000 BX=0000 CX=2800 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=130E ES=130E SS=130E CS=130E IP=0100 NV UP EI PL NZ NA PO NC
130E:0100 55 PUSH BP
-rcx
CX 2800 :4000
-w
Writing 4000 bytes
-q
Now you can just do this to get a 32 KB file in xub.bin;
Code: 
copy/b ide_386l.bin+ide_386l.bin xub.bin

I hope this helps! Welcome to the forum by the way!
 
Thank you very much, @krille!
Now I understand much better!

Actually, I think the information you wrote in this post would be exactly the information which I felt missing in the xtide page.
Maybe you can just merge it into there?

If I understand correctly, the correct way is not to just take an image file from the download page, but instead my retro mate needs to run XTIDECFG on the particular machine to configure the BIOS image, then save it, then pad it and finally send me the image so I can flash an EPROM for him?
 
retardware said:
...If I understand correctly, the correct way is not to just take an image file from the download page, but instead my retro mate needs to run XTIDECFG on the particular machine to configure the BIOS image, then save it, then pad it and finally send me the image so I can flash an EPROM for him?
Click to expand...
The recommended way is to configure the XUB using XTIDECFG.COM on the machine it is intended for first, Once properly configured and saved, XTIDECFG will have done the padding and checksum. The file size will end up being either 4kb / 8kb or 10kb depending on what file was chosen.
 
I'm having pains with trying to get xtide universal bios on a 80486 (using onboard IDE. The idea is to try and support modern HDDs, as bios's implementation is limited to 8GB)

The NIC is an ISA D-LINK DE-200TP+. ROM socket is dIp28 (I have no idea which roms it is meant to support or where to find this information), which fits the 27C256 perfectly. There's a boot rom jumper, set to enabled.

Using a TL866-II and minipro (open source burning tool for this programmer) I burned + verified these into M27C256 roms:

- ide_386l (written by xtidecfg) padded to 32768
- ide_386 (as-is from download) padded to 8192, and concatenated 4 times.

Padded means dd if=/dev/zero of=pad bs=1 count=<bytes> ; cat rom pad >paddedrom

Neither work. The 486 doesn't find the bios extension at all. The ethernet does of course work (I boot a freedos floppy with etherdfs in boot script)

I have one blank M27C256 left to burn. Advice?

(An EPROM eraser is on its way, but will take ~4 weeks)
 
Last edited:
I would recommend trying again with the 4x copy of the 8k version, but load/save it in xtidecfg first to write the checksum byte
 
maxtherabbit said:
retardware has a solution for that ;)
Click to expand...

As far as I can see he does have an extra layer of indirection :wink:.

I can burn my own eproms (and soon I'll be able to blank them too!), but there's the issue of not knowing:

- If I'm padding correctly (described the method used above)
- If I'm missing some form of checksum somewhere.
- If 27C256 is the correct EPROM for a D-Link DE-200TP+ NIC. (or which EPROM or EEPROM I should get if it's not the case)
- What memory address the NIC should be configured to show the ROM at.
- If this 486's bios is hostile to boot roms and it won't work no matter what.
 
maxtherabbit said:
I would recommend trying again with the 4x copy of the 8k version, but load/save it in xtidecfg first to write the checksum byte
Click to expand...

It would mean the downloads have the wrong checksum (!) or that zero pad is the wrong padding. Either would surprise me.

I only have one chance at this until I receive the eprom eraser, so I guess I'll wait a day or two for possible additional ideas.
 
dmac said:
I can burn my own eproms (and soon I'll be able to blank them too!), but there's the issue of not knowing:

- If I'm padding correctly (described the method used above)
- If I'm missing some form of checksum somewhere.
Click to expand...
Try the DOS utility at [here], and see if it finds the XTIDE Universal BIOS (XUB) in memory space. If found, the utility will also verify the checksumming.

Because your computer is AT-class, you will need to use the utility with its optional NOMBCHECK switch,
i.e.
A:>rayxtide /nombcheck
 
You must log in or register to reply here.
Back
Top