home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / apple2 / 19583 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.6 KB  |  53 lines
  1. Newsgroups: comp.sys.apple2
  2. Path: sparky!uunet!usc!rpi!usenet.coe.montana.edu!nntp.uoregon.edu!cie.uoregon.edu!nparker
  3. From: nparker@cie.uoregon.edu (Neil Parker)
  4. Subject: Re: Apple II RWTS codes.
  5. Message-ID: <1992Aug28.091925.1873@nntp.uoregon.edu>
  6. Sender: news@nntp.uoregon.edu
  7. Organization: The Universal Society for the Prevention of Reality
  8. References: <m0mNh96-000130C@crash.cts.com> <philip.714956593@labtam>
  9. Date: Fri, 28 Aug 92 09:19:25 GMT
  10. Lines: 41
  11.  
  12. In article <philip.714956593@labtam> philip@labtam.labtam.oz.au (Philip
  13. Stephens) writes:
  14. >ncp@gnh-cathouse.cts.com (Neal Pitts) writes:
  15. >
  16. >>>> The stuff in DOS 3.3 reads the raw data and then analyzes it,
  17. >>while the ProDOS routine analyzes it while it's reading (where analyze ==
  18. >>convert from 6+2 encoding to plain data). <<
  19. >
  20. >>Is there any good reason for ProDOS to do this?  I would think that it would
  21. >>have taken the speed penalty for a good reason...
  22. >
  23. >  ProDOS's way is faster.  Since ProDOS reads and writes data in blocks (two
  24. >sectors at a time), having the two sectors of a block physically adjacent means
  25. >they can be read and written quicker.  And to top it off, this arrangement
  26. >allows the interleave to be 2:1, compared to DOS 3.3's interleave of 3:1.
  27.  
  28. Actually, DOS 3.3 uses a 2:1 interleave.  The difference is it's
  29. backwards--going in order around the disk you encounter (logical) sectors
  30. 0, 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, 9, 1, 8, and 15.  DOS 3.3 allocates
  31. sectors in descending order, so in effect it's getting an interleave
  32. pretty much equivalent to ProDOS's.
  33.  
  34. Interestingly enough, the bottleneck in DOS 3.3 isn't coming from RWTS's
  35. habit of decoding after the sector is read--it's coming from the fact that
  36. the DOS 3.3 file manager tells RWTS to read the sector into its own
  37. internal buffer, and then it doles out that buffer one byte at a time to
  38. the user's code.  By the time it's copied out the whole buffer, the next
  39. sector has already spun by, so you have to wait for another disk
  40. revolution.  If the file manager's "middleman" buffer can be eliminated
  41. from the picture, the remaining code is fast enough to catch the next
  42. sector BEFORE it spins by, and a dramatic improvement in speed occurs--an
  43. entire track can be read in 2 revolutions instead of 16, and hi-res
  44. pictures load in roughly 5 seconds.  I know of more than one "fast DOS"
  45. patch that worked by eliminating the "middleman" buffer (I even wrote one
  46. myself once).
  47.  
  48.               - Neil Parker
  49. --
  50. Neil Parker                 No cute ASCII art...no cute quote...no cute
  51. nparker@cie.uoregon.edu     disclaimer...no deposit, no return...
  52. parker@corona.uoregon.edu   (This space intentionally left blank:           )
  53.