Page 1 of 1
How MS-DOS/FreeDOS disk drivers work?
Posted: Wed Dec 09, 2015 12:01 pm
by EvolSoft
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
Re: How MS-DOS/FreeDOS disk drivers work?
Posted: Wed Dec 09, 2015 12:10 pm
by BrightLight
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.
Re: How MS-DOS/FreeDOS disk drivers work?
Posted: Wed Dec 09, 2015 8:40 pm
by SpyderTL
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.
Re: How MS-DOS/FreeDOS disk drivers work?
Posted: Thu Dec 10, 2015 7:05 am
by EvolSoft
Thanks for all answers
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?
Posted: Thu Dec 10, 2015 7:19 am
by Muazzam
EvolSoft wrote:[...] We're making a modern DOS like [...]
*I.
Re: How MS-DOS/FreeDOS disk drivers work?
Posted: Thu Dec 10, 2015 8:15 am
by BrightLight
EvolSoft wrote:What does the DPB (Disk Parameter Block) do?
The disk parameter block in the boot sector contains information about the file system. It is essential to create a valid FAT file system.
Re: How MS-DOS/FreeDOS disk drivers work?
Posted: Thu Dec 10, 2015 8:51 am
by SpyderTL
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.