From: Greg King (gngking_at_erols.com)
Date: 2004-09-09 09:17:57
From: Baltissen, GJPAA (Ruud); on Date: August 31, 2004, at 03:11 PM -0400
>
> - The CBM drives keep a copy of the BAM in memory. CBM-HD doesn't;
> it loads the according BAM sector, changes the bit,
> and saves the sector again. More reliable IMHO. OK,
> more I/O, but a very acceptable price.
Commodore drives buffer the BAM because they move their heads slowly (from
a file's tracks to the BAM's track, then back to the file's tracks). A
hard-disk drive is much faster; but, it really doesn't matter! Both modern
operating systems and hard-disk drives have caches; so, the physical effect
is the same: CBM-HD writes the BAM alot, but the drive doesn't.
>
> ... one question:
> at what point is the BAM in memory written back to disk?
CBM DOS uses two buffers: the BAM is read into a channel buffer, and two
track's worth of that BAM is copied into a "scratch" buffer. Those entire
two tracks are "pre-allocated" in the BAM which, then, is written back onto
the disk. As files are written/deleted, the scratch buffer is changed.
When the DOS wants to write/delete on a track that isn't in that buffer,
the older of the two tracks' BAM is copied back to the channel buffer, the
new "current" track's BAM is copied into the "scratch" buffer, it is
"pre-allocated" entirely, and the BAM is written onto the disk. I believe
that both tracks' BAMs in the "scratch" buffer are updated on the disk when
a file is closed.
By the way, that process is part of the reason why people used to think
that the "B-A" and "B-F" commands have a bug. They thought that those
commands mistakenly affect a full track instead of the single block that a
programmer wanted. The truth is that they do -- but, it's not a mistake!
The real bug was in the programmer's code: it didn't open a "#"
buffer-file, and/or didn't close it when the program was finished.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.