Dex wrote:Good points Ready4Dis, but i would just add that it is possible to read/write usb, by going to and from realmode, i have a pmode floppy and a bios driver in my OS.
Because if you go back to realmode from pmode emulation works again, this lets you read/write to a USB fob, also it lets you use a USB floppy drives etc or read the boot image of a CD uder emulation.
Now when you go to and from pmode to realmode for floppy driver, it is not any slower than using it in realmode.
But when you load from USB under emulation, even in realmode, it is much slower than floppy loading, i would say as much as 4 times slower than a floppy.
I have started coding a USB stack, so far it was not that hard, its just very hard to get any info.
As for CD, you can code a driver, but they are read only, my problem in my OS is write, as i have a fasm port, i can assemble the code, but it is so slow if you use floppy, you can not use CD, so that leaves hdd which is fine, but my OS only read/writes to fat16/32, which most are NTFS
.
I am thinking about using a floppy image to get around this, as i can much easier code a driver to load and write back a image file eg: vfat.ima to a NTFS partion than read/write files in the normal way to NTFS, as the image will stay the same size.
Well, that's why I have a Fat32 partition, I have a bootsector for fat12/fat16/fat32, and utilities I wrote to format, and write files out to each type (yes, I write a LOT of utilities myself, but then, I can have them do anything I want also, like writing contiguous files rather than scattered for things like my kernel image). Anyways, yes CD's are read only, which is a problem when you are trying to self host and would like to be able to compile, etc. To get around the slow floppy, most people store an image of the floppy in memory, and read/write to it, then once all the updates are done, they commit the 'dirty' pages back to disk (and if done in a background thread, the main application can exit before the data is actually done writing, but you know when it's done writing because the light on the disk will go out). It's similar in concept to a ram-disk or memory mapped file (except you are mapping the disk, not just a file). Your driver for the floppy would be coded in such a way that when reading/writing it does so from memory (which is ALWAYS current, so you know it's good), where the driver stores a list of pages that have been modified. It would then have a thread that would write the data to disk in the background, so it can return to the user application as soon as the memory is updated (a few MS), which can significantly increase your application performance, even if you must wait for the light to extinguish to turn off your PC or reboot, at least you can do other things (compile more files?) while waiting for the disk to be updated. It wastes a mb of ram, but I think it's a fair tradeoff, especially if you use the floppy a bunch, if not, and you have a good memory manager with virtual memory (swap disk/file), read/writing to the floppy will read/write from memory, which would be stored on your HD in most cased (paged out), then it would write to floppy when updated, and be paged back out not to much later (depending on your manager). Now, me personally, I like having a spare partition setup for booting, it just makes things 'simple'
. Yes, I am aware of going back to real-mode and reading/writing, you can do that for FDC, HDC, CD, VESA, etc.. but chances are, you will miss a LOT of interrupts if you're not in v86, multitasking will 'pause', anything relying on timers goes to crap, etc. And reading large files is a big no-no, unless you are using voodoo mode/flat real mode/unreal mode, but then you still don't have paging in real-mode, so you would need to pass it a list of physical pages, which gets very combersom... of course you could limit transfers to a smaller size, and copy them from the pmode driver, minimizing the time spent in real-mode for each read (so you won't miss quite as many interrupts, just 99% of them), and multi-tasking will only appear very sluggish instead of paused completely, and your I/O rates (which are already dismal at best) will be completely shot, so it's far from a solution, although it would be a workaround while you are working on your USB drivers. I have not tried writing USB drivers yet, but that is a goal so I can boot from my thumb-drive, until then I will stick with my HDD (which was the original question, and I still recommend if you have a spare one, or spare partition). A few things to always do when working on a hard drive.
1.) Read before writing -> always get your file reading code working before attempting to write anything to disk, if you read from another partition by accident, no big deal, if you write to it, plan on re-installing an OS.
2.) Use a function specifically designed for writing to partitions -> Especially while still developing have a function that uses the partition start LBA as a variable of some sort (whether it's passed in or global), and always check to make sure it's not 0 before issuing the write command. If it's zero, throw an error, and crap out so you know something tried to f*ck up your HD
3.) Always make sure you back-up anything important before playing with a HD that has data you want to keep, accidents happen.
4.) Test in an emulator -> Download free-dos or another small OS to play with, make an image file with multiple partitions, and test your code, make sure it doesn't hose the alternate OS, never try your code on a real pc unless your a.) never make mistakes, b.) have spare hardware and it doesn't matter if you mess up, or c.) like running scandisk and trying to recover lost file segments
.
Anyways, I write most of my own utilities, and I know my HD pretty well now for doing so, but I had to do a lot of testing and trial and error before everything worked (know how many times I booted to bochs, and ran chkdisk before I got my fat code to not throw any errors, stupid things too, like the fact that windows doesn't recognize a fat partition if anything but MSWIN4.1 is in the FAT table (OEM Field)). I tried writing another string in there, and it just wouldn't recognize my drive, changed it to MSWIN4.1 like MS uses, and bam it worked.
. I multi-boot windows xp, dos and my OS on 3 seperate partitions. My partition and Dos are both Fat, which my OS can read easily. I can copy files to my partition straight from windows, boot my OS, update my kernel/bootsector by booting to my dos partition and running my utilities. I am also writing some windows utilities to be able to write directly to partitions (as long as you have admin rights). Another idea is to write an installer, basically a bootsector that loads a copy program. You don't even have to leave real-mode, and can use bios int's very easily to copy your OS to a partition from a floppy disk. If you are not comfortable writing tools, or understand how reading/writing to a partition or MBR will affect your computer, I suggest sticking with the floppy until you are a bit more seasoned, because playing with those things can hose a system pretty quickly. I tested my MBR a bit before writing it to my working hard drive, since I actually USE the computer I was messing with