prindle@nadc (05/02/86)
From: prindle@NADC I've already documented a reproducable problem with the 1571 drive - that of specific situations in which a file open for writing and residing on the second side of the diskette is written extremely slowly. However, I've also from time to time been the victim of another strange behavior. Specifically, if a program has several files open (e.g. one read and one write), and the file being written fills up the first side and proceeds to the second side, it sometimes happens that the "next-track/sector" chain through the file gets broken prematurely and/or the directory entry does not point to the correct first track/sector of the file. The net result is that the written file, once closed, is recorded in the directory as having a certain length, but is much shorter than that when read, and contains incorrect or out of sequence information. The total block count for the diskette becomes wrong, and scratch- ing the file does not recover all the blocks; it is necessary to do a validate to get the block count correct again. (Note that none of this applies when the 1571 is being accessed by CP/M, since in this case the drive is only being utilized to do random block reads/writes with all directory and allocation information maintained by CP/M itself.) Now this is about as reproducible as the infamous "@(replace)" bug, and of course always happens when I'm busy trying to do something else and don't have time to track down the problem or record the exact circumstances of the failure. However, it has happened enough times (3 or 4) with similar results, that I am fairly convinced that it is not a result of human or random electronic error. I would appreciate hearing from readers of this list about their experiences which would tend to either confirm or deny the existence of such a problem. If there is a problem, a simple program which will consistently demonstrate the failure would go a long way in convincing Commodore to search for a bug and manufacture updated roms with the fix. I stress *simple*, because all of the test cases which supposedly "prove" the "@(replace)" bug are so outlandishly complicated that they won't be taken seriously by Commodore. The 1571 is a wonderful drive in many ways, and it would be a shame for it's reputation to suffer from readily correctable firmware bugs. I, for one, would be more than willing to shell out 10 or 15 bucks to get updated roms from Commodore, provided they would break down and admit whatever problems these were supposed to fix. Cheers, Frank Prindle Prindle@NADC.arpa
fred@cbmvax.cbm.UUCP (Fred Bowen) (05/05/86)
> From: prindle@NADC > > I've already documented a reproducable problem with the 1571 drive - that of > specific situations in which a file open for writing and residing on the second > side of the diskette is written extremely slowly. However, I've also from > time to time been the victim of another strange behavior. Specifically, if a > program has several files open (e.g. one read and one write), and the file > being written fills up the first side and proceeds to the second side, it > sometimes happens that the "next-track/sector" chain through the file gets > broken prematurely and/or the directory entry does not point to the correct > first track/sector of the file. The net result is that the written file, > once closed, is recorded in the directory as having a certain length, but is > much shorter than that when read, and contains incorrect or out of sequence > information. The total block count for the diskette becomes wrong, and scratch- > ing the file does not recover all the blocks; it is necessary to do a validate > to get the block count correct again. > they won't be taken seriously by Commodore. > > The 1571 is a wonderful drive in many ways, and it would be a shame for it's > reputation to suffer from readily correctable firmware bugs. I, for one, > would be more than willing to shell out 10 or 15 bucks to get updated roms from > Commodore, provided they would break down and admit whatever problems these > were supposed to fix. > > Cheers, > Frank Prindle > Prindle@NADC.arpa Please Frank! You've gotta have a tough hide in my position. I can confirm everything you have mentioned, even the '@' replace bug. No secrets here- I have been stung by these bugs many, many times, and it should please you to know I not only admit it, but have done everything I can to get them fixed! New ROMs for both the 1571 and c128 are due to be released from here this week. I cannot tell you how long it will be before you guys, our valued customers, will see them. I have suggested to the powers that be to make these 'update' ROMs available, albeit at some cost, to current owners who ask for them. I'll keep the net posted. In the meantime, I could post my list of c128 bugs and their status (statii?). Would that help? By the way, you're analysis of the 1571 bugs is correct- it is a side1/side2 BAM problem. Hint- writing to side 2 can be sped up considerably if you use the SAVE secondary address for WRITE files (1, that is). This too is a bug that has a solution in the works. Note that I am the c128 'guru', not the 1571 one- but I can put my foot in my mouth better... -- Fred Bowen uucp: {inhp4|seismo|caip}!cbmvax!fred arpa: cbmvax!fred@seismo.css.GOV tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380