home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / cbm / 4399 < prev    next >
Encoding:
Text File  |  1992-11-05  |  3.3 KB  |  70 lines
  1. Newsgroups: comp.sys.cbm
  2. Path: sparky!uunet!news.univie.ac.at!chx400!ira.uka.de!ira.uka.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!zx1!uet019
  3. From: uet019@zx1.Darkcrystal.Cyberspace (Oliver B. Warzecha)
  4. Subject: Re: Decreased seek times.
  5. Message-ID: <1992Nov5.131146.22893@rhrk.uni-kl.de>
  6. Sender: news@rhrk.uni-kl.de
  7. Reply-To: uet019@zx1.hrz.uni-dortmund.de
  8. Organization: University of Dortmund, Germany
  9. X-Newsreader: TIN [version 1.1 PL6]
  10. References: <sheun.720890127@barney>
  11. Date: Thu, 5 Nov 1992 13:11:46 GMT
  12. Lines: 56
  13.  
  14. Sheun Olatunbosun (sheun@cs.city.ac.uk) wrote:
  15. : In <1992Nov4.015117.7144@pimacc.pima.edu> ppugliese@pimacc.pima.edu writes:
  16. : 
  17. : >In article <92308.181655K3027E7@ALIJKU11.BITNET>, K3027E7@ALIJKU11.BITNET writes:
  18. : >> fuzzy@netcom.com (Fuzzy Fox) writes:
  19. : >> 
  20. : >>>interleave.  The basic problem is GCR decoding.  I would venture to say
  21. : >>>that it is impossible for a 1541 with standard 1 MHz processor to decode
  22. : >>>a sector in less than the time it takes for FOUR sectors to rotate under
  23. : >>>the head.  In fact, GCR decoding is one of the slowest parts of any
  24. : >> Fast decoding in the 1541 is not possible due to lack of memory.
  25. : >> If you transfer the sector undecoded to the C64 you can decode it
  26. : >> there using tables for fast bit manipulation. During that the 1541 can
  27. : >> already read the next sector.
  28. : >> Thus it is possible to read and decode an entire track within 3 rotations.
  29.  
  30. (Stuff about "intelligent" drive deleted)
  31.  
  32. : In either case, I think the problem seems to be that the GCR
  33. : encoding/decoding is done in the disk drive software and that the drive
  34. : has limited RAM. If A LOT more RAM was available, I'm sure that more
  35. : bulk data could be transferred to and from the computer before the need to
  36. : read/write more sectors to disk. In addition, it could de possible to write
  37. : lengthy routines in disk RAM to control the drive directly (and probably
  38. : do MS-Dos formatting... he guesses). I'm assuming that any hardware vectors 
  39. : can de modified such as in the C64 with its RAM banks and NMI/IRQ interrupts,
  40. : etc
  41. Here in Germany, some time ago, two people recognised just these problems
  42. of the 1541 and wrote the speeder "prologic dos", which has exactly
  43. these features:
  44. - 2 MHz Operation of the 1541
  45. - 8 K additional RAM in the drive
  46. - Hardware-based GCR decoding
  47. - Parallel data-transfer via 2 additional 6821 chips
  48. Well what can I say - I work with it and the result is just fine:
  49. 202 Blocks loaded in ~4.4 seconds is the fastest you can achieve.
  50. All other Operations are just as fast (Validating full disk in  ~15 s)
  51. Oh - this is NO commercial advert, but while I've been reading the articles
  52. in this thread I just recognised many of the things people were talking
  53. about, and so I decided to come up with this, it might be interesting.
  54. : 
  55. : But finally, could someone throw some light on these questions.
  56. : 
  57. : At what serial rate is the data being transferred between the computer
  58. : and the disk drive? 
  59. I think it was ca. 300 cps with a standard 1541(old). I have heard the
  60. 1541-II is 10% faster or so.
  61. : Also, is the C64's VIA 6522 chip communicating with a similar chip inside
  62. : the disk drive?
  63. Obviously you talk about the C64's CIA 6526, which is indeed communicating 
  64. with a VIA 6522 in the 1541. 
  65.  
  66. OBW
  67. uet019@zx1.hrz.uni-dortmund.de
  68.  
  69. "no flag or uniform ever stopped the bullet of a gun" - Moore/Lynott
  70.