Re: Commented 1541-II DOS disassembly

Den Tue, 28 Aug 2018 10:58:09 +1000 skrev Julian Perry
<jp@digitaltapestries.com>:
> Re: Commented 1541-II DOS disassembly Hello Spiro,
> 
> Tuesday, August 28, 2018, 6:17:23 AM, you wrote:
> 
> > Hello,
> 
> > * On Mon, Aug 27, 2018 at 12:09:07PM +0200 Mia Magnusson wrote:
> >> Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <smf@null.net>:
> >  
> >> 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.
> 
> > But in this case, you are not better than doing a:
> 
> > SAVE "NEWFILENAME",8
> > OPEN 1,8,15,"S0:OLDFILENAME"
> > PRINT#1,"R:NEWFILENAME=OLDFILENAME"
> > CLOSE 1
> 
> > That is, you need enough space on the disk for both variants, the
> > old and the new file.
> 
> > The "nice" thing about SAVE@ is that this is not needed. You just
> > need the space for the maximum of the size of the old file and of
> > the new file.
> 
> 
> > BTW, all speak about SAVE@. What about writing a file with @, that
> > is:
> 
> > OPEN 1,8,2,"@0:MYDATEFILE,S,W"
> 
> > I would expect that the bug would trigger here, too? Or is it really
> > specific to SAVE@?
> There are some shortcuts when saving a file, as opposed to writing a
> sequential file.
> 
> Most notably with SEQ files the BAM is updated whenever a new track
> is required. With a PROGRAM file the BAM is only written out once the
> program file is closed after the save (I think the drive determines
> this from the Secondary address: if you write out a sequential file
> as "filename,p,w" but with a SA of (say) 2 it will still update after
> every track, but I'd be happy to be corrected). You can notice this
> just from the head motion. Neufield might have something on it.

So, will the SAVE@ bug be triggered if you do this?
SAVE "@FILENAME",8,2
(I assume that the drive itself cannot know the difference between SAVE
and OPEN for write, but I might very well be wrong here)


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