Announcement

Collapse

Forum etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


"PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

XTIDE Universal BIOS v2.0.0 beta testing thread

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Krille
    replied
    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.

    Leave a comment:


  • Krille
    replied
    Originally posted by Malc View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • Krille
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • Krille
    replied
    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.

    Leave a comment:


  • Malc
    replied
    Originally posted by Krille View Post
    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.

    Leave a comment:


  • Krille
    replied
    Originally posted by Malc View Post
    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.

    Leave a comment:


  • Malc
    replied
    Originally posted by Krille View Post
    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. ?

    Leave a comment:


  • Megatron-uk
    replied
    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

    Leave a comment:


  • Megatron-uk
    replied
    Originally posted by Krille View Post
    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:

    xtide_biosdrvs.png

    Win98SE fdisk output, one primary and one extended partition:

    xtide_fdisk1.png

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

    xtide_fdisk2.png

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

    xtide_dir_sizes.png

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

    xtide_dir_corrupt.png

    xtide_dir_corrupt2.png
    Attached Files

    Leave a comment:


  • Krille
    replied
    Originally posted by Malc View Post
    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).

    Originally posted by Megatron-uk View Post
    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?

    Leave a comment:


  • Megatron-uk
    replied
    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.

    Leave a comment:


  • Malc
    replied
    Originally posted by Krille View Post
    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.

    Leave a comment:


  • TheDrip
    replied
    Originally posted by Krille View Post

    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.

    Leave a comment:

Working...
X