XTIDE Universal BIOS v2.0.0 beta testing thread

[Jove]

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?

8 bit controller on a 16 bit bus.

 

[Malc]

r606 is out!

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!

A CHS Translation *Bug* ??
Now i gotta remember to manually set the " CHS Translation Mode " to LBA, Otherwise i get the "Missing operating system" error.
No big deal, The CF cards i use in my XT's support LBA, I use a much newer / faster system to set my CF cards up.

 

[Megatron-uk]

Could this 'bug' be responsible for disk content over >8GB being inaccessible? This is using a r605 ide_386l image on a 3c509b.

I've got some CF cards and modern hard drives all over 8gb that I am trying to partition and format with Win98se or PC-dos 7.1 fat32 (and they do so just fine) but fail at accessing any content I drop on to them over ~8gb...

But connect them back up to a modern pc and all the content and files are there.

 

[Krille]

A CHS Translation *Bug* ??
Now i gotta remember to manually set the " CHS Translation Mode " to LBA, Otherwise i get the "Missing operating system" error.
No big deal, The CF cards i use in my XT's support LBA, I use a much newer / faster system to set my CF cards up.

Yeah, forcing the translation mode to use LBA can be used if you want to avoid repartitioning and reformatting the drives. The downside of using LBA is that you might lose a bit of disk space due to rounding because of the translation. The translation also makes disk accesses a bit slower (not sure how much slower, though).

Could this 'bug' be responsible for disk content over >8GB being inaccessible? This is using a r605 ide_386l image on a 3c509b.

I've got some CF cards and modern hard drives all over 8gb that I am trying to partition and format with Win98se or PC-dos 7.1 fat32 (and they do so just fine) but fail at accessing any content I drop on to them over ~8gb...

But connect them back up to a modern pc and all the content and files are there.

No, this bug affects only small drives with 1024 cylinders or less. So basically drives with sizes up to 504 MiB or 528 MB. MS-DOS 6.22 and older versions has a drive size limit at about 8 GB. So which version of DOS are you using?

 

[Megatron-uk]

No, this bug affects only small drives with 1024 cylinders or less. So basically drives with sizes up to 504 MiB or 528 MB. MS-DOS 6.22 and older versions has a drive size limit at about 8 GB. So which version of DOS are you using?

So far I've tried the Dos 7.1 as included on a Win98SE boot floppy, as well as IBM PC-DOS 7.1. Both are fully FAT32 aware, as far as I know.

Both will partition the drive(s) and format them as normal (a small C:, another ~7GB for D:, and the remainder for E: - so E: stretches from just below 8GB to the remainder of the drive). I've even tried a big 64GB CF card and a couple of 2.5" IDE laptop drives and both Win98SE and PC-DOS 7.1 are happy partitioning and even formatting partitions up to the maximum size of the drive. All devices I've tried experience the same behaviour I describe below.

However, if I go back to my 16GB card that I'm using - I put a basic bootable system on C:, check it can boot and then remove the drive to copy content on to it from my Linux workstation.

On accessing the drive back in the XTIDE system again, all content copied to C: and D: is present and correct - absolutely zero problems. If I left things there, the system is absolutely fine, everything works. But, if I copy enough content on to E: so that directory entries and file content is beyond 8GB (say 2GB of data), I see empty directories, corrupt filenames or dir will simply lock the computer up.

Remove the card and put it back in to a modern PC and all the content is still there, absolutely fine.

Output from biosdrvs.com:



Win98SE fdisk output, one primary and one extended partition:



Two logical drives, with E: extending from under 8GB to the end of the (16GB) drive.



Drive C: is fine, so is D:, and here I've got several GB of content copied to E:, root directory entry looks okay:



... but trying to access virtually anything from that third partition which is beyond 8GB generates rubbish:

 

[Megatron-uk]

I've tried partitioning and formatting in Linux instead of either the Win98SE or PC-DOS 7.1 fdisk/format tools. I've tried running Powerquest Partition Magic in Dos itself. Various combinations of partition sizes: One large FAT32 partition, one small FAT16 partition and the rest as FAT32, FAT16 plus multiple FAT32 partitions (which is how I narrowed the problem down to content >8GB being consistently problematic) etc.

