The making of my 32bit Floppy Driver..

[Neo]

Another really important question: for ISRs, i save and restore all registers, does this even matter? I noticed neo's code just calls the C handler and iret's.

I do save and restore all the registers using the 2 macros shown in my code ISR_HEAD & ISR_TAIL. ISR_HEAD is

Code: Select all

%macro ISR_HEAD 0
 cli
 pusha
 push   fs
 push   gs
 push   es
 push   ds
%endmacro

and ISR_TAIL is pretty much its opposite.
It is always better to save the registers and restore them even though the thing works without it sometimes (when the regs are not modified). Right now i have no multitasking etc.. but i guess that when that's implemented it would be necessary to PUSH and POP all.

btw i think i've understood the fix-drive-data command. Each columns seems to be the be the delays for differnt data-transfer speeds.
Still if anyone has some better links to this kinda stuff it would be great.

[distantvoices]

@solar:

*indeed* there is a good reason to do fdc driver development, tough it is ugly and kinda weird: first, you don't want testers to experience havoc with your neat well designed harddrive drivers (yumyum all the data on the hd is gone and the head is parked amidst the disk *lol*), and second, you learn how to code a driver with multitasking in mind: designed correctly (without busy waiting), a floppy driver is as smooth as a soft cloth in a micro kernel environment. It just fits in. Sure you have someone waiting for the blocks from the floppy, but you can set off doing something else.

Since I gonna design File system service in multi threaded manner, I think, there won't be many bottle necks. The floppy driver will get something like a schedule - the interface where orders are placed, and which tells the driver what to do next. It is then: place a bunch of orders and have the driver set off doing the work. I could imagine following scenario: you have a two-threaded driver: one thread fetches orders, processes them and puts them into a queue (and wakes up the work horse thread), and the work horse thread comes along and fullfills the requests as they are queued up. This way you can have as many fs service threads send messages to the disk driver as you want. One request after each other is fetched and queued up for further processing.

HOpe I've expressed myself clear enough. Sometimes I really screw up sentences.

[mr. xsism]

true but it helps ease into other stuff like ATA IDE and ATAPI. Look i fixed my problem. I forgot i had to send Head once as 3rd bit in read command byte and then by itself. I put all this together in just 2 nights including FAT12 code. Check it out!

[attachment deleted by admin]

[Solar]

first, you don't want testers to experience havoc with your neat well designed harddrive drivers (yumyum all the data on the hd is gone and the head is parked amidst the disk *lol*)...

Rather sooner than later, I'll have to add hard drive support to my OS anyhow (since that's a requirement set in stone for a couple of years to come). That has to be tested anyway. What does having floppy support earn me there?

(Of course I won't release hard drive code before casually alpha-testing it myself so the HD-destroying bugs are taken out.)

...and second, you learn how to code a driver with multitasking in mind...

Do you really learn that by writing FDC code? Or rather, if you have to learn that yet, aren't you a bit misplaced to lead-manage your own OS project?

I don't want to sound arrogant here, but just as I think writing your own boot loader is a poor way to learn about OS coding, or as writing an OS is a poor way to learn about C programming, I think that writing a floppy driver does little except teaching you how to write floppy drivers...

...designed correctly (without busy waiting), a floppy driver is as smooth as a soft cloth in a micro kernel environment.

You mean the fact that every OS I have tried so far on the IA32 platform - including Linux, FreeBSD, and various flavors Windows - all but freeze up when the floppy is accessed is because of poor drivers? Hard to believe...

I know the Amiga had smooth floppy access, but that was due to the dedicated custom chips...

[BI lazy]

Whadda hell d'ya think I've done in the last 3 1/2 years on the field of OS research, OS project leading, designing and coding? Rubbing my nose? Talk the Talk?

If you say "do you really learn that by writing fdc code?", you don't seem to have grasped the *real* thing about it: designing a driver in a way that it doesn't hinder the overall performance of the system. *slow* floppy is a really good exercise for that. And don't come with arguments like *what do I need that for?*. Imagine your system s crapped out and the sole key to it is a small floppy? what'cha gonna do now, gosh, without floppy access? *damnit*

I don't preach the holy floppy pragma, but I don't like stubborness and arguments like "Who needs that ...".

your saying about: writing floppy driver does little except teaching how to write floppy drivers - I consider this one narrow sighted and polemic. It is a matter of fact, that you have to write drivers for *your* Operating system, care crap 'bout windows, linux and sorts: they have their own. You need a video (console) driver, you need a keyboard driver, you need ... well, you see what I wanna say? Does writing keyboard drivers teach nothing else but writing keyboard drivers?

Tack sa mycket

[Solar]

Whadda hell d'ya think I've done in the last 3 1/2 years on the field of OS research...

Hey, HEY! No need to go ballistic! ::)

If you say "do you really learn that by writing fdc code?", you don't seem to have grasped the *real* thing about it: designing a driver in a way that it doesn't hinder the overall performance of the system.

I admit that I haven't written a floppy driver myself yet. But from what I see so far, it is significantly different from a state-of-the-art DMA hard disk driver, in its tight coupling with BIOS interrupts etc.

Imagine your system s crapped out and the sole key to it is a small floppy? what'cha gonna do now, gosh, without floppy access? *damnit*

I really mean no offense when I say, "rescue disk" today usually means a CD-R. I've seen quite a couple of laptops that come with DVD-R drives but without floppy bay.

I don't mean to belittle those who write a FD driver these days. I just question whether it's worth the hassle.

