home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / programm / 9278 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!gatech!psuvax1!uxa.ecn.bgu.edu!garrot.DMI.USherb.CA!famus2
  3. From: famus2@DMI.USherb.CA (Projet2 Famus)
  4. Subject: Re: Fast floppy writing techniques
  5. Message-ID: <BuFK8q.71s@DMI.USherb.CA>
  6. Sender: usenet@DMI.USherb.CA (Pour courrier Usenet)
  7. Nntp-Posting-Host: roselin
  8. Organization: Universite de Sherbrooke -- departement de Mathematiques et d'Informatique
  9. Date: Fri, 11 Sep 1992 20:14:50 GMT
  10. Lines: 38
  11.  
  12. >>Hi, I was wondering if anyone has C code for fast file writing to floppies.
  13. >>The application that I'm writing compresses the data before writing to disk,
  14. >>but the bottleneck is the floppy.  I'm currently trying to optimize disk
  15. >>writing by using a technique similar to XCOPY, but if I had code that
  16. >>resembled XCOPY already written that might help me meet my deadline.
  17.                                                   
  18. >>email: famus2@dmi.usherb.ca                      
  19.                                                     
  20. >Sorry, XCOPY gets its speed from cashing. The basic idea is that copy
  21. >will read a sector and then write a sector( or is that a few sectors).
  22. >Anyway it takes a lot of time to move from the read postion to the
  23. >write position, back to read the next sector and move to write it ....
  24.  
  25. >Xcopy will read in one or more files at once, the theror being that one  
  26. >sector in a file tends to follow the other, then write them all out at
  27. >once.        
  28.              
  29. >If you want to play at the BIOS level (don't do this at home kids) you 
  30. >can read/ write entire tracks at once. 
  31.  
  32. Yeah, I know about taking it a track at a time, it's a little too
  33. involved for my timeframe.
  34.  
  35. XCOPY gains speed (IMO) from batching together READS (until buffer is
  36. full) and writes (until buffer is empty).  Caching is not quite
  37. what XCOPY is doing.  I have not disassembled it (no good disasm).
  38.  
  39. An interesting idea I received from bobk@bridge2.NSD.3Com.COM
  40. (Bob Konigsberg) is to open, seek til end -1, then write last byte
  41. then seek to beginning, then to write whole file out.  I thought
  42. the idea was so interesting that I posted it for all to see.
  43.  
  44. Thanks Bob!
  45.  
  46. Steven Woolgar
  47. CHUS-FAMUS
  48. e-mail: famus2@dmi.usherb.ca
  49.  
  50.