FDD/HDD drivers

[0xBADC0DE]

I've got a question - should I implement the FDD/HDD drivers as a V86 task [BIOS Services in V86 Mode], or as a fully 32-bit protected mode driver.

[Warrior]

32Bit protected mode driver.

From the OSFaq:

Can i use VM86 for disk access ?

Theorically yes, though it is probably not a GoodIdea(tm), as most BIOS disk access will include IRQ handlers, DMA transfers which you can hardly control from your VM monitor, and may stick in VM86 task while the BIOS waits for an interrupt response while a 'good' driver would have let the CPU free for other processes.

Remember of your old MS9x system freezing when doing a disk access ? that was most of the time due to an INT13-through-VM86 problem.

[0xBADC0DE]

I should clarify - if I am going to do it the V86 way, I would first create a V86 thread in the kernel. I would then have the kernel pass requests to a queue that the V86 driver reads. The V86 thread would read the queue, processing requests. The kernel will preempt that thread, so the CPU is not left idle.

[Phugoid]

Sure, the kernel will preempt the thread, but the thread will not notify the kernel when it is idle (blocking on an I/O operation). You will have no way of knowing that the thread is blocked, so your kernel will repeatedly schedule the thread even though it is doing nothing. So you will still waste CPU time until the next forced scheduling event, until the I/O operation is complete.

[Dex4u]

I've got a question - should I implement the FDD/HDD drivers as a V86 task [BIOS Services in V86 Mode], or as a fully 32-bit protected mode driver.

If your talking from a BIOS V Your own Pmode driver, then i would say Use BIOS, do not make a pmode floppy driver until very late in the Dev time table. I came to this conclusion, by first making a pmode floppy driver, which worked great, also at the same time, i added a go back to realmode function for calling BIOS int's.

When i found that my pmode fdd driver did not work in DosBox (the dos emulator) because of it expecting int 13h , i make a function that went back to realmode read 512b (using BIOS int 13h) came back to pmode moved it to a buffer and so on until it had read as much as it needed, i thought it would be very slow, but not a bit of it, it is if any thing faster than my pmode fdd driver, faster than a window, linux fdd driver etc.
Not only that, it will read from usb key-fob as well, which a pmode drivers would need a usb driver, to do this. You could just as easy use it for hdd. But this does not get away from the fact the the read/write functionsare just a small part of read from floppy, the fat12 etc is the biggist part, but if i was to start again, i would not make a pmode floppy driver.

[kataklinger]

I hate doing things twice, so if I was you I would do driver in protected mode.

[Pype.Clicker]

pmode driver for me. There are good public-domain references (see ata-atapi.com) that can be used. Trying to use v86 mode for a block device is auwfully slow (see win'95 "INT13 driver" if you don't trust me) and it is a design nightmare ...

[DIGIT4L_PUNK]

pmode driver for me. There are good public-domain references (see ata-atapi.com) that can be used. Trying to use v86 mode for a block device is auwfully slow (see win'95 "INT13 driver" if you don't trust me) and it is a design nightmare ...

I hate doing things twice, so if I was you I would do driver in protected mode.

I agree with you