disks... hard. soft. otherwise..

[df]

well tonight i finished off my keyboard driver, with uk + usa keymaps as external binary files...

next stage is a floppy driver + hard disk driver...

thats a big step...

needs a VFS interface, filesystem driver, dma driver, floppy driver and hard disc ATA/IDE driver....

thats a lot in one breath...

i think (being the disorganised person that I am), the vfs + filesystem will come later, with first the floppy drive+dma ...

once i can read sectors off the floppy via dma, then I'll worry about filesystems + vfs interfaces...

joy...

design by chaos + laziness. ohyeah.

[df]

i've about-faced on that since last night...

i have some code I've half done ages ago as a ramdisk driver... I think I'll polish the ramdisk code, and do some fs code and vfs layer... and worry about teh hardware stuff later on hahah aaaah

[chrisa128]

Can I have look at code for ramdisk driver as this is what I am currently working on?

Chris

[Matze2002]

Hi,
i am very interested, too ;D

bye,
Matze

[df]

this is as basic as it gets, its minimal, and probably wont even compile

I just knocked this up in 5 minutes. calculations are probably wrong.

there is so much wrong in the below I dont know where to start.
- there is no separation from disk + code.
- doesnt take more than 1 ramdisk (easily fixed)
- does not interface into higherup (ie: vfs, or whatnot)
- ++ many many more....

all it really does is pretend to read/write a sector sized chunk into/from memory...

Code: Select all

typedef struct RAMDISKINFO
{
   UINT32   lngSectors;   
   UINT32   lngTracks;
   UINT32   lngHeads;   
   void*   ptrImage;
} RAMDISKINFO;

RAMDISKINFO   *rdi;

void InitRamDisk(UINT32 lngSize)
{
   rdi=(RAMDISKINFO*)malloc(sizeof(RAMDISKINFO));
      
   rdi->lngSectors=lngSize/512;   
   rdi->lngTracks=rdi->lngSectors/64;   
   rdi->lngHeads=rdi->lngTracks/1024;
   
   rdi->ptrImage=(void*)malloc(lngSize);   
}

UINT32 rd_ReadSector(UINT32 lngSectorCount, UINT32 lngTrack, UINT32 lngHead, UINT32 lngStartSector, void* ptrBuffer)
{
   UINT8   *p;
   
   p=rdi->ptrImage;   
   p+=((lngHead*1024) + (lngTrack*64) + (lngStartSector)) * 512;
   memmove(ptrBuffer, p, lngSectorCount*512);
   
   return lngSectorCount;
}

UINT32 rd_WriteSector(UINT32 lngSectorCount, UINT32 lngTrack, UINT32 lngHead, UINT32 lngStartSector, void* ptrBuffer)
{
   UINT8   *p;
   
   p=rdi->ptrImage;   
   p+=((lngHead*1024) + (lngTrack*64) + (lngStartSector)) * 512;
   memmove(p, ptrBuffer, lngSectorCount*512);
   
   return lngSectorCount;
}

[Pype.Clicker]

Should a disk advertise its geometry ? I mean, it's well-known that sectors on a track can be used faster than sectors on distinct tracks ... How can you handle this ? How can the upper-layer (say the sectors allocation policy) know which sector it should select among the available free sectors ?

[df]

it does not have a concept of free/used sectors. there is FS. thats for a higher up layer. my other code treats it like a disk. read/write sectors, but its up to the FS code + VFS to determine free/used etc, placement.

all the posted code does is read 512byte chunks. it just pretends to be a raw disk device. a floppy disk does not have a concept of whats on it, it just shuttles data on and off.

I'm looking into the minix FS for a floppy FS. I want something a bit more sturdy than FATs single direction link list concept, and one designed to do long filenames, without wasting 10 entries in the FAT table