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

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

    #16
    Originally posted by aitotat View Post
    I've finally completed configuration program for XTIDE Universal BIOS. It has build-in flash utility so flash.com will no longer be needed. I'll release configuration program with XTIDE Univeral BIOS beta3. That should take maybe two weeks.

    I have found some bugs on beta2:
    • Slave drives are not detected without Master
    • XTIDE Univeral BIOS does not work when system has hard disks controlled by some other BIOSes
    aitotat: thanks for the hard work on this. some pretty nice improvements it looks like. lots of stuff i'd have love to do myself if i had a little better knowledge of assembly.

    i'm going to try your latest beta. dude if you get el torito cd-rom booting work, i want to have your children. even though it won't do anything else, it would give me a chuckle to boot an XP CD-ROM and at least see "the setup is analyzing your hardware configuration" message on a 25 year old computer... before it locks up.
    sigpic

    Comment


      #17
      Originally posted by Mike Chambers View Post
      aitotat: thanks for the hard work on this. some pretty nice improvements it looks like. lots of stuff i'd have love to do myself if i had a little better knowledge of assembly.

      i'm going to try your latest beta. dude if you get el torito cd-rom booting work, i want to have your children. even though it won't do anything else, it would give me a chuckle to boot an XP CD-ROM and at least see "the setup is analyzing your hardware configuration" message on a 25 year old computer... before it locks up.


      EDIT: another idea i've been kicking around is looking into embedding a minimal FreeDOS that could be used as an alternate boot option. kinda like the way the tandy 1000hx embedded DOS 2.11. beat that boot time, vista.
      sigpic

      Comment


        #18
        Beta3 is finally released!

        Here are the changes since beta2:
        • BIOS configuration and flashing program finally available
        • No more conflicts with other hard disk BIOSes
        • Slave drives should now be detected without master
        • Timeouts now use system timer
        • Variables can now be located to top of base memory
        • Completely rewritten interrupt handling
        • Minor optimizations to 8-bit transfers
        • CTRL can be held down to skip initialization
        • Late initialization to fix compatibility issues with old systems


        Configuration program is a bit slow on XT systems. It uses BIOS functions to print single character at a time. I need to rewrite my print library functions sometime to speed things and to support colors. EEPROM Software Data Protection is enabled by default since new XTIDE cards should come with Atmel EEPROMs. Disable SDP if you have SEEQ EEPROM. SEEQ does not support SDP so data verify fails when SDP is enabled. It is safe to use larger page sizes for faster flashing. 7.16MHz V20 is fast enough for 4-byte pages but not larger. 16MHz 286 easily handles 64-byte pages (largest possible). SEEQ does not support 64-byte pages (32-byte works fine).

        BIOS variables can now be located to top of base RAM and it is the default setting. It will steal 1kB of base RAM but it ensures that nothing accidentally corrupts BIOS variables. Top of interrupt vectors (30:0h) can be used if necessary. All Tandy 1000 models with 640kB or less RAM require that top of interrupt vectors are used.

        Late initialization is how i fixed the Tandy problem i mentioned in my last post. Late initialization detects drives when main BIOS calls boot loader (int 19h). This will ensure that all main BIOS functions are available. Late initialization is default on XT builds while AT build defaults to early initialization.

        Edit:
        I almost forgot: Initialization can be skipped by holding CTRL down. This is useful if something goes wrong and the system won't boot otherwise. XTIDE Universal BIOS boot loader is always installed when late initialization is used. CTRL will skip all the rest (drive detection, int 13h revectoring etc) but XTIDE Universal BIOS boot loader is still used for booting.
        Last edited by aitotat; December 17, 2009, 10:28 AM. Reason: Forgot that CTRL skips initialization

        Comment


          #19
          Originally posted by Mike Chambers View Post
          that way, it would be possible to load MS-DOS on something other than a 360 KB disk in an XT.
          If i understood correctly, the only thing you want is to replace 360kB Diskette Parameter Table with other disk type? HD support would require HD controller, HD drive and HD BIOS so the only useful thing i could do is to force BIOS to report 720kB drive correctly.

          Is that what you mean? It should be easy and DOS should then be able to format 3.5" DD diskettes as 720kB and not 360kB.

          Comment


            #20
            Finally had some time to test microdrives. I tested following microdrives with XTIDE Universal BIOS beta3:
            Hitachi, 6 GB (model: HMS360606D5CF00)
            Seagate ST1.2 Drive, 4 GB (model: ST64022CF)
            Magicstor, 4 GB (model: GS10040A-11 47)

            Hitachi and Seagate work fine, just like any CF card or hard disk.

            Magicstor does not work properly for some reason. I can create partitions and format them. Formatting is a lot slower than with Hitachi or Seagate. Booting does not work with Magicstor. Boot sector is found but system freezes before any DOS strings. Same thing happens on a 486 with Award BIOS and large drive support. This means that there is something odd about Magicstor drive itself. It does work fine with a CF-to-USB adapter that i have.

            Microdrives seem to be good drives as long as you avoid Macigstor drives. Microdrives are silent, have good transfer rates (they are faster than ISA can handle) and there is no write limit like on CF cards. CF cards have much better seek times since microdrives are real hard disks. Microdrives are a lot cheaper than CF cards with same capacity. There are lots of cheap microdrives on ebay: 2.5 to 6 GB models cost 8 to 13 USD with shipping.

            Comment


              #21
              most excellent. if I move forward with my PCjr design (gutting an LPT sidecar and putting XTIDE in there) I will be putting a microdrive into that as well for power requirements and obviously size restraints. Was thinking that I could do a CF slot in the back as well...

              Comment


                #22
                I have some good news and bad news. Good news first:

                Beta 4 is going to have a boot menu with drive number swapping (DOS can only boot from first floppy or hard disk) and optional ROM boot (for systems with ROM Basic or ROM DOS). Hard disk drive numbers can even be swapped when booting from floppy drive A. Menu height can be configured and that info at the bottom can be hidden.

                Bad news is that the boot menu takes much more space than i had hoped. I think there will be enough space left for HD floppy support for XT builds and EBIOS support for AT build. There are definitely not enough space for both of them at the same time. This is not a big problem since EBIOS support is quite useless on XTs and ATs already have HD floppy support. There likely won't be enough space for other features either (BIOS partitions, CD-ROM boot etc). I suppose it might be possible to compress most of initialization and boot menu code and then decompress and execute them from RAM. I hope there are some suitable free compression libraries.

                Beta 4 will have block mode transfers and i'd like to include cylinder limiting as well.

                Comment


                  #23
                  This is excellent news. I think the boot menu is extremely useful on these old machines, so I'm happy that it is now available.
                  Have you tested this out on a tandy machine that may boot up in 40 column mode? It looks like your menu should just barely fit!

                  Anyway, I plan on burning your BIOS onto all of the production level eeproms for the XTIDE, starting in about a week, so the clock is ticking to get a working release! (no pressure eh?)

                  Comment


                    #24
                    Forgive me for not being perfectly up to date - I try, but there is a lot of activity ..

                    Is the BIOS available for download somewhere? I have a few reasons for asking:
                    • The existing versions that I have on my card work well enough, and I would like a snapshot of the source code.
                    • I want to have access to a version that only does PIO, and does not assume DMA or IRQs. This is the most widely compatible code, and is suitable for other machines.
                    • I'm going to be working with Hargle on the PCjr version of the adapter
                    • I plan on experimenting with a memory mapped version of the adapter for improved speed when doing PIO transfers. (The IDE registers would stay the same, except for the DATA register which I would like to be in memory space, not I/O space.)



                    Thanks,
                    Mike

                    Comment


                      #25
                      Originally posted by hargle View Post
                      Have you tested this out on a tandy machine that may boot up in 40 column mode?
                      Boot menu width is 38 characters (just like configuration program) so it will work fine on 40 column mode. I just tested it on Tandy and it looks and works fine. I'll try to get beta4 released during next week. Cylinder limitation is missing but that should be easy. Boot menu default drive is fixed to 00h (Floppy Drive A) and i want it to be configurable.

                      Comment


                        #26
                        Originally posted by mbbrutman View Post
                        The existing versions that I have on my card work well enough, and I would like a snapshot of the source code.
                        You can have sources for beta3 right away or do you want to wait beta4?

                        I plan on experimenting with a memory mapped version of the adapter for improved speed when doing PIO transfers. (The IDE registers would stay the same, except for the DATA register which I would like to be in memory space, not I/O space.)
                        Do you mean adapter with RAM as a transfer buffer or do you intent to map XTIDE Data High register to memory space and keep Data Low in I/O space? Or maybe map both data registers to adjacent memory addresses? Best thing would be to modify XTIDE so that only one 8-bit data register would be needed.

                        Comment


                          #27
                          I'll take whatever you have available right now. Ideally this code is in a repository somewhere so we can see the changes between the releases.

                          The key to performance with the PIO design is to be able to utilize 16 bit transfers .. and we can't use 16 bit transfers with the current design using I/O ports. On these machines an in or out of a word generates two bus transactions to two adjacent port addresses. This behavior would have been fine, except that the second port address that would be generated is in use already.

                          My plan is to change the latches used for the 16 bit data transfers. Instead of using two different ports for hi and low, I would use two adjacent memory addresses. That way a single read word or store word can be used to get all 16 bits. The processor can do a 16 bit read much more efficiently than it can do two 8 bit reads - less instructions are required and it generates the two bus cycles by itself.

                          The other ports would stay the same for compatibility. Only the data port would change. User written software that uses the data port directly would be broken, although it's already broken on these machines because you have to do two different port I/Os to get the 16 bit data. I'm anticipating that the BIOS code to read and write sectors is all that most people care about for these machines, and as long as that code is correct if other utilities don't work it is not a big loss.


                          Mike

                          Comment


                            #28
                            I noticed something about CF-cards and microdrives when testing boot menu and other new features. It seems that not all CF-cards are bootable and some cards do not work properly when other card or drive is present.

                            Here are the CF cards that i have:
                            • 64MB Apacer (no speed rating), not bootable
                            • 256MB Apacer (no speed rating), not bootable
                            • 256MB Apacer Photo Steno II Pro (100x)
                            • 512MB Apacer Photo Steno III (88x), works only as single drive

                            And here are the microdrives:
                            • 4GB Magicstor (model: GS10040A-11 47), not bootable
                            • 4GB Seagate ST1.2 (model: ST64022CF), works only as master
                            • 6GB Hitachi (model: HMS360606D5CF00)


                            So three of the drives cannot be booted. Apparently they intentionally have fixed boot sector that does not actually boot anything (AA55h signature is present). They allow writes to boot sector but no data is actually written. I have no idea why they work that way. I believe there is a way to get them to boot. BIOS reserves one cylinder for diagnostics. It is not needed but i reserve it for compatibility with other BIOSes. Diagnostics cylinder is the last cylinder but if i reserved first cylinder, then boot sector would be located to some writable sector. That would break the compatibility with other BIOSes so I don't want to do that. When I implement BIOS partitions (if there are enough space for it) i'll make sure that it is possible to left some space unused at the beginning of disk.

                            So I have only one fully working CF-card and one microdrive. It is a good thing that the Hitachi is the only 100% working microdrive since it have the best access times of all the three microdrives.

                            It is time to release beta4. It is a bit of rushed release so I hope there are not a lot of bugs. This will be the last beta before first stable release. There might be release candidate version(s) if lots of bugs are found. There won't be any new features before stable v.1.0.0. I will fully release source codes when first stable version gets released.

                            Here are the changes since beta3:
                            • Boot menu with drive swapping
                            • Block mode transfers
                            • Cylinder limiting
                            • Drive detection read errors are now properly detected
                            • A little longer timeout value when detecting drives
                            • Minor optimizations to save some bytes



                            Boot menu
                            Boot menu allows to select hard disk or floppy where to boot from. Drive swapping is enabled by default. It is required since DOS can only boot from first floppy or hard disk drive. It is possible to swap hard disks and boot from floppy drive A. Select hard disk you want as a first hard disk and press F instead of Enter. This is needed so DOS could be easily installed to any hard disk. Boot menu has several settings in configuration program.

                            Block mode transfers
                            This is what is known as “IDE HDD Block Mode” in many BIOSes. I see no reason to disable this so it is always enabled and set to maximum block size supported by drive. Block mode increases transfer rates since more sectors can be transferred per interrupt to minimize any sector handling overhead. It will also help the drive to use cache more optimally.

                            Cylinder limiting
                            Old software (like FDISK on Tandy DOS 3.2) won't work with large drives. Cylinder limiting can make the drive appear smaller than it actually is. This is a temporary solution that will likely be removed when BIOS partitions are implemented. Disk size in MiB can be calculated with following formula: (cylinders * heads * sectors per track) / 2048. There are many programs to detect CHS parameters from drive. For example DOS 6.x has MSD.EXE that can be used to see the CHS parameters so wanted cylinder limit can be calculated.

                            Comment


                              #29
                              I believe there is a bug when 386 or later processor is used and DPTs are stored to top of interrupt vectors (30:0h). Some (most?) BIOSes use top of interrupt vectors as a stack during POST. This doesn't normally matter since stack grows towards lower addresses.

                              It does matter now since boot menu is created to stack. Before releasing v1.0.0_b4 i noticed that the second Disk Parameter Table occasionally got corrupted. This seemed to happen only when stack usage was highest, like when timer interrupt was generated when boot menu selection was being changed.

                              I fixed it by moving stack to top of first 64kB of RAM by setting SS and SP to zero. It works fine on Tandy 1000 SX with NEC V20. It should work with any 286 and below but i think that 386 and later generates Stack Fault exception (since SP underruns to FFFEh where first word is stored). It might not matter if default exception handler just returns so if anyone has 386 or later, please try and let me know if it works.

                              By default 1kB of base RAM is used for DTPs so there is no need to relocate stack. This bug can happen only when ”Reserve 1kB of base memory” is set to N and 386 or later processor is used.

                              Comment


                                #30
                                XTIDE Universal BIOS v1.0.0_RC1

                                Changes since v1.0.0_b4
                                • Fixed 386 (and later) stack exception bug
                                • Stack is relocated for boot menu even if DPTs are not stored to 30:0h
                                • Strings and boot menu are displayed properly on BIOSes that corrupts AH when returning from INT 10h/AH=Eh
                                • L-CHS addressing is now used for <=504MiB drives even if LBA is supported


                                386 stack exception bug is fixed by relocating boot menu stack to 0:7C00h (below boot sector). Stack is now relocated even if 1kB of base RAM has been stolen. It is possible that some other BIOS uses 30:0h so now stack cannot corrupt anything important.

                                L-CHS to LBA translation is slow on 8088/8086. Previously translation was performed for all drives that supported LBA. Now it is only done when necessary. This will slightly improve access times for 512MB and smaller CF cards when slow processor is used.

                                Configuration program (idecfg.com) has been updated too:
                                • Optimized flashing so 8088@4.77MHz is fast enough to flash with Software Data Protection enabled
                                • Quick help can be hidden by pressing F2. This will make menu navigation faster.
                                Last edited by aitotat; January 24, 2010, 06:05 AM. Reason: Forgot to mention that configuration program has been updated.

                                Comment

                                Working...
                                X