I've tried the following XTIDE images:

r604 ide_atl (which is working in a 286 with a 4GB CF card)
r605 ide_386l
r606 ide_386l

 

[Malc]

Yeah, forcing the translation mode to use LBA can be used if you want to avoid repartitioning and reformatting the drives. The downside of using LBA is that you might lose a bit of disk space due to rounding because of the translation. The translation also makes disk accesses a bit slower (not sure how much slower, though).

I did a little experiment, I used 2 identical CF cards, 1 was setup using CHS and the other LBA and both had a full install of DOS 6.22, The disk space loss was negligible a little over 1Mb, I noticed no difference in speed, I ran IOTEST on both cards and got very similar results just a few Kb/s either way.

I'm curious, With XUB r606 CHS Translation mode set to " AUTO ", The cf card setup with CHS parameters Boots perfectly fine But i have to manually set the translation mode to LBA for the other cf card for it to work, So " auto " is not really "Auto", ie: it's not detecting the access mode of the already setup CF card. ?

 

[Krille]

I did a little experiment, I used 2 identical CF cards, 1 was setup using CHS and the other LBA and both had a full install of DOS 6.22, The disk space loss was negligible a little over 1Mb, I noticed no difference in speed, I ran IOTEST on both cards and got very similar results just a few Kb/s either way.

Thanks for testing! Yeah, I mentioned this just as an FYI, it won't make much of a difference either way.

I'm curious, With XUB r606 CHS Translation mode set to " AUTO ", The cf card setup with CHS parameters Boots perfectly fine But i have to manually set the translation mode to LBA for the other cf card for it to work, So " auto " is not really "Auto", ie: it's not detecting the access mode of the already setup CF card. ?

Auto in this context means "let the BIOS decide" (which it does based on information in the IDENTIFY DEVICE response), as opposed to the user forcing a translation mode, not autodetecting the currently used translation mode - that would require reading the disk and identifying the file system, then try to analyse it in order to determine the CHS translation used. Not something a BIOS can do, at least not a BIOS that's supposed to fit in an 8 KB ROM.

Megatron-uk That is definitely another bug. I'm surprised no one has reported it before. Also, I saw your thread on vogons - Tomi (aitotat) pointed me to it.

 

[Malc]

Auto in this context means "let the BIOS decide" (which it does based on information in the IDENTIFY DEVICE response), as opposed to the user forcing a translation mode, not autodetecting the currently used translation mode - that would require reading the disk and identifying the file system, then try to analyse it in order to determine the CHS translation used. Not something a BIOS can do, at least not a BIOS that's supposed to fit in an 8 KB ROM.

That makes sense, "Biosdrvs" reports the correct *Manufacture specific* CHS Values for the CF cards, A bit weird that Phoenix and Award seem's to default to LBA for the same cards, But i can easily remedy that.

 

[Krille]

So, with r611 out Tomi fixed a bug in the LBA48 code - apparently it has always been broken. I guess not many people are using XUB with drives supporting LBA48 which makes sense since it's only required for drives over 128 GiB / 137 GB and few people need that much storage in their vintage machines. Note that LBA48 is also supported on some drives smaller than that. For example, Tomi did his testing on a 60 GB Toshiba 1.8" hard drive. So to anyone who has had problems with *any* drive using LBA this revision might be the fix!

However, with that said, I don't think this will fix your problem Megatron-uk.

Last night I found this post on another forum. The section under "Smart ATA devices with correct (but 'illegal') CHS values" mentions that some CF cards violates the ATA specification by reporting more than 16383 cylinders and the Sandisk Ultra 16 and 32 GB models are specifically mentioned. Your image of the BIOSDRVS output clearly shows that the card reports 31045 cylinders.

 

[Malc]

I noticed Biosdrvs.com is missing from recent official builds on the XUB binaries site, I assume there is a problem server side ?

 

[Krille]

No, I made a change in r609 that broke the building of BIOSDRVS.COM. I usually verify that everything builds before committing to the repository but forgot to do that. The problem was fixed in r612.

 

[Malc]

Ah i see, I see it's also missing from r613 though it builds fine locally.

 

[Krille]

Ah i see, I see it's also missing from r613 though it builds fine locally.

