Re: Commented 1541-II DOS disassembly

Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <smf@null.net>:
> On 26/08/2018 17:29, Rhialto wrote:
> 
> > I don't remember with certainty if there were alreay rumours about
> > the bug at the time of the 4040 (as Wikipedia states), but there
> > could have been. If there indeed was a problem, the explanation
> > would likely be different than for the 1541.
> 
> If the fixes in that article actually work (which commodore seem to 
> think they do) then it would seem likely that the 4040 bugs are
> different.
> 
> It doesn't come as a surprise that commodore could manage to mess up
> the same thing twice.

For the 1541 there are three different factors that's all needed to
trigger the bug.

One thing is the "phantom drive" thing which is fixed here, making all
five buffers free.

One thing is that five buffers are needed at all. To conserve buffers,
the new version of the file could be saved with a special file type,
and when the save is complete that could be detected by the normal
save routine, and the old file scratched, and the normal scratch
routine could search for a file with a special file type and change
that to the normal file type. This could be considered not a bug as
there really are five buffers in an otherwise bug free drive and there
isn't much use for being able to SAVE@ while also having other files
open at the same time.

One thing is that the drive seems to allow allocating (and
deallocating?) sectors on more tracks than it can cache BAM for without
somehow forcing a BAM update or just abort the operation. This is IMHO
the real bug that causes corruption, although it's the "phantom drive
buffer" bug that triggers this bug and also that bug fix also makes
SAVE@ work better. But fixing this bug would mean that SAVE@ would just
fail instead of cause corruption in cases where SAVE@ cannot do it's
job (like with some other file open at the same time).

I'm not sure how the 4040 and it's siblings work, but at least the last
factor might be present there too, at least if it allows the BAM to not
always be in a buffer. Although with 12 buffers it would require a
bunch of buffers in use by open files to trigger that last bug. That
would only happen if you SAVE@ your program while it has exited without
closing it's files.

Another trigger, both for the 4040 and 1541, and similar drives if they
have the bug, is if using a peripherial sharing device like VIC Switch
or it's sibling PET Switch / MBS (German name Mehrbenutzersystem). In
such case it's fairly reasonable to assume that one client can have
files open on a drive while another client uses SAVE@. For educational
usage it might not have happened that much as using data files from
self written software might be something that a school would never
reach, so a sAVE@ bug could probably mostly be triggered if some user
uses word processing software or similar while some other user writes
code and uses SAVE@. For office use it's not that likely that SAVE@
would be used at all, except for software development and it seems
likely that a software development company could afford one drive for
each user.

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.