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.