I don't see the CX=0860h mentioned above. I am presuming that BIOS drives 1 and 2 are the 3rd and 4th floppy drives, but the question is how do I map a drive letter to them? Is there a DOS int call that allows you to iterate through the drive letters that points to the BIOS drives they belong to?
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
My Floppy Drive Image tool 1.00
- Thread starter alank2
- Start date
I get 0860h now.
I also found this:
This sounds like exactly what I'd want to do, but maybe I'm missing something. One can iterate BL for the drive letters 1-26, but how is this actually useful? If you just subtract "A" from the drive letter to get 0 for A and 1 for B, would that mean that the third floppy drive (2) HAS to be C: ? Could there E: be drive be BIOS drive 2 ?
I also found this:
This sounds like exactly what I'd want to do, but maybe I'm missing something. One can iterate BL for the drive letters 1-26, but how is this actually useful? If you just subtract "A" from the drive letter to get 0 for A and 1 for B, would that mean that the third floppy drive (2) HAS to be C: ? Could there E: be drive be BIOS drive 2 ?
modem7
10k Member
Here is what I make out.
I have a system with three floppy drives, and a hard drive containing one DOS partition.
If I boot to DOS 3.3, I discover that the drive letters (logical drives) assigned by DOS are:
A: = First floppy drive
B: = Second floppy drive
C: = Third floppy drive
D: = DOS partition on hard drive
If I then boot to DOS 5, I discover that the drive letters (logical drives) assigned by DOS are:
A: = First floppy drive
B: = Second floppy drive
C: = DOS partition on hard drive
D: = Third floppy drive
Let's look at the latter DOS situation, where the hard drive partition is C:
I have not used the subject function 44H before, but from what I read in the 'The MS-DOS Encyclopedia' book:
* Logical drive A: - Programmer passes 01h to the function. On return, the carry flag is clear. Returned in the device type field is a value ranging from 0 to 4, or 7, i.e. A: is a floppy drive.
* Logical drive B: - Programmer passes 02h to the function. On return, the carry flag is clear. Returned in the device type field is a value ranging from 0 to 4, or 7, i.e. B: is a floppy drive.
* Logical drive C: - Programmer passes 03h to the function. On return, the carry flag is clear. Returned in the device type field is the value of 5, i.e. C: is a partition on a hard drive.
* Logical drive D: - Programmer passes 04h to the function. On return, the carry flag is clear. Returned in the device type field is a value ranging from 0 to 4, or 7, i.e. D: is a floppy drive.
* Logical drive E: - Programmer passes 05h to the function. On return, the carry flag is set, and in AX is 2, indicating 'invalid drive'.
* Logical drive F: - Programmer passes 06h to the function. On return, the carry flag is set, and in AX is 2, indicating 'invalid drive'.
And so on.
What drive number to use in INT13H functions ?
According to the pointed-to Microsoft Q62571 article:
- The bit about subtracting "A" (or 1) only applies if function 44H indicates that the logical drive is a floppy/diskette type.
- Therefore, for A:, a floppy drive, the drive number to use in INT13H functions is 0 ("A" - "A" = 0).
- Therefore, for B:, a floppy drive, the drive number to use in INT13H functions is 1 ("B" - "A" = 1).
- Therefore, for C:, a partition on a hard drive, step 3 in Q62571 needs to be followed.
- Therefore, for D:, a floppy drive, the drive number to use in INT13H functions is 3 ("D" - "A" = 3).
If that is correct, then presumably, if the drive number of 2 was passed to INT13H, INT13H would indicate an invalid drive.
modem7 I appreciate the detailed work through!
>- Therefore, for D:, a floppy drive, the drive number to use in INT13H functions is 3 ("D" - "A" = 3).
That is just it, wouldn't the BIOS have floppy drives 0, 1, and 2 ? Why would the BIOS see its third floppy drive as 3 just because DOS chooses to locate it after the hard drive instead of before it?
Also, why iterate using the function at all if one is just going to always subtract 'A' from it anyway leaving. (except for determine which letters are floppy drives and which are not)
It would make more sense to me if the Q62571 said to iterate the function and build a new list of floppy drives (in order 0 for the first encountered, 1 for the second, 2 for the third, and so on) by skipping hard drives that are in the way, but that isn't what it says.
>- Therefore, for D:, a floppy drive, the drive number to use in INT13H functions is 3 ("D" - "A" = 3).
That is just it, wouldn't the BIOS have floppy drives 0, 1, and 2 ? Why would the BIOS see its third floppy drive as 3 just because DOS chooses to locate it after the hard drive instead of before it?
Also, why iterate using the function at all if one is just going to always subtract 'A' from it anyway leaving. (except for determine which letters are floppy drives and which are not)
It would make more sense to me if the Q62571 said to iterate the function and build a new list of floppy drives (in order 0 for the first encountered, 1 for the second, 2 for the third, and so on) by skipping hard drives that are in the way, but that isn't what it says.
modem7
10k Member
First, my post #23 is simply my take. I have never had to write a program that interfaces with a third or fourth floppy drive.
But I know that the BIOS has no idea what the OS is going to do, and it doesn't need to. For all the BIOS knows, the OS that will be loaded is named RAYDOS and the users of RAYDOS use something else other than alphabetical letters to interact with drives, and hard drives always come before floppy drives.
And I know that the BIOS is very fixed. See the diagram at [here]. For example, if I only have one floppy drive in my IBM 5150, and I accidentally put it in as physical 1 instead of 0, the BIOS is not designed to cater for that by dynamically remapping the drive as physical 0. Having the floppy count switches in my 5150 set for one drive, DOS is going to assign A: to physical 0 (which doesn't exist) and because of the floppy count switches, think that physical 1 does not exist.
And in a 3-drive scenario, I could have one 'internal' drive connected as physical 0, and two 'external' drives (physicals 2 and 3). I would set the floppy count switches to one, so that DOS doesn't expect a physical 1, and use DRIVER.SYS to support physicals 2 and 3 (and note that I would need to inform each instance of DRIVER.SYS of which physical drive it is to support).
There is no flexibility at the hardware level and no flexibility in INT13H.
DOS is a different story.
modem7
10k Member
Maybe I want to write a hardware information gathering program. One of the menu items is 'Drives' and when the user selects that, a list of DOS drive letters (logical drives) appears, showing the user certain information for each drive letter.
A: = 360K floppy drive
B: = 360K floppy drive
C: = Hard drive
D: = 1.44M floppy drive
And in writing such a program, I would certainly need to cater for the fact that different versions of DOS can use different logical-to-physical drive mappings.
I totally get that.
What I am thinking about doing is just adding the ability to support 0: through maybe 7: as well just for the DOS version which would use BIOS drives 0-7 so the user could reference them by drive letter or drive number. Then I don't have to mess around with trying to determine which drive letter might go with which drive. I'll have to think about how the WIN32 version might possibly accommodate something like that too.
modem7
10k Member
But if you are giving the user the option of referring to floppy drives by drive letter (i.e. logical drives), don't you then have to inquire of DOS what physical that corresponds to ?
For example. The situation is as follows:
If I boot to DOS 3.3, I discover that the drive letters (logical drives) assigned by DOS are:
A: = First floppy drive
B: = Second floppy drive
C: = Third floppy drive
D: = DOS partition on hard drive
The user of your floppy imaging program forgets that the third floppy drive is C:, not D:, and asks to perform an operation on D:. It would be good if your program responded with something like, "D: is a hard drive, not a floppy/diskette drive."
And if the user correctly pointed to C:, how would you know which of the following is the situation:
Scenario 1 - A: = physical floppy drive 0, plus B: = physical floppy drive 1, plus C: = physical floppy drive 2 (i.e. program to use drive number 2 in INT13H functions)
Scenario 2 - A: = physical floppy drive 0, plus B: = physical floppy drive 1, plus C: = physical floppy drive 3 (i.e. program to use drive number 3 in INT13H functions)
I would love that solution, but I'm not confident that there is a way to accomplish it. The Q article (was that a MS document?) had a method that to me doesn't make any sense. Maybe I am misunderstanding, but they essentially said you could query to find out which drive letters are floppy drives and which are hard disks. That part makes sense. The part that doesn't is that if drive D: says it is a floppy they say to subtract A: from it to get 3, but that is obviously wrong if C: was a hard drive and D: for a third BIOS floppy drive (2). It would have made sense if they said to count up the BIOS floppy drive number for zero for every drive that indicates that it is a floppy, but that is not what they said. If I'm wrong please tell me as I'd love to go this route if I could trust that a drive letter was truly matched up with a BIOS floppy drive.
My workaround/alternative is to leave the current system in place A:=bios drive 0 and B:=bios drive 1. Then add 8 new drive _numbers_ using 0: through 7: which simply don't refer to a drive by drive letter at all, but instead by the BIOS drive number. So if you know your drive is BIOS drive 2, you would use 2: .
krebizfan
Veteran Member
The undocumented way would be to look at the list of lists (Function 52h) and go through the chain of each DPB and see what values are there. It might be more reliable if certain drivers are in use which cause the drive letters to have an unusual order.
Function 32h gives the DPB for a specified drive.
Function 32h gives the DPB for a specified drive.
Chuck(G)
25k Member
Unfortunately, there's no guarantee of a 1:1 mapping of drive letters to BIOS unit numbers. This cart can be upset by drivers being assigned a letter (e.g. DRIVER.SYS or any other floppy driver). There's also ASSIGN, etc... to mess things up.
Here is a version that allows specifying the BIOS drive using 0: through 7: as well. It calls itself 1.05-test1. It is probably a good idea to verify the drive number goes with the correct drive - this is easily done by running something like:
FDIMAGE 2:
Which will just try to read the disk for BIOS floppy drive 2.
The 32-bit versoin *might* work under Windows9x (maybe 98 that was mentioned in a link above), but it won't work under NT as the interface there is to open the drive letter A: and B: and so there is no way to specify BIOS drive 0-7. You can still specify 0: or 1: for NT on the 32-bit version and it will translate to opening A: or B:.
Really I'd like to see how this does in DOS with the DOS version using 0: - 7: so anyone with 3 or 4 drives would be able to test it.
FDIMAGE 2:
Which will just try to read the disk for BIOS floppy drive 2.
The 32-bit versoin *might* work under Windows9x (maybe 98 that was mentioned in a link above), but it won't work under NT as the interface there is to open the drive letter A: and B: and so there is no way to specify BIOS drive 0-7. You can still specify 0: or 1: for NT on the 32-bit version and it will translate to opening A: or B:.
Really I'd like to see how this does in DOS with the DOS version using 0: - 7: so anyone with 3 or 4 drives would be able to test it.
modem7
10k Member
I'll give it a go.
modem7
10k Member
Also modem7, if you get a chance, try the compression on the 5160. Unlike most compression, it should NOT bring the system to a crawl. You'll feel a difference between it and making an uncompressed image, but it shouldn't be the end of the world. I tried to carefully construct it as to maximize performance while still being workable on 8088 class machines. It is all written in C too, so no optimizations in ASM. I ran it on my 7.16 Mhz T1100plus (8086) and it ran pretty well.
modem7
10k Member
IBM 5160, no EMS, floppy drive is a 360K one. Diskette used was a 360K one.
C:\>fdimage a: ---> took about 35 seconds.
C:\>fdimage a: fred /r --> took about 1:36.