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

8 bit IDE (XTA) Replacement Project

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

    Originally posted by vwestlife View Post
    After nearly missing the flaming tip of an exploding tantalum capacitor that shot across the room like a firework the first time I powered it on, I got the VTI/MiniScribe card connected. One odd thing is that it doesn't spin up the drive until the ROM initializes. It recognized my Seagate ST-325X drive as a MiniScribe 8425XT, but aborted with an error when attempting to format it. It didn't recognize my WD 93208X drive at all, and didn't even spin it up.

    There are a few MiniScribe IDE-XT drives on eBay, but with only vague descriptions and no photos; maybe I'll see if any of them will take a lowball offer.
    I guess on the plus side, explosions make it very easy to locate the bad cap.

    Those are some interesting data points. I don't even know how it would prevent the drive spinning up. Holding the reset line maybe. At some point during testing I will try the VTI/MiniScribe BIOS in my XTA board.

    Comment


      Originally posted by Eudimorphodon View Post
      I would probably say it would make more sense to have this drive replacement have an internal table of as many drive geometries as you can possibly find and allow the user to select which one it emulates by matching the model number to their current (dead) drive than doing this scattered "sparse sectors" thing. You could do this by providing a simple program that would write configuration information for the MCU to the SD card (or whatever) from a desktop or laptop PC.
      This is surprisingly difficult. I have been digging into this for a while and am still not sure what the actual drive parameters are for the 3 hard drives I have. I *think* I know the correct parameters for the ST325X with its current jumper configuration because it came attached to an ST05X card and I have pulled the parameters from its BIOS. But even that drive has a jumper for configuring it for use on other machines and I don't know what that does.

      Things get more complicated with other drives. My WD drive has a "translation" jumper which presumably configures it for a different set of parameter tables. However nether of the two sets of parameter tables in the WD BIOS I disassembled match what I got from the BIOS of the machine I pulled the drive from (a Tandy 1000 TL/2).

      Things get even more messy with the ST351 A/X. Even ignoring the AT mode settings, it has a lot of options. I have not been able to make much headway into characterizing exactly what they do. The only reason I was able to configure it to work with my ST05X card was because I found a Tandy fax-back doc saying to use a specific jumper arrangement I had not seen elsewhere. If I use the settings from stason.org or other Tandy docs, the drive does not work correctly with the ST05X. On one setting I tried, the drive was not detected at all. On another, the drive started hammering the heads continuously. Just for fun, the ST351 A/X comes in two varieties, one with a 12 pin jumper block, and another with an 8 pin jumper block.

      Even if I can figure all this out, it seems like a high burden to put on anyone trying to configure the device. There is also no guarantee that the vintage PC is using optimal geometry. I suspect that my TL/2 is wasting a head (using 4 instead of 5), and so the image that computer wrote would not be readable on another computer even if I matched the WD geometry perfectly.

      I think a good start is a default that works for everything but the SD card can't be used in other machines. A jumper config for a few known BIOSes would be doable. I am still concerned that the landscape is so confusing that most folks will not be able to get an SD card that works in their modern PC. I think the experience might be better if we just say up front that nope, the primary SD card won't work in another computer without reinitializing.

      I was thinking I might do a a more complex translation where the first part of an SD card is configured for 5 heads / 17 sectors / 1024 tracks, then anything outside of that range is located later on the SD card. This will match some common 40MB drive parameters and so in some cases the SD card will be readable on another PC. Unfortunately I think it mostly just covers the Seagate and WD hard card BIOSes which are the weakest use case for this project. I have considered something that runs on the vintage PC to pull the parameters from the actual parameter table being used and store them to an unused sector towards the end of SD card. The tricky part of this is that it has to happen before fdisk runs. Maybe there could be an optional tool that could be run before fdisk to change the base parameters for the translation I just described. I think I can implement it in a way that even if something goes wrong with the parameters, the SD card will still work fine in the vintage PC that fdisk-ed it.

      It is all configurable in software of course and could be changed later. First pass will be one fixed CHS translation method to the primary SD card. Next on my priority list is probably boot-floppy-image-via-MBR-injection because that sounds super fun. Then device driver support for the second SD card as a hard drive. Somewhere along the way I am going to lose interest. Not before there is something working with any luck.

      The main outcome of these thoughts is that I am putting the second SD card connector back and I should probably add a few more dip switches. When I thought the OnTrack MBR injection would work well, I removed the second SD connector from the drive and I was looking at cutting back on the dip switches to save an IC.

      Originally posted by Eudimorphodon View Post
      So far as preconfiguring goes, given the hulking power of the MCU you're planning to use and the fact you're already having to deal with geometry translation (vs. what XTIDE does, which is just use the native LBA geometry of the attached IDE/CF device) it might be worth considering doing disk image files instead of using the storage media "raw". There are utilities (or built-in OS facilities, depending on what you're using) for mounting disk images and raw images can also be attached to emulators, so doing this could eliminate the need for bizarre workarounds for bootstrapping on the machine you're using it on, and you could also provide a facility for switching between disk images. This would mean that even if you *were* limited to 40MB or whatever it'd be simple enough for the user to switch between a "Games" image, an "Apps" image, whatever.

      (Doing disk images on a FAT32 or whatever formatted SD card or USB stick would also simplify that "configure me to look like a ..." step; the program to do that could literally live on the storage media, along with the config file it generates.)
      I did originally plan to use .IMG files. I do love the ability to make an image in PCem and very much wish it was easier to move them to a vintage PC. If I could make the process robust (I think that means, override the drive parameter tables), I would be quite for that. Otherwise it gets pretty fragile and not much fun. Even using XTIDE it can be challenging to share drive IMG files. And XTIDE has full control over the parameter tables. Something that could be added later if I/someone is motivated and there is demand.

      I do think I could potentially support HD IMG files on the second SD card via a driver. It occurs to me now that I could also boot a floppy image located there. Maybe even cycle floppy images so a clean DOS install is possible.

      Comment


        Another strategy if you really want to just assume the worst about the know-ability of drive parameters would be to analyze the commands you receive during a format operation and derive your LBA-to-CHS mapping on the fly. Or even simpler, maybe? Have the size and geometry be undefined until an MBR and partition table is written. With classical DOS won’t the start and endpoints of the partitions be written in CHS format? Once you have an MBR written to the disk it seems to me like you should be able to derive the correct CHS to LBA translation from it.
        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

        Comment


          Originally posted by Eudimorphodon View Post
          ... one more note about abstracting the disk as suggested above: if you really also want to support larger volumes than the system BIOS supports if you go with the disk image idea this may become trivial, as long as it's not a hard requirement you be able to boot from them. (IE, they'd have to be drive D or whatever. You'd still have a bootable C.)

          A simple block device driver for MS-DOS can be *extremely* tiny; you mentioned Tandy 1000s, well, the driver that a Tandy 1000 HX loads (as a BIOS extension) to access its ROM drive fits in 512 bytes. You might object this is read-only, but also going with oddball Tandy-isms, there was a rare-er version of the Tandy Plus Bus memory expansion card that could hold 512K of RAM instead of 384k. The extra 128k, if enabled, was mapped into the UMB space and Tandy provided a driver to use it as a RAM disk. (I've run this driver on my homebrew expansion cards for these systems.) It also is well under 1K resident, and it of course is read-write. Just spitballing here, but I'm thinking if you set up your drive substitute so it could use "illegal opcodes" sent to the command register as a hidden API you could, in addition to emulating the 40MB or whatever "real" XTA drive, enable it to support one or more "soft" drives which could be of arbitrary size (up to the max that FAT16 supports with DOS 5+, presumably) just by loading a tiny driver in config.sys.
          I did some reading a couple of days ago on block drivers. I do think I can make it fairly small. Maybe not as low as 512 bytes resident but you have given me a target. There needs to be enough code to directly communicate with the drive. Probably not very large actually if I skipped DMA/IRQ and just use polled IO. I do enjoy a good REPNZ. There also needs to be space for the BPB's for each partition (described here: https://jdebp.uk/FGA/bios-parameter-block.html). The FAT16 partitions need about 64 bytes per partition. What I am thinking is to have the drive to parse out the partitions so the block driver just has to read a array of BPB's from the drive. With any luck the fatfs library already has robust partition parsing that I can leverage. The range of possible MBR's and BPB's seems to be quite extensive. Even if I have to write the partition parsing code myself, this kind of stuff is so much easier in 32 bit. I wrote something in Turbo C++ 3.0 for DOS recently and I was constantly dealing with challenges related to16 bit ints/sizes.

          I would prefer to just throw the entire secondary SD card at DOS and let DOS figure it out. I just don't know if there is a way to tell DOS there is a new hard drive in the system by the time a device driver runs. I am thinking not. Maybe it would work well enough to at least let fdisk initialize the drive.

          Thanks for the info on the HX ROM drive. I was curious how that works. For what I want to do with floppy images, I don't know what OS is booting so I don't think I can do anything too specific to hook in a custom driver. That is really why I plan to use a floppy image rather than a hard drive or block device image. My plan is something like:
          • If the "boot floppy image" button is pressed, rather than load sector 0 from the SD card, return a custom boot loader.
          • The custom boot loader detects the drive, loads some disk IO code high in base memory, reduces the BIOS memory size so the disk IO code does not get overwritten, then tells the BIOS to execute its bootstrap code again.
          • The disk IO code would hook int 13, overriding drive A: access to instead read from the floppy image.
          I think this will work. It will certainly be a lot of fun to try.

          What you describe there with the additional opcodes is exactly what I had in mind for access images or the secondary SD card. The only slight concern is that if I use an undocumented opcode, I might accidentally hit an undocumented operation on a real hard drive. My "identify yourself" command might be another drive's "factory intialize". I know, running an XT MFM hard drive or second XTA drive next to a solid state replacement is a little out there, but I think it should work/be safe. What I plan to do is issue a read from a definitely-out-of-range sector and see if the drive returns data containing a fingerprint. Hmm, I wonder if a high cylinder number could smash heads. So maybe cylinder zero with an out of range head and sector might be more safe.

          Comment


            Originally posted by Eudimorphodon View Post
            Another strategy if you really want to just assume the worst about the know-ability of drive parameters would be to analyze the commands you receive during a format operation and derive your LBA-to-CHS mapping on the fly. Or even simpler, maybe? Have the size and geometry be undefined until an MBR and partition table is written. With classical DOS won’t the start and endpoints of the partitions be written in CHS format? Once you have an MBR written to the disk it seems to me like you should be able to derive the correct CHS to LBA translation from it.
            Thanks for all the feedback / ideas. I am enjoying the conversation.

            I did look into the above a little. It does not appear that the MBR contains CHS info. The per-partition BPB from DOS 3.0 and later does have heads and sectors fields which are the important ones. I think those fields are optional and I am not sure whether they are always set. I don't understand why this info is not in the MBR instead - it seems far more useful there. If the the CHS is not known from the get-go, how are BPB's loaded in the first place? Maybe the first BPB is always within the first track/head and that is good enough. It is interesting - this information would allow the hard drive to be read even if moved to another PC with different parameter tables. Maybe that is what the information is for. It stills seems like it belongs in the first sector (the MBR).

            There is a bit of a tricky timing problem with trying to process this automatically. It should be robust to diagnose the partitions and BPB's after partitioning is done / system restarted. By that time a bunch of sectors have already been written. At this point it would probably be safest to have an explicit tool or other way to trigger the drive to reorder the sectors. I was going to suggest this option in an earlier reply but I don't want to write it. A tool to set CHS before running fdisk - I might be up for implementing that.

            Comment


              The docs here:

              https://wiki.osdev.org/Partition_Table

              Say that the information for the four primary partitions supported by MBR format boot records are stored in a 64 byte data structure stored in the first sector of the hard disk, and that three bytes of each partition record are the CHS info for the ending cylinders/head/sector. It also says for drives smaller than 8GB this should match up with the LBA representation. So I would think if this is accurate simply creating a partition the maximum size supported by the BIOS for the drive should give you a partition table entry that contains the maximum cylinder, head, and sector count? This is literally only one sector’s worth of data you need to parse to decide on the optimal geometry to accommodate the actual format, which will not follow immediately. (You need to reboot after an FDISK.)

              Edit: of course I can't say I've ever written my own OS for x86 hardware from scratch, not even close, so maybe these docs are way off, but... I haven't seen anything that says the CHS values are "optional".

              Another point about targeting disk images instead of trying to directly map to partitions on the underlying storage is that your strategy of a "sparse" mapping could certainly be done in a "temporary" image file used for the inital FDISK and formatting, and then based on what the controller logs as the maximum observed CHS values you could A: compress the image, and B: update your config so future disk image initializations can use compact translation in the first place. The compression step could happen either in situ or by popping the card into a reader and running a utility, whatever is easier.
              Last edited by Eudimorphodon; October 22, 2021, 10:23 PM.
              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

              Comment


                Originally posted by Eudimorphodon View Post
                The docs here:

                https://wiki.osdev.org/Partition_Table

                Say that the information for the four primary partitions supported by MBR format boot records are stored in a 64 byte data structure stored in the first sector of the hard disk, and that three bytes of each partition record are the CHS info for the ending cylinders/head/sector. It also says for drives smaller than 8GB this should match up with the LBA representation. So I would think if this is accurate simply creating a partition the maximum size supported by the BIOS for the drive should give you a partition table entry that contains the maximum cylinder, head, and sector count? This is literally only one sector’s worth of data you need to parse to decide on the optimal geometry to accommodate the actual format, which will not follow immediately. (You need to reboot after an FDISK.)
                OK, I did some experimentation in PCem, and yeah, I think this will work most of the time. Cool. It does appear that the MBR is the first sector written during a fresh install (I tested using the DOS 6.22 install disks). DOS did write the max head and sector count into the end sector. For for some reason DOS dropped the last cylinder but that is not important. I am just going to hardcode for 1024 cylinders. I don't know if this approach will be correct in all cases - 32 meg partitions with DOS 3.3 might not work for example. I could use the 32 bit LBA values to confirm the translation is working correctly. Maybe that is not even necessary - if I get the CHS values wrong, I am still no worse off than I was before - any writes to heads/sectors out of range will still be translated to be written to later locations on the SD card. Probably the better option in the case where the 32 bit values do not match the CHS values is to use them to infer a CHS.

                I was thrown by some of this for a little while. I have been disassembling what I thought was a DOS MBR and the format does not match the published MBR formats. I was using the first sector I extracted off one of my XTIDE CF cards. I think I got the first sector of the first partition, not the first sector of the drive. Starting over with PCem, all makes more sense now.

                It turns out there is no need to disassemble any MBR's. Someone has done a thorough job of analyzing them: https://thestarman.pcministry.com/asm/mbr/index.html

                Comment


                  Does anyone have a Tandy 1100 HD they could dump the BIOS from? I would like to learn a bit about the little Connor 2.5" XTA drives. I tried the Tandy 1100 FD and Panasonic BP150 BIOSes but no luck. I did fund some hard drive parameter tables but they are quite small. I think they must be for ROM drives.

                  Comment


                    Originally posted by JayesonLS View Post

                    ... I don't know if this approach will be correct in all cases - 32 meg partitions with DOS 3.3 might not work for example. ...
                    So I tried it on DOS 3.3 with a 40 meg type 17 drive (5 heads, 17 cyliders) and it did indeed end the primary 32 meg partition at the end of cylinder (head & cylinder = max). Nice!

                    Comment


                      Originally posted by JayesonLS View Post
                      So I tried it on DOS 3.3 with a 40 meg type 17 drive (5 heads, 17 cyliders) and it did indeed end the primary 32 meg partition at the end of cylinder (head & cylinder = max). Nice!
                      I vaguely recall from a book I had ages ago about DOS disk layouts/repair/etc. that DOS always used cylinder boundaries for partitions, even in versions where in FDISK you specify the size in "megabytes". (It gets rounded to the closest cylinder.) You might want to double check that but, yeah, that's why I was thinking this strategy should work. And I agree with just making the cylinder count the maximum no matter what because, yeah, the absolute size doesn't matter for the LBA/CHS translation algorithm, you just need the correct heads/sectors count. Unused bytes at the end aren't really going to matter regardless of if it's an image or raw storage.

                      An idea that doesn't even depend on FDISK came to me this morning: I use a simple multi-boot manager called bootmgr to switch between several different DOS versions on my Tandy 1000; it's a really tight little piece of code that fits a simple partition selection menu into the teeny amount of code space available in the MBR, in place of the standard code that just finds and loads the boot sector from the active partition. It doesn't look to me like there's anything in the MBR proper that cares about geometry, it just has this rigid structure of having space for a blob of code that's loaded, and it's up to that code to figure out the next step. So...

                      How about this? You set up the firmware of the device so if it's uninitialized any boot attempt (IE, a read of sector zero) is answered with a synthetic MBR that contains a code payload that when loaded simply looks at the BIOS Fixed Disk Parameter Table to figure out the size of the disk (maybe print this on the screen for future reference) and then makes an INT13h call to read the last logical sector on the drive? (Actually, won't even need the FDPT for this, the INT13h AH=08h call has the info we need in it?) Your drive can then autoconfigure itself based on that bogus sector read attempt because you'll know it'll have the highest value for all three parameters. On the drive end the "configured" flag gets set, the MBR code reboots the PC, and bam, your drive matches whatever the BIOS is set to perfectly.

                      The source code for bootmgr is available, you could probably use it as a starting point.
                      Last edited by Eudimorphodon; October 23, 2021, 07:14 AM.
                      My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                      Comment


                        Originally posted by Eudimorphodon View Post

                        How about this? You set up the firmware of the device so if it's uninitialized any boot attempt (IE, a read of sector zero) is answered with a synthetic MBR that contains a code payload that when loaded simply looks at the BIOS Fixed Disk Parameter Table to figure out the size of the disk (maybe print this on the screen for future reference) and then makes an INT13h call to read the last logical sector on the drive? (Actually, won't even need the FDPT for this, the INT13h AH=08h call has the info we need in it?) Your drive can then autoconfigure itself based on that bogus sector read attempt because you'll know it'll have the highest value for all three parameters. On the drive end the "configured" flag gets set, the MBR code reboots the PC, and bam, your drive matches whatever the BIOS is set to perfectly.
                        I have thought about something quite similar to this. It gets back into the issue of not getting the drive parameters until after the drive is initialized. In this case, the drive is likely already partitioned and has DOS installed. It is certainly possible to reindex the SD card at this point - I am just trying to avoid it. It is the kind of thing that is likely to have bugs and is time consuming to test thoroughly.

                        I was thinking that it would be an OK user experience if the MBR code prompted the user on whether they would like to reindex the drive. But I think there is a concern that someone might move the drive to another machine. At this point it could blindly reorder the sectors on the SD card into something unreadable on any PC. I think the safer approach if re-indexing were implemented would be to trigger it from a command line tool so that chkdks/scandisk could be run beforehand to be sure the SD card is reading correctly.

                        I think re-indexing may be unnecessary anyway. Your idea of sniffing the MBR writes should get the CHS translation correct the vast majority of the time.

                        Fitting that boot manager into an MBR sector is pretty impressive. You don't even get 384 bytes to play with after accounting for the partition tables. I may have a read sometime to see how it was done.

                        Comment


                          I did a schematic and layout for the 3.5" XTA variant of the drive. It is designed to fit into an inexpensive, metal 3.5" to 2.5" drive adapter. I decided against putting and IBM edge connector on the other end to keep things simple and the board small.

                          The Pico has very high switching speeds so I went with a 4 layer board. My first one. Ground planes on the outside made layout and coupling very easy. Hopefully I don't need too many bodges because those are going to be difficult!

                          XTA-35-TH.png
                          The image options seem to be this tiny medium version, or an enormous large version. Click the image for more detail I guess.

                          Comment


                            Originally posted by JayesonLS View Post
                            I have thought about something quite similar to this. It gets back into the issue of not getting the drive parameters until after the drive is initialized. In this case, the drive is likely already partitioned and has DOS installed. It is certainly possible to reindex the SD card at this point - I am just trying to avoid it. It is the kind of thing that is likely to have bugs and is time consuming to test thoroughly.
                            The solution I was suggesting wasn’t for a “reindexing” scenario, it would only be invoked if the drive were blank, IE, you’ve inserted an empty card if you’re writing directly to it, or if you’re using images the user has indicated they want to start a new one. (Presumably you maintain some kind of metadata to definitively know if you’ve touched a disk before if you’re not using image files. Said metadata would also likely include the virtualized CHS parameters currently in effect.) The “fake” MBR that contained the code to get the BIOS parameters wouldn’t be on the disk, it’d be thrown out of the MCU’s flash under that one singular circumstance. And again, for this we don’t need to know the drive parameters to generate it; the BIOS doesn’t care about partitions, it’s just knows enough to throw a read request for sector CHS 0:0:0, load it into memory, and execute the code block.

                            Basically this accomplishes roughly what you get from booting a DOS and having FDISK write an MBR (which you subsequently analyze a partition table entry of for the geometry) except with this idea the disk will configure itself properly even if the user intended to do something really bizarre with it, like, I dunno, run a non-DOS OS that doesn’t use a DOS compatible partition table.

                            If you take a real XTA drive and move it to another machine that’s jumpered for a different geometry drive it’s expected behavior for it not to work, worrying about making drive images automagically reformat for that scenario seems like a heck of a feature creep.
                            Last edited by Eudimorphodon; October 23, 2021, 08:48 PM.
                            My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                            Comment


                              Originally posted by Eudimorphodon View Post

                              The solution I was suggesting wasn’t for a “reindexing” scenario, it would only be invoked if the drive were blank, IE, you’ve inserted an empty card if you’re writing directly to it, or if you’re using images the user has indicated they want to start a new one. (Presumably you maintain some kind of metadata to definitively know if you’ve touched a disk before if you’re not using image files. Said metadata would also likely include the virtualized CHS parameters currently in effect.) The “fake” MBR that contained the code to get the BIOS parameters wouldn’t be on the disk, it’d be thrown out of the MCU’s flash under that one singular circumstance. And again, for this we don’t need to know the drive parameters to generate it; the BIOS doesn’t care about partitions, it’s just knows enough to throw a read request for sector CHS 0:0:0, load it into memory, and execute the code block.

                              Basically this accomplishes roughly what you get from booting a DOS and having FDISK write an MBR (which you subsequently analyze a partition table entry of for the geometry) except with this idea the disk will configure itself properly even if the user intended to do something really bizarre with it, like, I dunno, run a non-DOS OS that doesn’t use a DOS compatible partition table.

                              If you take a real XTA drive and move it to another machine that’s jumpered for a different geometry drive it’s expected behavior for it not to work, worrying about making drive images automagically reformat for that scenario seems like a heck of a feature creep.
                              OK, that makes sense. This is a productive conversation. You have inspired me to change the "Boot Floppy Image" button into a "Boot Menu" button. The setup instructions from the drive would include entering the boot menu an

                              I am thinking the boot menu would be like a terminal connection to the drive so all the logic can be implemented in the drive firmware in modern C++. The code running on the PC would be limited to displaying text, capturing input and a few other actions like "install floppy drive redirect code and run bootstrap.". This opens up all sorts of options. Things like implementing SD card initialization on the drive would become easier to implement. Something like:

                              Code:
                              IntelliDrive Boot Menu - Firmware version 0.1
                              
                              Primary SD card detected (128MB, not initialized)
                              Secondary SD card detected (8GB, FAT32)
                              
                              WARNING: Drive parameters are not configured to match this PC.
                              
                              Select from the following:
                              1. Configure drive parameters (Recommended)
                              2. Configure other IntelliDrive options
                              3. Configure or erase Primary SD card partitions
                              4. Configure or erase Secondary SD card partitions
                              5. Boot from floppy disk in A: drive
                              6. Boot DISK001.IMG floppy image from secondary SD card
                              7. Boot IntelliDrive's included FreeDOS floppy image
                              8. Display installation instructions
                              9. Reboot system
                              
                              Enter 1 to 9: _
                              Last edited by JayesonLS; October 24, 2021, 02:31 AM.

                              Comment


                                In the old days before LBA, all partitions had to start and end on a cylinder boundary. Since the first sector of the first cylinder contains the partition table, the first cylinder itself does not belong to any partition and the remainder of it goes unused. This is the common hiding spot for boot managers (I like XFDisk, which can also boot from floppy, even B: in older versions) or disk managers such as OnTrack. If I remember correctly, the MBR is simply 448 bytes of code followed by 64 bytes of partition table; the code can be anything and is usually written by whatever OS is installed.

                                Personally, I prefer disks behaving like disks - no magic by the BIOS (some IBM BIOSes require a bootable FAT16 partition, breaking Linux installations for no reason) or the devices itself (looking at CF cards doing the same). Operating systems such as Minix or Xenix will likely fail on a DOS-focused magic disk. Especially partition table setup should not be left to the operating system or other system tools, not the disk itself.

                                The "magic boot button" is a good idea. In this mode, the Pico could prove just a single cylinder containing your configuration utility. The actual parameters (either read from the BIOS or set manually) could be set by writing to a magic sector on that cylinder, triggering re-initialization. This approach could avoid needing jumpers on the hardware, since the user can select the desired geometry and jumper setting when configuring (and the Pico could write the settings to a configuration file, either on the SD card or elsewhere, allowing setup on a different system). Since the actual geometry is known, a regular flat image file would be usable as well.

                                Since the boot menu is only shown after the BIOS has finished initializing the whole system (which is different from an Option ROM), the code has access to all BIOS facilities, although staying with the most basic int10h (video) / int16h (keyboard) / int13h (disk) functions may be good for compatibility. No magic would be visible if the button has not been not pressed.

                                Did I miss anything important?

                                Comment

                                Working...
                                X