Ah, now I see what you mean. I hadn't noticed that so I just assumed you meant my recent eff-up. Thanks for letting me know! Yeah, the server is running Linux so it's very particular about using the correct case when referencing files.

 

[Krille]

XUB r614 is out!

Two notable changes;

A configuration option to skip detection of slave drives has been added. This is most useful with controllers that don't support slave drives at all.

'Auto Configure' in XTIDECFG should now detect Olivetti M24 and friends and select the highest performing transfer mode/device type for any controllers found. The detection relies on a BIOS call supposedly only available on Olivetti machines so it might detect other non-M24 machines as M24:s? Obviously this is not ideal so if anyone has any suggestions on how to improve this I'm all ears.

 

[Blazer]

I have the r614 release of ide_atl.bin on a 3Com 3C509B network card and a 16-bit IDE controller.

There is a an MFM controller that is on IRQ 14 at 1F0h and I have configured the 16-bit IDE controller to be on IRQ 15 at 170h.

I have configured the XUB BIOS for one controller and to use IRQ 15 at 170h but I am not sure what to set the control block address to.

The following extract from the XUB website states that it should be set to the base port + 200h for a standard IDE controller which is 370h.

Wherever I look online it says that secondary controller is normally on IRQ 15, port 170h, base address 376h.

Is 370h correct or should it be 376h?

Thank you.

https://www.xtideuniversalbios.org/

• Base (cmd block) address [default=300h for XT-builds, 1F0h/170h/1E8h/168h for AT-builds]
  Command block (base port) I/O-address where the IDE controller is located. The JR-IDE/ISA and SVC ADP50L controllers use memory mapped I/O, not port I/O, so for these controllers the ROM segment address as configured with switches or jumpers on the card should be set here instead. Note that this is not necessarily the same segment address as the XTIDE Universal BIOS has been installed into.

• Control block address [default=308h for XT-builds, 3F0h/370h/3E8h/368h for AT-builds]
  Set to base port + 8h for XTIDE rev1, rev2 and Lo-tech XT-CF. Set to base port + 200h for standard IDE controller.

 

[Krille]

Is 370h correct or should it be 376h?

Have you tried running 'Auto Configure' in XTIDECFG (with a drive connected)? If the control block address is at the usual address for standard 16-bit IDE controllers then it should be detected at 370h. The only port used in the control block is at offset 6 which is likely why the references you found says 376h.

So my bet is on 370h.

 

[Blazer]

Have you tried running 'Auto Configure' in XTIDECFG (with a drive connected)? If the control block address is at the usual address for standard 16-bit IDE controllers then it should be detected at 370h. The only port used in the control block is at offset 6 which is likely why the references you found says 376h.

So my bet is on 370h.

Thanks for the explanation.

 

[Blazer]

I have the r614 release of ide_atl.bin on a 3Com 3C509B network card and a 16-bit IDE controller connected to a rear accessible compact flash adapter.

There is a an MFM controller that is on IRQ 14 at 1F0h and I have configured the 16-bit IDE controller to be on IRQ 15 at 170h.

I have configured the XUB BIOS for one controller and to use IRQ 15 at 170h.

If I boot the system with the Sandisk 256MB compact flash card inserted and press D then it boots from the CF card as expected. The XUB BIOS shows the following:

Master at 170h: Sandisk SD-2259-HB
Slave at 170h: not found

If I boot the system with no CF card inserted then the XUB boot messages for Master and Slave do not say "not found" but are blank.

Master at 170h:
Slave at 170h:

The system then boots automatically from the MFM drive successfully.

If I run biosdrvs.com it lists 3 drives rather than just the MFM drive.

Are the two extra drives shown which have strange values related to the XUB BIOS thinking that there is something still connected to the Master and Slave IDE connectors?

Thank you.

 

[Krille]

If I boot the system with no CF card inserted then the XUB boot messages for Master and Slave do not say "not found" but are blank.

Master at 170h:
Slave at 170h:

The system then boots automatically from the MFM drive successfully.

If I run biosdrvs.com it lists 3 drives rather than just the MFM drive.

This is weird. I would try disconnecting the CF adapter, the IDE cable and also remove the IDE controller (if possible) to see if these misdetections stop and if so where the problem is.