Re: Commented 1541-II DOS disassembly

From: smf <smf_at_null.net>
Date: Mon, 27 Aug 2018 12:00:10 +0100
Message-ID: <2fb8c5f6-733a-afec-e981-1bab7758d45b@null.net>
On 27/08/2018 11:09, Mia Magnusson wrote:
> 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.

I thought it tried to force a BAM update, but it fucks up due to 
stealing it's own buffer.

You can argue there isn't enough checking going on, but they have 
limited rom space.

You could argue that it should fail and force the user to close handles, 
but I assume they came to the decision that saving a program was a 
higher priority.

In the 1541 case the buffer shouldn't even have been allocated. I think 
it's interesting that they didn't fix that bug & instead allowed the 
buffer to be stolen.

I guess they were scared that having 5 buffers free all of the time, 
while earlier drives would only have 4, would be a compatilibity nightmare.
Received on 2018-08-27 14:00:05

Archive generated by hypermail 2.2.0.