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

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

    Originally posted by dmac View Post
    The expectation for rom images is for them to be ready to burn. A good policy is to have the safest defaults.
    The XTIDE project supports so many different hardware configurations I suspect you’d have quite a bit of difficulty getting people to agree on what the most useful default is. (I would go so far as to say that may be an impossible ask for the eight bit builds) It’s not unreasonable to expect consumers of such a technically oriented thing to put a few minutes into RTFM-ing.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

    Comment


      I've debated this with Krille before, but my stance is it is FAR easier for a user to see the XTIDE sign-on text and get the drift that it's looking at the wrong I/O port or whatever than to get absolutely nothing at all and be left wondering wtf.

      My opinion: the ROM releases should be ready to load and execute, the default drive access configuration is irrelevant.

      Imagine you are the user with no foreknowledge - if you see that the ROM is loading successfully but not finding drives, your troubleshooting instincts would then bring you toward the ROM's documentation. If you see that it is not loading at all, you would begin to suspect something else in your system or tool chain. EXACTLY as what occurred here. No one in their right mind would assume "oh this released option ROM image must not be checksummed"

      Comment


        … But if someone is insisting on not reading the manual and burns one of these unconfigured images to a UV-erasable or OTP EPROM they still just wrecked their day. Maybe I’m a big meany but I have my doubts that someone who isn’t even going to scan the manual for something that is pretty obviously more complicated than a pirated game ROM has the best instincts troubleshooting or otherwise. The warning that the BIOS images for download are useless until configured is the first paragraph of the first page of the website. The devs could put a “Readme.1st” file in the download dir proper for people that direct link there and skip the front page, but that’s about the only way I can see to put any more bubble wrap around it.

        Maybe the unconfigured images should be padded and checksummed, but out of the box all they do is say “UNCONFIGURED: run XTIDECFG to continue!”.

        (Edit: I just checked the modification history for the front page and the stern warning about running XTIDECFG appeared six months ago. I would definitely have more sympathy prior to that. FWIW, I do actually think a readme with the downloads could be useful additional CYA.)
        Last edited by Eudimorphodon; September 12, 2021, 07:05 AM.
        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

        Comment


          You say "insisting" on not reading the docs implying people are being belligerent, when in reality the most common MO throughout the history of technology has been "try first, read later."

          The disconnect here is that the symptom is not commensurate with the actual problem - a ROM being configured improperly for the hardware does not prevent it from loading and executing, it defies the knowledge of experience.

          It would be trivial for the releases to include a checksum byte, I don't feel like I'm asking for a large accommodation.

          Comment


            Originally posted by Eudimorphodon View Post
            (Edit: I just checked the modification history for the front page and the stern warning about running XTIDECFG appeared six months ago. I would definitely have more sympathy prior to that. FWIW, I do actually think a readme with the downloads could be useful additional CYA.)
            that warning appeared at my behest, prior there was NO indication at all, anwhere

            Comment


              Originally posted by maxtherabbit View Post
              that warning appeared at my behest, prior there was NO indication at all, anywhere
              Thank you for that, then. I actually went back and checked the changelog on the Wiki front page after posting because bad memories of some significant issues with the documentation that existed a couple years ago when I built my first XT-CF suddenly came flooding back. (There was this period where it was actually really confusing to find the Download page at all if you came in via the front door.) So... yeah, the docs have certainly had their gaps in the past. At least it's there now.

              That said:

              You say "insisting" on not reading the docs implying people are being belligerent, when in reality the most common MO throughout the history of technology has been "try first, read later."
              I know it's been everyone's gosh-given right as an American to just dump the newest hyper-sophisticated miracle of modern science out of a box, plug it in, and have it "just go" since the 1950's, and based on such it would be a reasonable expectation for someone, say, buying a complete XTIDE card to assume the BIOS chip on it was set up to at least accommodate the default jumper settings so it's "plug and play". But the BIOS itself isn't a "consumer" item, it's "system integration"-level code that typically *will* require customization for whatever hardware it's intended to go with, and making the wrong choices can in a significant number of edge cases create crash-severity conditions. Having an unconfigured image do "nothing" is the safer option compared to having it try to do wrong thing.

              (If the code had more capability to at runtime autodetect hardware this would be less of a problem, but as it is it requires re-flashing the ROM if you change port hardware addresses, let alone what hardware scheme you're using.)

              If someone wanted to take on the job of curating pre-configured ROMs for various common configurations maybe that wouldn't be the worst idea ever. I haven't used the AT build, only the XT ones, and on the XT side of the fence 16-bit "full" XTIDE and 8-bit XT-CF-lite hardware seem to be about roughly equally common and there are significant type variants of both. Therefore the chances that a "generic" binary will be correct one seem pretty low. Maybe there is a "generic" AT config that covers 95% of use cases with no further config?
              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

              Comment


                Having an unconfigured image do "nothing" is the safer option compared to having it try to do wrong thing.
                This is really the crux of my disagreement, I cannot concieve of a situation where running an improperly configured XUB would actually hurt anything

                Comment


                  Originally posted by maxtherabbit View Post
                  This is really the crux of my disagreement, I cannot concieve of a situation where running an improperly configured XUB would actually hurt anything
                  To pick a random example from the XT side of the fence: If you enable "Full Operating Mode" then pretty bad things will happen if you use that BIOS in a Tandy 1000 (you will crash and burn hard if you use a Tandy graphics mode), but if you don't enable it you'll break ROM BASIC in an IBM machine. Which should be the default?
                  My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                  Comment


                    Back in the early days it was a no brainer, The 6 monthly and prior official releases on the old google code site were configured and checksummed, The XT binaries were configured for the XTIDE R1 controller and the AT binaries were configured for the 16-bit controllers because there was no other's until the XTIDE R2 > / JR IDE and Lo-Tech ISA CF / Lite controllers appeared, The BETA 3 was the last of the configured and checksummed binaries to be released in March 2013 which was R517, The Google code XUB site was shut down in 2016, By then the XUB revision had reached r588.

                    Eventually the XUB found a new home and is now at r618, It supports more controllers and more systems, I have no idea what's involved server side in setting up to provide basic configured and checksummed XT binaries configured for the XTIDE r1 controller and AT binaries configured for the 16-bit controller,

                    Personally i don't see the point in checksumming NON_CONFIGURED_BINARIES but maybe a basic configuration would make some folk happy or not.

                    Comment


                      To answer the specific question as posed, I'd break the ROM BASIC, because who cares lol.

                      But my meaning in bolding hurt was to imply real damage, such as data loss, not simply making something not work.

                      Overall I like the idea of making the releases conform to the most likely use cases by default, as malc laid out. 16-bit IDE for the At build and so on

                      Comment


                        Hey, I actually like the idea of embedding a code stub in there that says "Thank you for downloading, now read the manual" if an image isn't configured if a dev wants to toss it together.
                        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                        Comment


                          Either way it bothers me not, I've rtfm and been building my own from source for Years.

                          Comment


                            Originally posted by modem7 View Post
                            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
                            Great idea and initiative, Ray!
                            That seems to be a very helpful tool!
                            Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                            Comment


                              Originally posted by dmac View Post

                              The expectation for rom images is for them to be ready to burn. A good policy is to have the safest defaults.

                              Knowledge about padding, checksums and such would be optional most of the time, so would be reading the documentation, if rom images were distributed in a burnable format, which (again) would be the safest and most correct way to distribute them.
                              My expectation is for people to read at least some of the documentation. I guess we should both adjust our expectations. If you think that reading the documentation is optional then by all means, don't read the documentation.

                              d967098131c49b3559e01c008dbc40f3.jpg
                              Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                              Comment


                                Originally posted by Eudimorphodon View Post
                                (I also assume that if you read a padded file back into XTIDECFG it would either complain about it being the wrong size or just discard the non-code pages.)
                                Actually, I just tried and it does neither. It will preserve the file size on disk. It should also flash the whole file to ROM but I can't test that.
                                Looking for a cache card for the "ICL ErgoPRO C4/66d V"

                                Comment

                                Working...
                                X