Hi all ,
We're making a modern DOS like operating system and we're trying to implement disk drives. After long searches about DOS and DOS disk I/O architecture on Google we didn't find nothing about DOS disk I/O working.
Our question is: How is the DOS able to read or write data to the disk? Does it use the int 13h of BIOS or does it use custom drivers?
Then how does the DOS recognize the driver linked to the drive letter?
For example if we have:
A: which is a floppy unit
C: which is a disk unit
and D: which is a CD ROM unit
What does the DOS do if we want to write a file on the drive C, for example?
Thanks in advance
How MS-DOS/FreeDOS disk drivers work?
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: How MS-DOS/FreeDOS disk drivers work?
By default, DOS does not support CD-ROM drives. It has a separate driver for CDs and that driver uses real ATAPI commands.
For hard disks and floppy disks, I believe it uses BIOS interrupt 0x13.
As for drive letters, that has nothing to do with BIOS or custom drivers. The BIOS or the driver only reads or writes the sector(s). The OS (more specifically, the virtual file system) is responsible for the drive letters.
If DOS wanted to write to drive C, I assume it would do this:
1) Check if C is a hard disk or floppy disk or CD-ROM, etc...
2) If it is a hard disk (as you have said), it will check if it has a valid file system.
3) Then, it will write the file to the disk using INT 0x13 calls.
How exactly the file is written depends on the file system used (most likely FAT16), which in turn doesn't depend on BIOS.
For hard disks and floppy disks, I believe it uses BIOS interrupt 0x13.
As for drive letters, that has nothing to do with BIOS or custom drivers. The BIOS or the driver only reads or writes the sector(s). The OS (more specifically, the virtual file system) is responsible for the drive letters.
If DOS wanted to write to drive C, I assume it would do this:
1) Check if C is a hard disk or floppy disk or CD-ROM, etc...
2) If it is a hard disk (as you have said), it will check if it has a valid file system.
3) Then, it will write the file to the disk using INT 0x13 calls.
How exactly the file is written depends on the file system used (most likely FAT16), which in turn doesn't depend on BIOS.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: How MS-DOS/FreeDOS disk drivers work?
The BIOS provides functions to read/write sectors, and the OS provides functions to read/write files (using the BIOS functions internally).
The drive letters just make it easier for the user to keep track of which drive they want to access. If you swap your A: drive with your B: drive by swapping their Data cables, then your A: drive would simply become your B: drive and vice versa.
DOS simply assigns floppy drives to drive A: and B:, and then starts assigning hard drives to drive letters after that. All of this happens at boot time, so it probably just creates a 26 element array that contains the drive type and the controller address for each drive.
The "drivers" for IDE drives and floppy drives are built in to the OS, and are always available.
The drive letters just make it easier for the user to keep track of which drive they want to access. If you swap your A: drive with your B: drive by swapping their Data cables, then your A: drive would simply become your B: drive and vice versa.
DOS simply assigns floppy drives to drive A: and B:, and then starts assigning hard drives to drive letters after that. All of this happens at boot time, so it probably just creates a 26 element array that contains the drive type and the controller address for each drive.
The "drivers" for IDE drives and floppy drives are built in to the OS, and are always available.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: How MS-DOS/FreeDOS disk drivers work?
Thanks for all answers
Everything is much more clearer now.
We've got just another question: What does the DPB (Disk Parameter Block) do?
Everything is much more clearer now.
We've got just another question: What does the DPB (Disk Parameter Block) do?
Re: How MS-DOS/FreeDOS disk drivers work?
*I.EvolSoft wrote:[...] We're making a modern DOS like [...]
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: How MS-DOS/FreeDOS disk drivers work?
The disk parameter block in the boot sector contains information about the file system. It is essential to create a valid FAT file system.EvolSoft wrote:What does the DPB (Disk Parameter Block) do?
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: How MS-DOS/FreeDOS disk drivers work?
Back in the day, floppy disks could be formatted in different ways. For instance, you could choose to write more than 80 tracks to a HD floppy drive, meaning you could store more than 1.44 MiB of data, if you wanted. This worked because the disk surface, itself, was just a blank piece of magnetic medium. Think of it as writing outside of the margins on a piece of paper.
The problem is that the floppy drive has no way of knowing how much data was actually on the disk. So the solution was to write a "header" on the disk that would give you all of the disk size information.
This header was carried over to hard disks, and over time, additional information about the structure of the data on the disk was added. File system type, table locations, flags, etc.
Unfortunately, the most logical place to put this header is in the first block, which is virtually guaranteed to exist, but it is also where the initial bootable code is supposed to be located. So, the "header" starts with a single 3-byte field that contains executable code, which usually just jumps to additional code located directly after the header.
The problem is that the floppy drive has no way of knowing how much data was actually on the disk. So the solution was to write a "header" on the disk that would give you all of the disk size information.
This header was carried over to hard disks, and over time, additional information about the structure of the data on the disk was added. File system type, table locations, flags, etc.
Unfortunately, the most logical place to put this header is in the first block, which is virtually guaranteed to exist, but it is also where the initial bootable code is supposed to be located. So, the "header" starts with a single 3-byte field that contains executable code, which usually just jumps to additional code located directly after the header.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott