On Fri, 12 Oct 2001 ncoplin@orbeng.com wrote:
> Hi All,
>
> I need some advice about the B-A command as I'm in the middle of
> implementing this support to 64HDD and my thinking is to fix the bug(s)
> rather than implement them, but am wary of compatibility.
>
> Does anyone know if the B-A bug (which when a block is already allocated, it
> allocs the whole track and jumps to the next track to search for a free
> block) is only a 1541 trait, or whether it is also in the 1571 and 1581
> ROMs?
In my experience, it does not do that. I routinely allocate blocks that
are already allocated without the problem you mention. There is a problem
with whether the information in memory is current, and whether you have
closed the files properly.
When allocating blocks, I routinely access a different track when done.
This forces the BAM on the disk to be updated. Actually, you need to
access 2 different tracks as the BAM information for 2 tracks is kept in
memory. If you remove a disk before the BAM is updated, problems that you
described, and others can occur.
Another problem is that, the BAM information in memory is not updated
until it is needed. If you have finished working on the disk and closed
all the files correctly, the drive can report incorrect information, since
it will not check the correct information on the disk until you relog the
disk. In short, once the files are closed, the BAM information in memory
is not guaranteed to be correct.
> Also, there is the question of allocation on the directory track. The 1541
> as I understand it can return a free block in Track 18, which supposedly it
> shouldn't. Do the 1571 and 1581 drives also point to their respective dirs
> (eg 18/53 or 40) when the next block is given?
Allocating blocks on the directory track is perfectly legitimate. After
all, the system would not know if there was any directory space left if it
could not do that.
This information applies to the 1541 and 1571. The 1581 does not
work in the same way. It keeps the entire BAM in memory. When you close
the files, the BAM is written to the disk, but the BAM in memory may not
be updated unles you remove the disk and reinsert it.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.