OSDev.org

@rootel77

and how can I do that ??

There was this point on "d*mn slow" that was intended to show that you'd need a 386 or so to show a noticeable effect. Do the maths (as I've tried to get you to do a few times before, on other occasions):

Floppy track rotation speed is around 3rps, 180rpm. That means that 3 tracks come around under the read head each second, for a total of 3 * 18 = 54 sectors. 54 sectors amount to (54 * 512 = ) 27648 bytes per second. In effect, without caching on behalf of the floppy drive, that means that on the slowest XT that's available, counting for 10 cycles per IN, you have a processor load of 5.8%. That means that you have to have a really really big overhead to notice the difference.

The trick in floppy performance is not in reading more or faster, but reading smarter.

As people have suggested before, read a full track and cache it. The disk isn't going to change until it's pulled out of the drive. Especially cache the FAT and directory entries, you need them a lot.

The next is going to require a bit of thought. If you read a track from sector 0 to 17 sequentially, then skip to the next track and again read from 0 to 17, you'll experience a delay between the first and second track read. This is because the floppy motor causes the disk to spin (causing magnetic fields to change and you to be able to read it in the first place), which also causes it to spin to sector 3 or so in the track you want to read. Now, if your floppy drive doesn't have a track buffer (don't bet on it), it's going to skip them (and ignore them, and waste time!) until it finds no. 0. When it does, it'll read it and read the full track. But, thinking about it, if you just read 3-17 and then 0-2, you'd also have the full track, but sooner. Some types of disks are formatted to take this effect into account and to stagger the actual sector division on the disk so that the head delay is fixed into the disk. You therefore might not be succesful with this idea.

As with all things, think. If you need tracks 0, 5 and 79, you don't read 5, then 79, then 0. You use some algorithm for deciding which to read next. Think up some ideas, decide what's fastest.



Most of all, for a floppy these effects are easily measured. They also work on a harddisk or on a cdrom (dvdrom / hd-dvd / bluray / whatever) but with harder to measure effects (since your processor then can become a limiting factor). If you practice this type of thinking on a floppy, you'll write better harddisk code.

For example, you can have a linked list for cached tracks. initiallay this list will be empty. at each read sector command, you search first in the list if the track containing the sector exists on the cache, if not you read the complete track (using read track command) into the cache.

you'll need to check if the user has changed the disk at each read command (the bit 7 in th digital input register indicates if set that disk has changed since the last command). if disk has chabged you clear the cache.

if you need an implementation example you can look at the http://minirighi.sourceforge.net/

Has anybody considered the fact that floppies are so slow and unreliable, that a driver that works (and preferably is tolerant of errors) is going to be enough, because normal people use floppies only as either the last resort, or because nobody told them USB sticks exist and they don't know how to move files over the internet.

So basicly, at the very moment of time somebody is actually going to start caring about performance, you've hopefully eliminated all good reasons to use floppies in the first place, so you might just as well write a floppy disk driver that uses busy-loop polling with interrupts totally disabled, displays "Accessing legacy storage device..." in text mode (doing the necessary video mode switch) while reading/writing, and calculates 8192 decimals of pi after each sector.

Once the system is usable for real use, about ten people would care, and by then you could get somebody else to write a better driver.

But ofcourse I can't code, so my opinion is totally irrelevant; after all I can only design and analyze algorithms, and write strange heaps of parenthesis that supposedly transform other heaps of parenthesis into another type of heap of parenthesis, and possibly sometimes even into executable code.

PS: Am I allowed to claim 100% assembler, if I write myself (in asm ofcourse) a macro-assembler with an input language that looks and feels like Lisp, runs interactively with the program if desired, and does JIT assembly?

'Cos if I'm allowed to claim 100% pure asm then, I might even bother, just for the fun of it.