From: "Julian Perry"; on Saturday, May 25, 2013; at 8:02 PM -0400 > > As I had recalled, "Inside Commodore DOS" by Immers & Neufield > confirms the bug. (I remember seeing it myself.) Apparently, there are 2 > bugs. > One: the "referred blocks" occasionally will give you track 18 (!). > Two: if a B-A is given to an already existing block, the error channel > will return the next free block, but allocate all blocks on the requested > track (which is what you're seeing)! > > The fix they suggest is quite drastic. It involves M-R reading the > BAM in DOS RAM into a string on the C64 -- doing the block-allocate -- > and, if the B-A returns "No Block" -- M-W writing the allocated block > BACK to RAM, overwriting the damage done. That book is wrong in many places. For example, U1/U2 didn't replace the B-R/B-W commands. They are in different categories: U1/U2 work on disks, while B-R/B-W work on "files" (nameless, random-access files). U1/U2 move sectors, while B-R/B-W move records. A sector that has a record in it has a record-length byte at its beginning. Your program shouldn't touch that byte; the DOS controls it. That's why the "#" buffer pointer starts at offset 1 instead of offset 0. Olaf is correct. The DOS pre-allocates each full track, as a precaution against blackouts (if the drive loses power before the modified BAM can be written back to the disk, then any file data that was written is protected). The disk copy is updated when the DOS moves to a different track -- and, when a file is closed. A fix isn't needed because the block commands aren't broken. They do exactly what they are supposed to do. The bug is in André's program. It doesn't open a "#" file -- and, more importantly, it doesn't close that file! A program must open "#" _before_ any B-A/B-F commands are sent; and, close it _after_ all B-A/B-F commands are sent. It doesn't matter that no data is sent through that buffer. B-A and B-F are block commands; and, block commands work with "files"; so, you must handle them that way. Message was sent through the cbm-hackers mailing listReceived on 2013-05-26 19:01:56
Archive generated by hypermail 2.2.0.