AlessandroB wrote on 2024-06-19, 10:51:

What differences in performance are there between the controller integrated on the motherboard and the XT-IDE?

Obviously it depends on the controller integrated on the mainboard. Let me explain better then... I would like to use a Compact flash with games from the first half of the 90s installed and to do this I have mounted the external bracket in each of my computers to easily insert the CF. From the Pentium 200 onwards there are no problems but from the 486 the classic disk size problems begin to appear. The 486 sees up to 1GB, the 386 512MB. Both are IBM computers, the 386 a PS/1 and the 486 a PC330. I imagine the 386 has a controller connected via ISA while the 486 via VLB. By installing an xt-ide card that is 8bit ISA I would almost certainly have a performance decline in 486, but in 386?

tnks guys

This is correct, but CompactFlash cards don't have any moving parts so seek time and read/write are much faster than a mechanical hard drive.

Please be aware to use your BIOS' function to shadow that ROM or to use EMM386 to shadow it before you try to compare performance.
Thank you in advance.

As an alternative you can use some DDO software with the current controller and skip XT-IDE, if you find out that it affects performance.

konc wrote on 2024-06-19, 12:37:

As an alternative you can use some DDO software with the current controller and skip XT-IDE, if you find out that it affects performance.

i only like to use a hardware solution

Disruptor wrote on 2024-06-19, 12:03:

Please be aware to use your BIOS' function to shadow that ROM or to use EMM386 to shadow it before you try to compare performance.
Thank you in advance.

I didn't understand very well, are you suggesting a way to do a test?

How much slower is the 8 bit card compared to a 16 bit interface? Probably about 60% of the speed.
Would you notice on a 386? Probably not in most cases.
Is it going to be a pain to get the 8 bit controller work along side your onboard IDE ports? Maybe.

If you just want to get the rear port, I'd get one of these:

