home bbs files messages ]

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