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

    Thank you very much, @krille!
    Now I understand much better!

    Actually, I think the information you wrote in this post would be exactly the information which I felt missing in the xtide page.
    Maybe you can just merge it into there?

    If I understand correctly, the correct way is not to just take an image file from the download page, but instead my retro mate needs to run XTIDECFG on the particular machine to configure the BIOS image, then save it, then pad it and finally send me the image so I can flash an EPROM for him?

    Comment


      Originally posted by retardware View Post
      ...If I understand correctly, the correct way is not to just take an image file from the download page, but instead my retro mate needs to run XTIDECFG on the particular machine to configure the BIOS image, then save it, then pad it and finally send me the image so I can flash an EPROM for him?
      The recommended way is to configure the XUB using XTIDECFG.COM on the machine it is intended for first, Once properly configured and saved, XTIDECFG will have done the padding and checksum. The file size will end up being either 4kb / 8kb or 10kb depending on what file was chosen.

      Comment


        I'm having pains with trying to get xtide universal bios on a 80486 (using onboard IDE. The idea is to try and support modern HDDs, as bios's implementation is limited to 8GB)

        The NIC is an ISA D-LINK DE-200TP+. ROM socket is dIp28 (I have no idea which roms it is meant to support or where to find this information), which fits the 27C256 perfectly. There's a boot rom jumper, set to enabled.

        Using a TL866-II and minipro (open source burning tool for this programmer) I burned + verified these into M27C256 roms:

        - ide_386l (written by xtidecfg) padded to 32768
        - ide_386 (as-is from download) padded to 8192, and concatenated 4 times.

        Padded means dd if=/dev/zero of=pad bs=1 count=<bytes> ; cat rom pad >paddedrom

        Neither work. The 486 doesn't find the bios extension at all. The ethernet does of course work (I boot a freedos floppy with etherdfs in boot script)

        I have one blank M27C256 left to burn. Advice?

        (An EPROM eraser is on its way, but will take ~4 weeks)
        Last edited by dmac; September 10, 2021, 07:16 PM. Reason: ethernet works, rom does not
        Got an Amiga and a null-modem cable? Try amigaXfer today!

        Comment


          Originally posted by dmac View Post

          (An EPROM eraser is on its way, but will take ~4 weeks)
          retardware has a solution for that

          Comment


            Using this (not exactly the same, but close enough):

            https://stason.org/TULARC/pc/network...for-PC-AT.html

            I tried all 8 "mem" settings with the ide_386 rom described above, for the address of the boot rom, to no avail. Left it at 0xC8000 as that seems to be the "default".

            I also disabled mem remapping & bios shadow in the CMOS settings. It doesn't seem to help.
            Got an Amiga and a null-modem cable? Try amigaXfer today!

            Comment


              I would recommend trying again with the 4x copy of the 8k version, but load/save it in xtidecfg first to write the checksum byte

              Comment


                Originally posted by maxtherabbit View Post
                retardware has a solution for that
                As far as I can see he does have an extra layer of indirection .

                I can burn my own eproms (and soon I'll be able to blank them too!), but there's the issue of not knowing:

                - If I'm padding correctly (described the method used above)
                - If I'm missing some form of checksum somewhere.
                - If 27C256 is the correct EPROM for a D-Link DE-200TP+ NIC. (or which EPROM or EEPROM I should get if it's not the case)
                - What memory address the NIC should be configured to show the ROM at.
                - If this 486's bios is hostile to boot roms and it won't work no matter what.
                Got an Amiga and a null-modem cable? Try amigaXfer today!

                Comment


                  Originally posted by maxtherabbit View Post
                  I would recommend trying again with the 4x copy of the 8k version, but load/save it in xtidecfg first to write the checksum byte
                  It would mean the downloads have the wrong checksum (!) or that zero pad is the wrong padding. Either would surprise me.

                  I only have one chance at this until I receive the eprom eraser, so I guess I'll wait a day or two for possible additional ideas.
                  Got an Amiga and a null-modem cable? Try amigaXfer today!

                  Comment


                    The newer releases are unchecksummed, I'm not a fan of the policy

                    Comment


                      Originally posted by dmac View Post
                      I can burn my own eproms (and soon I'll be able to blank them too!), but there's the issue of not knowing:

                      - If I'm padding correctly (described the method used above)
                      - If I'm missing some form of checksum somewhere.
                      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

                      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
                        Thanks. Did not know about this tool.
                        Got an Amiga and a null-modem cable? Try amigaXfer today!

                        Comment


                          Originally posted by maxtherabbit View Post
                          The newer releases are unchecksummed, I'm not a fan of the policy
                          The better policy will minimize burned roms that won't work. Thus yeah, this is terrible.
                          Last edited by dmac; September 11, 2021, 09:13 PM. Reason: elaborated
                          Got an Amiga and a null-modem cable? Try amigaXfer today!

                          Comment


                            I took a look at some datasheets, and figured out that on some 27C128, the pin 27C256 uses as A14 is used as PGM (inverted). Thus if driven low, it'd enable programming. Therefore, most NICs that don't use A14 likely drive it high or pull it up.

                            Therefore, A14 will be permanently high on most NICs that don't support 32KB boot rom.

                            Thus, my 10KB 386l rom with correct checksum and padded with zeros wouldn't work because the exposed upper 16KB are just zero.

                            Originally posted by maxtherabbit View Post
                            I would recommend trying again with the 4x copy of the 8k version, but load/save it in xtidecfg first to write the checksum byte
                            That would definitely have worked. Mine didn't work because wrong checksum.

                            And I went and burned my remaining 32KB rom as blank 16KB pad + checksummed 10KB + blank 6KB pad.

                            ... and verify failed. My remaining rom was bad .

                            So testing will have to wait until I get UV eraser or more eproms (27C64 and 27C128 on their way).

                            Sigh.

                            Of interest, to test an option rom on qemu:

                            Code:
                            qemu-system-i386 -net none -option-rom ide_386l_padded.bin
                            To checksum an option rom, this cute tool from from qemu: https://github.com/qemu/qemu/blob/ma...pts/signrom.py

                            And interesting quote from etherboot documentation.


                            How does the main BIOS know that the code in the ROM is to be executed and why does it not execute some random code by accident? The ROM code has several conditions placed on it.
                            • The ROM must start on a 2kB boundary in the memory space, between 0xC8000 and 0xEE000, although some main BIOSes scan outside these limits.
                            • The first two bytes of the ROM must be 55 AA hex.
                            • The third byte of the ROM should contain the number of bytes in the ROM code divided by 512. So if the ROM code is 16kB long, then this byte would hold 20 hex (32 decimal).
                            • All the bytes in the ROM (specified by the length byte just mentioned) must checksum to 8 bits of binary zero. The sum is formed by 8 bit addition of all the bytes, throwing away the carry. Note that there is not a particular location designated as the "checksum byte". Normally the ROM building process alters an unused byte somewhere to fulfil the checksum condition.
                            I hope this is of use to someone.

                            I'll be back once I receive the goods and am able to do further testing.
                            Got an Amiga and a null-modem cable? Try amigaXfer today!

                            Comment


                              Originally posted by dmac View Post
                              The better policy will minimize burned roms that won't work. Thus yeah, this is terrible.
                              I don’t understand what the “policy” issue here is. It is in the docs that the downloaded binaries need to be run through XTIDECFG before they are usable and that pads the image to the next 2k boundary and makes the checksum add up. That the downloads are not padded to a 2k boundary is a good tip-off that they’re not usable.

                              Also if you need to pad a configured ROM to a larger size for your burner to accept it (some software doesn’t care and will just burn an image smaller than the ROM into the start of it) there’s no need to update any checksum, as the docs say the header has a byte saying how many 512 byte code pages there are that count in the calculation. If you pad on a 2k boundary then it simply doesn’t matter what you stick in there as long as it’s not going to get confused for another extension. (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.)
                              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                              Comment


                                Originally posted by Eudimorphodon View Post

                                I don’t understand what the “policy” issue here is. It is in the docs that the downloaded binaries need to be run through XTIDECFG before they are usable and that pads the image to the next 2k boundary and makes the checksum add up. That the downloads are not padded to a 2k boundary is a good tip-off that they’re not usable.

                                Also if you need to pad a configured ROM to a larger size for your burner to accept it (some software doesn’t care and will just burn an image smaller than the ROM into the start of it) there’s no need to update any checksum, as the docs say the header has a byte saying how many 512 byte code pages there are that count in the calculation. If you pad on a 2k boundary then it simply doesn’t matter what you stick in there as long as it’s not going to get confused for another extension. (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.)
                                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.
                                Got an Amiga and a null-modem cable? Try amigaXfer today!

                                Comment

                                Working...
                                X