OSDev.org

Hi. I started to write my floppy driver. But i don't understand that when i wanted to read disk, the fdc how can understand where to read?

Hello..
First of all refer to this like http://www.isdaman.com/alsos/hardware/fdc/floppy.htm its a great document of fdc & you'll get all info about different commands of it.

But i don't understand that when i wanted to read disk, the fdc how can understand where to read?

Well for this you can use DMA. You have to tell DMA where you want it to write information from floppy, i.e. where the sector from floppy will be stored in memory. Thus when the sector is ready for read, fdc (using DMA) will write that sector into memory location specified by DMA. You can search for plenty of docs for DMA.. OSDEVER is the best place to start with..

Ok. I readed document. I started writing. But, i don't use paging. In document example, it is using "DMaPagePort". Can i use DMA without paging? [OsDever "DMAProgramming" Document]

Actually, that would make things easier.

DMA, like real mode and non-paging kernels, see the flat address space. If you dont use paging, you can tell the dma chip to write or read to a buffer without worrying about different addresses:

void * buffer = allocate(buffersize, FLAG_ALIGN64K) ;
SetupDMA(buffer);
Floppy_read();
Floppy_wait();
/* do with buffer whatcha want */

with paging, the real address would be different from the virtual address, needing you either to 1: keep two different pointers 2: specifically map those adresses to your address space. By looking at the name i suspect it uses the second method
nevertheless, sample of the first method:

void * buffer = ...
void * inrealmemory = translateaddress(buffer);
setupdma(inrealmemory);
floppy_read();
floppy_wait();
/* same code as previous example */

the only thing you'd need to take care of is that your buffer doesnt cross the 64K boundary, but any self-respecting doc would've told you that already

I think Tolga is referring to DmaPagePort, not the paging in the CPU. The port has really nothing to do with paging. The DMA needs a 24-bit physical address to know where to read/write data and its own address specifier is only 16 bits. You're missing the top 8 bits which is where the DmaPagePort comes in.

As the DMA reads/writes, it increments (or decrements if you tell it to) the lower 16-bit portion of the 24-bit address but the DMA page specifier doesn't increment or decrement when the 16-bit address specifier in the DMA rolls over. This is why DMA transfers can't cross 64KB boundaries, or else you might be writing to the top of the 64KB page and when it rolls over you'll be writing to the bottom, and not the bottom of the next page.

And, what is purpose of page port? It shows what?

Quickly read through the doc:

DMAPagePort is set to the io address where you are supposed to write the page (bits 16 thru 23) to:

address = ...
page = address >> 16;
offset = address & 0xffff;
outportb(DMAPagePort, page);
/* rest of DMA setup code */

Each dma channel has its own page register, each at its own io address.
The addresses themselves are listed in the doc. (page 6, the code block at the bottom)

Yes. I understand.

The last question, in document "if we are doing a 16 bit transfer, then we have to divide the physical address by 2 or just bitshift it once to the right."

Is this a rule?

Rule: no, since you can write anything to that register.
Most commonly it wouldn't work though:

There are 4 dma channels for 8-bit transfers, and 4 for 16 bit transfers.
If you use an 8-bit channel (DMA0..3) the address loaded points directly to the memory you want
If you use an 16-bit channel (DMA4..7), it will copy two bytes at a time. Since memory usually doesn't work when you ask for a word over a 2-byte boundary, the DMA controller must have the lowest bit set to zero to avoid trouble.
(Same goes for the processor: if you'd ask a processor a word at e.g. 0x1007, it would read two bytes from 0x1007 and 0x1008 instead of a single word due to the alignment, which costs you a cycle. Not sure wether the processor's built-in cache suffers from this though)

Apparently the dma controller wants to be nice to us and prevent the lowest bit to be set at any cost - in this case by removing it altogether. Result is that the dma register's bits 0..14 correspond to your offset bits 1..15, causing you to do extra work and shift the desired offset into place.

8-bit DMA luckily doesn't have this 'feature'

The other problem.

How can i detect floppy type, and it's features?

Example: 3? Floppy. 18 Sector, 2 Head, 80 Track. Data Rate = 500 Kbps.

I didn't found this in documents.

The other problem.

How can i detect floppy type, and it's features?

Example: 3? Floppy. 18 Sector, 2 Head, 80 Track. Data Rate = 500 Kbps.

I didn't found this in documents.

Here's a tutorial that'll tell you the capacity of the two floppy drives.

-Stephen

hm. maybe that answer the question, but i have the feeling that Tolga was more looking for the type of the media rather than the drive capabilities...

Afaik, the BPB of the floppy might tell you that ... if it's present and correct. So it's up to the software that formatted the floppy to know what format it defines, setup the hardware properly and write back the values in the BPB.

I have to admit i have no idea of whether the BPB of a 720KB floppy can be read when you've configured the drive for 1.44MB floppy...