Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,394 of 4,675    |
|    wolfgang kern to bilsch    |
|    Re: mechanics of file operations in 16 b    |
|    11 May 18 10:50:09    |
      From: nowhere@never.at              bilsch wrote:              > I'm writing 16 bit real mode programming using NASM. I will have a text       > editor and need to do file open, save, copy in FAT16 file system. The       > partition is 2GB and cluster size is 32k. I don't know exactly how much       > memory space will be available - hopefully much of       > 0x00600 to 0xA0000. It will not necessarily work on any PC - we'll see.              this range let me assume you want to write a bootable text editor,       EBDA (usually 1K) resides at 0x9FC00.              > My question. File operations need to access a 256 sector FAT (128k) and       > a 32 sector root directory (16K), and files could need 32k open at a       > time - ideally more. The I've never done anything like this. I assume       > the file operations are done accessing parts of FAT and root at a time       > and not the whole 144k. 144k is a lot of space. I need to have a       > smaller FAT and smaller cluster size. I also need to juggle between       > portion of file in memory and portion on disk at a given time. Any       > suggestions? TIA. Bill S.              my OS got its very own FileSystem but it still supports FAT-rd/wr too.              I'd use several 512 MB partitions (8K clusters) and reserve one 4K buffer       per partition (but only two at a time) to temporary hold 8 consecutive       FAT-sectors.       You can use smaller buffers but I wont recommend to use only one sector.              To hold a permanent copy of the root directory in memory is a good idea,       but if space is a major issue you can load just parts of it on demand or       skip the often unused tail-sectors.       I add one Volume Entry (RO to fool M$) to hold the actual used size       (in sectors) of the root (same for folders).              The disk manager should remember at least for two instances what it       loaded to where:       Drive:Path, start-cluster, fragments(if any), size and memory location.              My recommendations on creating your own disk manager:       "avoid fragmented write like hell!";saves a lot on speed for read       "have a free cluster info aside" ;a few bytes save you from FAT-scan.       __       wolfgang              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca