home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / cbm / 5646 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.3 KB  |  73 lines
  1. Newsgroups: comp.sys.cbm
  2. Path: sparky!uunet!UB.com!pacbell.com!decwrl!csus.edu!netcom.com!fuzzy
  3. From: fuzzy@netcom.com (Fuzzy Fox)
  4. Subject: Re: 2 Q's: BMI & SAVE@
  5. Message-ID: <1993Jan27.060700.191@netcom.com>
  6. Organization: Foxes 'R' Us - Seven locations to serve you
  7. References: <1993Jan22.062624.23025@netcom.com> <30370@optima.cs.arizona.edu> <1993Jan24.043922.20002@netcom.com> <C1Ds7u.M53@ddsw1.mcs.com>
  8. Date: Wed, 27 Jan 1993 06:07:00 GMT
  9. Lines: 62
  10.  
  11. dattier@ddsw1.mcs.com (DWT) writes:
  12.  
  13. >| Huh??  If you always SCRATCH the file then SAVE, you will not run into
  14. >| the @-save bug, because you're NOT USING @-save!!  :)
  15.  
  16. >And now, yours truly:
  17.  
  18. >David, so if you never leave North America you can't catch the Hong Kong
  19. >flu?  If the same bug is triggered by scratch+save, then you haven't fallen
  20. >afoul of the save+replace bug, you've fallen afoul of the scratch+save bug.
  21. >It's no help to change the problem's name: you still have a confused disk.
  22.  
  23. The scratch command scratches the file before writing a new copy.  The
  24. @save command scratches the file after writing the new copy.  They do
  25. not do the same thing, and to not run the same code in the drive ROM.
  26. One of the routines has a bug in it.  The other does not.
  27.  
  28. Perhaps you mistake me for someone who has just stepped in from nowhere
  29. to answer this question.  In actuality I have dedicated a few years of
  30. my life to learning many of the intricacies of the C64 and 1541, and
  31. thus I feel like I know what I'm talking about.  There is no bug in the
  32. Scratch command, nor is there a bug in the file-save routine.  If you do
  33. not trust your disk to scratch a file properly or save a file, then you
  34. might as well just toss it out the window.  DOS is not *THAT* buggy.
  35.  
  36. >Chris was almost right.  To avoid it, initialize first:
  37.  
  38. >open15,8,15,"i0":close15
  39. >save"@0:filename",8
  40.  
  41. This is wrong.  The Initialize command will not cause the proper BAM to
  42. be written to disk if the bug is triggered.
  43.  
  44. >Specifying the drive number works.  Scratching first and then saving does
  45. >not (unless you scratch, initialize, and then save).
  46.  
  47. Yes, actually, scratching then saving really does work.  Whether or not
  48. you specify the drive number.
  49.  
  50. >Credit to Ken Arnold for this one: a lot of disk messes blamed on save@ might
  51. >be the result of carelessness about disk ID's and initializing.  (The 1541
  52. >doesn't automatically initialize when a disk is inserted but only if the disk
  53. >ID is different.)  Take a disk out of a 1541 and insert a different disk with
  54. >the same ID, and the 1541 treats it as the same disk and uses the first
  55. >disk's BAM unless told to initialize.
  56.  
  57. This is also not true.  The drive will generally notice if you interrupt
  58. the write protect sensor by removing a disk and inserting another.  It
  59. is very difficult to distract the drive so badly that it will not see
  60. the sensor being triggered.  When the drive does notice a new disk being
  61. inserted, it will initialize on the next disk access, regardless of the
  62. ID of the newly inserted disk.
  63.  
  64. Old 4040 drives did have the problem of not initializing properly when
  65. the same ID was inserted, but 1541's and beyond have nearly erradicated
  66. this problem.
  67.  
  68. -- 
  69. #ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
  70. #define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
  71. #define  FALSE  1   |
  72. #endif              | "911 Emergency Rescue Service - Can you hold, please?"
  73.