Attach that to your on-board IDE controller.
And then look at a drive overlay ( https://vogonsdrivers.com/index.php?catid=19 ) or a 386 build of the XUB option rom ( https://minuszerodegrees.net/xtide/XUB/XUB%20versions.htm )

The 9.09 version of the EZ drive overlay supports 32bit transfers for VLB. The 386L build of R625 XUB supports 32bit transfers and has native support for VLB IDE controllers for some Promise and QDI controllers but support for faster transfer modes also depends on the interaction with the storage device too, so things can get complicated when trying to get faster ATA or WDMA modes working. Getting faster storage performance from a VLB controller is often a lot more complicated than just hooking a drive up to a very long board controller.

Access to ROM on the ISA bus is slow, and causes waitstate penalties among other things, while the code gets executed.

This is important, as the handler for INT13 (disk handler) is code that gets run any time you access a disk drive, and is the code that handles ECHS and LBA translation for DOS.

"Shadowing" is a technology that was developed back in the 90s to address this performance hit; It copies the ROM from the rom chip into an identically sized slice of RAM, uses the Memory Mapping Unit (MMU, it's baked into the memory controller on some systems, into the CPU on others. Architecture specific.) to remap the address, so that the RAM is accessed instead of the ROM, and then sets that RAM as Read Only. In vintage machines, this is accomplished by the chipset.

Essentially, this makes a copy of the option rom in MUUUUUCH faster system ram (which has no waitstates other than the memory fetch cycle itself, which is unavoidable.)

I am unsure how one goes about getting EMM386 to shadow a rom... I am unaware of any flags to give it to make it do that. I know it can map a rom out completely, and map empty, writable ram there instead, using the INCLUDE statement, but I am unsure how you would get it to shadow a rom (correctly).

googled. Apparently, you can use the ROM=XXXX-XXXX style syntax to tell EMM386 to shadow a rom within the specified address range. This might be beneficial in some circumstances, of which an 8bit XT-IDE card (or 8bit nic with option rom socket) is used to get the XUB into the adapter region for booting/detection purposes.

Making it shadowed in ram, instead of doing a very slow ISA bus access cycle, would result in a handy boost to disk IO.

douglar wrote on 2024-06-19, 13:05:

How much slower is the 8 bit card compared to a 16 bit interface? Probably about 60% of the speed. Would you notice on a 386? […]
Show full quote

How much slower is the 8 bit card compared to a 16 bit interface? Probably about 60% of the speed.
Would you notice on a 386? Probably not in most cases.
Is it going to be a pain to get the 8 bit controller work along side your onboard IDE ports? Maybe.

If you just want to get the rear port, I'd get one of these: images (1).png
Attach that to your on-board IDE controller.
And then look at a drive overlay ( https://vogonsdrivers.com/index.php?catid=19 ) or a 386 build of the XUB option rom ( https://minuszerodegrees.net/xtide/XUB/XUB%20versions.htm )

The 9.09 version of the EZ drive overlay supports 32bit transfers for VLB. The 386L build of R625 XUB supports 32bit transfers and has native support for VLB IDE controllers for some Promise and QDI controllers but support for faster transfer modes also depends on the interaction with the storage device too, so things can get complicated when trying to get faster ATA or WDMA modes working. Getting faster storage performance from a VLB controller is often a lot more complicated than just hooking a drive up to a very long board controller.

+1 to this

Loading the the XUB from a network card is probably the easiest way forward. It might be possible to add the XUB as an option ROM to the existing motherboard BIOS ROM, but that's more complicated.

Thanks for all the answers, as usual incredibly precise and full of information. Vogons is truly a gem. But I was looking for something less demanding, I have very little time to dedicate to our hobby and if on the one hand I have performance reduced by 60% I'm not sure if it's worth it to me... after all in 512MB of 90->95 games you install a lot

AlessandroB wrote on 2024-06-19, 17:40:

Thanks for all the answers, as usual incredibly precise and full of information. Vogons is truly a gem. But I was looking for something less demanding, I have very little time to dedicate to our hobby and if on the one hand I have performance reduced by 60% I'm not sure if it's worth it to me... after all in 512MB of 90->95 games you install a lot

If you are going to use XT-ide / XUB, you will need to config the image and write it to an EPROM or EEPROM. Most of the 8 bit XT-IDE cards come with an EEPROM and are capable of writing to it.

The quick and easy solution though is to install easy drive http://vogonsdrivers.com/getfile.php?fileid=1900

douglar wrote on 2024-06-19, 18:20:

AlessandroB wrote on 2024-06-19, 17:40:

Thanks for all the answers, as usual incredibly precise and full of information. Vogons is truly a gem. But I was looking for something less demanding, I have very little time to dedicate to our hobby and if on the one hand I have performance reduced by 60% I'm not sure if it's worth it to me... after all in 512MB of 90->95 games you install a lot

If you are going to use XT-ide / XUB, you will need to config the image and write it to an EPROM or EEPROM. Most of the 8 bit XT-IDE cards come with an EEPROM and are capable of writing to it.

The quick and easy solution though is to install easy drive http://vogonsdrivers.com/getfile.php?fileid=1900

i have an xt-ide in mi ps/2 286 and is plug and play… inserta card in the slot isa, insert cf in the xt-ide slot , switch on the computer and work prefect

AlessandroB wrote on 2024-06-19, 18:50:

i have an xt-ide in mi ps/2 286 and is plug and play… inserta card in the slot isa, insert cf in the xt-ide slot , switch on the computer and work prefect

Consider note#3 from this link: https://minuszerodegrees.net/xtide/XUB/XUB.htm
You got lucky. Your device came hard coded with a configuration that worked for you. If you try to put it into a system that is already using those hard coded resources, it would not have worked. If it had the 386 rom, it would not have worked.

Generally speaking, I expect most XTide devices come with the XT rom with the correct check sum, which is going to be slow.

On a 286, you might want to get IDE_ATL.bin for better performance & features.
On a 386 or a 486 you might want to get the IDE_386l.bin to enable faster transfers.
https://www.lo-tech.co.uk/wiki/XTIDE_Universal_BIOS

p.s: There is such a thing as Legacy ISA "plug-n-play" which involved hardware, drivers and BIOS that understood a common set of enumeration, arbitration, & configuration processes. XUB and computers before 1995 don't know about that stuff.

p.p.s: I do agree that XUB is good at autodetecting geometry of devices that support the ATA Identify_device command. But if you are using drives older than ATA-3, you may need to manually configure the Heads, Sectors, Cylinders with the XUB config tool.

I am severely biased against drive overlays, so my vote always goes toward XUB ( XT-IDE), except if there are no other options than a drive overlay .

darry wrote on 2024-06-20, 02:35:

I am severely biased against drive overlays, so my vote always goes toward XUB ( XT-IDE), except if there are no other options than a drive overlay .

Some of those early overlays were practically ransomware, yes. Proprietary partition types & non-standard CHS mapping made accessing the volume really hard unless you booted from the drive. Sometimes it seemed like the only way to get data off them was with a big stack of floppy disks.

However if you use v9 or v10 of EZ drive or OnTrack, things were much more compatible. Standard partition types, LBA support, 32 bit disk access, & didn't make Windows 9x panic into compatibility mode. All the stuff you expect from XT-Ide.

darry wrote on 2024-06-20, 02:35:

I am severely biased against drive overlays, so my vote always goes toward XUB ( XT-IDE), except if there are no other options than a drive overlay .

XUB more or less is a drive overlay; they both replace the BIOS (Int 13) routines, the only difference is XUB comes from a ROM rather than the disk.

jmarsh wrote on 2024-06-20, 15:46:

darry wrote on 2024-06-20, 02:35:

I am severely biased against drive overlays, so my vote always goes toward XUB ( XT-IDE), except if there are no other options than a drive overlay .

XUB more or less is a drive overlay; they both replace the BIOS (Int 13) routines, the only difference is XUB comes from a ROM rather than the disk.

My specific dislike is for drive overlay software loaded from disk and when I said that I was biased against it, I did mean to imply that I disliked it for reasons that were not purely rational.

XUB is pretty mature at this point and likely both reliable and compatible (including LBA48 support and ability to reliably read/write drives moved to modern machines), though there used to be issues [1]. There might still be issues that I have not read about yet or encountered, TBH.

As for drive overlay software loaded from disk, off the top of my head, my concerns would be :
- ability to move a drive to a modern PC for data transfer without risking corruption (if it works at all)
- concern about losing access to drive content if the on-disk bootloader gets corrupted/overwritten
- compatibility with post Windows 9x/ME (i.e. NT, OS/2, XP)
- conventional memory consumption

That being said, at leat some of these might be moot points in a retro usage scenario where reinstalling OS and games or reimaging is the worst case data loss scenario, but some might still be issues, depending on actual use case details.

EDIT:
See also : XUBDisk - floppy disk XTIDE Universal BIOS booter

[1]
Re: XTIDE and large (>8G) partitions
Re: Adding XT-IDE option ROM to Asus P3B-F BIOS . (please ignore my hypothesis about the Phoenix Enhanced Disk Drive Specification in my use case, as L-CHS was not being used)

IMO, a very clever thing could be made by combining the functionality of umbpci (and on 286/386 systems, other chipset umb drivers) with XUB, so that hardware configured/supplied UMB can be created, and the XUB loaded there.

Possibly as a GRUB2 driver module.

Letting it live inside a very small ext2 or hidden fat partition, or cooking it up as a boot floppy prebooter, (combine with plopboot?) Should let you have a sane partition table, at the cost of one of the partition entries.