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.