OSDev.org

Hi all,i'm a newbie in OS development, and i'm now facing a problem to connect to a floppy drivre and view some files on the directory.

I'm now already can boot up and to detect the keyboard input,so what should i do in the next step....???

so, i need all the experts to help....

Thanks.....

Below are the files boot.asm that i already write:
http://www.geocities.com/voonwahwong/boot.asm

i think you need more a search engine than an expert atm.
What exactly do you want to achieve ?

reading more files from the floppy at your bootloader so that you get kernel to load ? see GRUB if that's the case

reading files from the floppy for whatever other reason? see FAT12 to see how the floppy is organized and RBIL to see how you access it.

writing your own pmode floppy driver ? see floppy driver

At your current stage of development might I suggest looking at John Fine's Bootsector as it is a good example of getting information from the root directory of the floppy and loading files from there into RAM.

When you get along further in your OS development you will be using protected mode (I assume) and the BIOS routines (disk keyboard and everything else) will be unavailable. They can be accessed thorugh the VM86 mode but that's another world entirely. In this case you will need your own keyboard code, floppy disk code and FAT format (assuming you use FAT for floppy's).

Floppy disks only have one 'real' directory and it's size is set (about 4 sectors, 255 diectory entries, if I remember correctly).
All other directories are 'logical' in that you take a pointer from the root and go to that pointer and further directories from pointers in that directory. The directory is treated like a file and you can walk through it entry by entry. It can hold files and other directory entries (in order of creation, nothing is sorted). See that FAT12 document in Pype's post.

Most single tasking OS's (DOS/CPM) support a current directory. This is simply a text line such as 'A:\This\That\TheOther\" and a pointer directly to "TheOther" directory. Multitasking OS's have a current directory per application and they can have current directories for saving, loading, components etc.

So in short for the purposes of booting, I'd reccommend sticking to the "Root directory" and when you've got the hang of loading things from that, try your hand at loading things from other directories probably made under your host OS (windows, linux, whatever). A good DOS book such as "Undocumented DOS" goes deep into how DOS manages it's floppy disks.

At the risk of offending those who have written their own bootloaders (and some with good reason) have you thought about using GRUB? (unless your OS is fully 16-bit)

Floppy disks only have one 'real' directory and it's size is set (about 4 sectors, 255 diectory entries, if I remember correctly).

while this is technically correct, i would like to avoid confusion by clarifying:

the size is set at formating time -- it is not a fixed value (though there are common values, and straying from these may confuse some programs, particularly older DOS ones) and should be read from the BPB for each disk

ps: this is not the case for FAT32 -- you must parse the FAT to find the root dir, and the length is variable (meaning it can also be fragmented) though your not likely to find FAT32 on FDDs! ;D

Xardfir wrote: Floppy disks only have one 'real' directory (...) All other directories are 'logical' (...) treated like a file and you can walk through it entry by entry.

What exactly makes a contiguous directory more 'real' than one using the FAT ? And isn't the root directory of a floppy itself made of sectors covered by the FAT too ?

And isn't the root directory of a floppy itself made of sectors covered by the FAT too ?

no its not (iirc)

the first cluster starts after the end of the rootDIR -- except on FAT32 where the rootDIR is covered by the FAT table

Hiya,
What I meant by a 'real directory' is that under FAT 12 and FAT 16 the root directory will always exist. It has to because, as JAAman mentioned, the root directory is Physically defined by the floppy format. All other directories are optional.
DOS only supported the root directory on a floppy disk in version 1. Microsoft came to it's senses in version 2 when it supported multiple directories on those massive 360k double sided floppies. This is where the notion (for the FAT file system) of a common directory came into existence.

So by extension, every application on a multitasking system (Non-DOS) needs to have a current directory structure for each partition on every storage device. When accessing a partition, unless specifically overridden, all file creation, modification and deletion should happen in the current directory within that partition.
So App A might be pointing to C:\Documents, while App B might be pointing to C:\Jellyfish&Onions. Two different applications, two different current directories.

I hope this gives some thought to v.wah for implementing his directory access.

So by extension, every application on a multitasking system (Non-DOS) needs to have a current directory structure for each partition on every storage device.

What is the need for having current directory on each partition. In most of the OS there is only one current directory for each process. Is there anybody who maintains a current dir for every partition?

Xardfir wrote: Microsoft came to it's senses in version 2 when it supported multiple directories...

Why would microsoft only come to its senses at that time? Maybe it was a smart thing to not include directories.

- It doesn't have to be tested, since you don't have directories
- You can instantly list all files
- You don't waste space on the disk for directory information
- You don't waste space for your OS code
- You wouldn't use them anyway, since you can't stuff that many files on the disk in the first place.

What is the need for having current directory on each partition. In most of the OS there is only one current directory for each process. Is there anybody who maintains a current dir for every partition?

A fake dos box under XP has a current directory for each drive, but that's the command line app storing that itself afaik.

@Kemp: We are not talking about Dos box only we are talking about all the processes.Don't we?

Sorry I wasn't very clear (was rather a short post I know). My comment was meant to be taken in several ways:

1) There are programs out there that want this functionality, so it may be useful
2) Those programs that do want it can be told to do it themselves if you don't want to supply it

Basically, it's nice but not required functionality for anything I've seen so far.

Hiya,
I believe the reason that DOS only included directories in version 2 is that
1) Version 1 was basically a version of CP/M with the FAT file system and the system calls moved around. The CP/M file system was patented by Digital Research and supporting similar functions allowed programs to be ported easily.
2) The size of a floppy in the original PC was 320K. Compaq (if I recall correctly) used a drive capable of 360K. There was also the 8" floppy (180k). DOS 1.1 had to be rewritten to take allow access to the extra 40k of the new drive. Anyway, point is that the disks were so small, each one would be a "directory". It's only with the IBM XT and the introduction of hard disks (a whole 10 Megs of!) that arranging storage became a problem (all those massive 64k text files we had to store .)

@pradeep: you answered your own question - DOS has a current directory for each partition. C:, D: and E: could all be on a single drive with a single app pointing to a currrent directory on each. On a multitasking system multiple apps have totally different current directory pointers for each and every partition. If this were not the case, each app would have to read and write to the same directories. Each application access would have to check that another application hadn't changed the current directory pointer and switch it back resulting in sloooow speed for all disk access.
An example (something Windowsey) your code 'current directory' could be in "C:\programfiles", your data 'current directory' could be in 'C:\mydocuments". You could have images stored on "D:\HaveALookAtThis" not to mention a network file on "Z:\somewhere\on\the\other\side\of\the\universe".
Without seperate "current directories" and appropriate network redirection most modern apps cannot work.

Xardfir wrote: ... resulting in sloooow speed for all disk access.
... not to mention a network file on "Z:\somewhere\on\the\other\side\of\the\universe".

If that's really on the other side of the universe, the latency will overrule any sort of overhead for current directory keeping.