Announcement

Collapse

Forum Rules and 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.


Rule 1: 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.


Rule 2: 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.



Rule 3: 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.


Rule 4: "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.

Rule 5: 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

    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

    Comment


      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. ?

      Comment


        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.
        Looking for a cache card for the "ICL ErgoPRO C4/66d V"

        Comment


          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.

          Comment


            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.
            Looking for a cache card for the "ICL ErgoPRO C4/66d V"

            Comment


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

              Comment


                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.
                Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                Comment


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

                  Comment


                    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.
                    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                    Comment


                      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.
                      Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                      Comment


                        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.
                        Last edited by Blazer; July 8, 2021, 09:18 PM.

                        Comment


                          Originally posted by Blazer View Post
                          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.
                          Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                          Comment


                            Originally posted by Krille View Post

                            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.

                            Comment


                              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.

                              Comment


                                Originally posted by Blazer View Post
                                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.
                                Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                                Comment

                                Working...
                                X