Re: Commented 1541-II DOS disassembly

From: smf <smf_at_null.net>
Date: Mon, 27 Aug 2018 20:43:56 +0100
Message-ID: <c7dc258a-2bb7-b121-d67b-f2410949c789@null.net>
On 27/08/2018 12:35, Mia Magnusson wrote:
> Yes, but some stuff in the ROM is IMHO rather useless on a single
> drive, like the copy function. That function might btw be the function
> that are second in a "competition" of which function uses the most
> buffers.

I get the impression they pretty much hacked up the code for the single 
IEEE 2031 drive on a friday afternoon and then hacked the IEC code in 
over a weekend.

Adding extra checking code, which they weren't aware they needed, was 
not on the cards.

> It should somehow put the disk in a state where it's obvious for a user
> that it needs validation.

Why? Surely save@ should just work. If it is too buggy to work, then how 
can you guarantee that validation will be good enough to fix it?

> Maybe the "steal buffer" might had been intended for something else,
> and it just made the SAVE@ bug a little harder to trigger.

 From the description it seems the steal buffer is used whenever an 
operation needs a buffer and there aren't any free.

What save@ didn't expect is that one of it's own buffers would be stolen.

> The reason that the 1541 has 5 buffers is surely that 1 buffer (1k ram)
> would be too few, and the next step using reasonable hardware (2k ram)
> is 5 buffers.

I suspect it has 5 buffers, because save@ requires 5 buffers.

> Or more probably they inherited SAVE@ from the larger drives and just
> didn't test things properly.
Standard commodore testing, they turned it on a couple of times and it 
didn't always catch fire.

>> 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.
> Rather that any general change might disturb some weird copy protection
> scheme.

That is what I meant by "compatilibity nightmare."
Received on 2018-08-27 22:00:05

Archive generated by hypermail 2.2.0.