I don't preach the holy floppy pragma, but I don't like stubborness and arguments like "Who needs that ...".

I think that "who needs floppies these days" is a valid design question. You don't write drivers for 300 baud acoustic couplers anymore, either.

your saying about: writing floppy driver does little except teaching how to write floppy drivers - I consider this one narrow sighted and polemic.

Sorry to hear that.

It is a matter of fact, that you have to write drivers for *your* Operating system, care crap 'bout windows, linux and sorts: they have their own. You need a video (console) driver, you need a keyboard driver, you need ... well, you see what I wanna say?

Don't you see what I want to say? You need screen output. You need a keyboard, and if you want to go anywhere you need a mouse. You need ethernet, hard drive and CD-ROM support.

But do you need a floppy? Apple answered that question for the iMac. Intel labeled floppies as "legacy" (same for PS/2 mice and keyboards, which however have more widespread use yet).

Would it really be so crippling if your OS would not support floppy drives?

Tack sa mycket

Again, no offense intended, sorry.

[BI lazy]

I'm not going ballistic. I speak directly.

Do you really think you do floppy programming without DMA and with BIOS? (in protected mode os by the help of a beloved VM86 Mode?) As a matter of fact, programming the FDC involves some DMA stuff too. The Bios just hides this from Sarah programatzki.

You usually code a floppy driver by accessing *Hardware* ports. Bios calls you issue in Bootloader stage or via vm86 (oh costly this is).

But what you may learn from the floppy thing, you can use for the hd-thing: the fetching and dispatching of orders for blocks, the delivering of stuff via DMA and so forth. Techniques, you need every where else in the os. (linked list management, message passing stuff, usage of timers and so forth)

It is and it will be short sighted to deny the OS - and the user - a decent floppy driver as well as it would be to deny it a decent ATA driver.

If you design the OS modular (and I do so) just leave out the fdc driver in the configuration or unload it and begone it is. So simple this question can be answered. But I as Developer consider it a challenge to code a driver for such a raw and delicate Device - and it works out well.

In short words: I consider it worth to take the challenge and design/code a decent floppy driver. It is for one a preparation for writing a HD driver - with much less risk.

tack sa mycket = thanks very much. Or do you think I am calling you names? *big grin*

[Solar]

tack sa mycket = thanks very much. Or do you think I am calling you names? *big grin*

Nope... while I don't speak much Swedish myself, having two Swedes on the project taught me enough Swedish to know your meaning.

(What's this with Scandinavians and OS development? )

[BI lazy]

*hehe*

I'm austrian, but 've been in sweden for holidays and this has left quite some impressions. d'ya know Smaland?

[bubach]

I am missing some dots, but except for that it seems nice..
it?s called sm?land..
I guess it?s just that programmers around here rock so hard!

h?lsningar Christoffer

[Solar]

d'ya know Smaland?

Nope, only Valentuna, Liding? and Stockholm, from spending a week with my "Number One" (project co-lead) last summer...

I guess it?s just that programmers around here rock so hard!

Oh how I would rejoyce if Lennart would finish his studies, find a well-payed job, and spend his spare time chained to the keyboard working on our OS!

[Pype.Clicker]

we all have priorities ... for some it's the floppy, for others the HDD, for others it's the network card. I'm personnally glad of it as it means when i'll *need* a floppy driver, people will have some to trade against SomeOtherThingOfMine ...

personnally, the first removable media i'll target is USB storage ... But that's unlikely to be simple ...

[Neo]

ok guys can we get back on topic?
i really need to know of the sequence of steps i've given from "Code slashers" tutorial is the correct way to init a FDC or can i just send 0x0C or 0x1c to the FDC_DOR??

[Neo]

ok i guess i will follow the method listed above instead of just sending 0x0c. b'coz it seems more correct and also allows the FDC to be setup with the necessary parmaeters etc.
Anyway it would be nice if someone could confirm this.

[mr. xsism]

Code: Select all

void initialize_floppy(void)
{
   EditIDTDesc(0x26, floppyISR, G_TRAP|G_DPL0|G_32BIT|G_PRESENT, 0x8);
   unmaskIRQ(FLOPPY);
}

Code: Select all

unsigned long fdc_read(unsigned char drive, unsigned char cylinder, unsigned char head, unsigned char sector, unsigned long buffer, unsigned long length)
{
   /* start motor */
   fdc_motor(drive, 1);
   delay(100);
   outportb(0x3F7,0);//CCR data speed
   fdc_seek(drive,cylinder);   
   /* DMA setting */
   initialize_DMA(buffer,length,2,DMA_WRITE|DMA_AUTO|DMA_SINGLE);   
   /* send commands */
   fdc_command(0x66);//READ CMD - make dynamic later
   fdc_command((head<<2) | drive);//DRIVE
   fdc_command(cylinder);//TRACK
   fdc_command(head);//HEAD
   fdc_command(sector);//SECTOR   
   fdc_command(2);//bytes per sector size - make dynamic later
   fdc_command(18);//end of track - make dynamic later
   fdc_command(0x1B);//rw gap - make dynamic later
   fdc_command(0xff);//bytes to r/w - make dynamic later
   /* Wait for op complete interrupt */
   interrupt_occurred=0;
   while(interrupt_occurred!=1);
   /* get results */
   fdc_result();
   /* turn motor off */
   fdc_motor(drive,0);
}

i don't init it really. It works fine. I am assuming though which could prove buggy on some PCs. I'll fix it later.