Re: Commented 1541-II DOS disassembly

From: Mia Magnusson <mia_at_plea.se>
Date: Mon, 27 Aug 2018 13:35:30 +0200
Message-ID: <20180827133530.00007423@plea.se>
Den Mon, 27 Aug 2018 12:00:10 +0100 skrev smf <smf@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.

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.

It's kind of obvious that they came to the conclusion that the code
wouldn't fit in a smaller ROM space (like 8k or 12k) and then just
reused as much as possible from the larger drives without much thought
about what would actually be usable.

> 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.

It should somehow put the disk in a state where it's obvious for a user
that it needs validation. (If a validate would solve the mess SAVE@
might create, as I understand it it does).

> 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.

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

Btw where the SAVE@ function a part of the very first Commodore drives,
or is it an add-on? If it were part of the first drive, are there any
evidence of it being planned from the beginning or a later add-on?

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. This of course assuming that there were no way of using
page 2 as a buffer.

In theory, they might have just concluded that "SAVE@ seems to work,
we'll include it" after choosing RAM size, while other parts of the ROM
might had been written and tested before SAVE@ became part of the ROM.

Or more probably they inherited SAVE@ from the larger drives and just
didn't test things properly.

> 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.


-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.
Received on 2018-08-27 14:02:11

Archive generated by hypermail 2.2.0.