Page 1 of 1
disks... hard. soft. otherwise..
Posted: Sat Jan 04, 2003 6:05 pm
by 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.
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 4:13 am
by 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
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 5:25 am
by chrisa128
Can I have look at code for ramdisk driver as this is what I am currently working on?
Chris
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 5:33 am
by Matze2002
Hi,
i am very interested, too ;D
bye,
Matze
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 7:01 am
by 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;
}
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 9:29 am
by 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 ?
Re:disks... hard. soft. otherwise..
Posted: Sun Jan 05, 2003 10:09 am
by 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