The Commodore PET/VIC-20/C64 tape routines write out the leader for each file twice, and then write the data twice. While it would seem that this should allow data to be loaded more reliably, experimenting with different kinds of corruption suggests that any problems on the tape are prone to render it unreadable, even if there is a complete undamaged header and a complete undamaged copy of the data.

The Commodore tape format certainly provides enough redundant information that a suitably-designed loader would be able to recover from any dropout which is shorter than the gaps between the two copies of a file header, or between the two copies of a file. As such, it would appear to be an example of a cassette format that uses a crude form of error-correcting code (as alluded to in the other question), but the load routines found in the VIC-20 and C64 don't seem live up to that promise.

Are there cases where the redundant information stored on the tape would allow successful loading of data that would otherwise be lost? Or is the intention simply to provide extra assurance that if both copies retrieve identically the data is almost certainly correct? Or perhaps tape format was designed for the PET, which might have had enough ROM space available for a more sophisticated tape loader?

  • 2
    Does this answer your question? Cassette formats using ECC? – Jean-François Fabre Oct 30 '20 at 21:07
  • I read that question as asking whether cassettes used anything like Hamming codes as a means of performing forward error correction without requiring that everything be sent redundantly. – supercat Oct 30 '20 at 21:09
  • @Jean-FrançoisFabre: Another way of looking at the distinction is to observe that the other question asks about which systems recorded enough redundant information that even if the tape is damaged, the portions that are readable would allow reconstruction of the original. Commodore's tape format certainly holes enough redundant information that a suitably-designed loader could recover data from a damaged type. My question is about the circumstances where Commodore's actual loader would be able to make use of the redundant information for that purpose. – supercat Oct 30 '20 at 22:48
  • 1
    @Jean-FrançoisFabre: I've edited the question. If the C64 and VIC-20 routines don't provide any means of handling tape images that don't have two valid complete copies of the data, that would raise the question of whether the use of two complete copies was intended to allow recovery, but the code for that never worked, or perhaps it worked successfully on the PET but would have taken too much ROM to fit in in the VIC-20 kernel. I would expect that a detailed answer to the former question would also address the latter. – supercat Nov 1 '20 at 17:18

What I've heard from people who should know, is that it's simply a form of error checking, not error correction. The data is always read twice, but the second time it simply checks that the data read from the tape is what is already in RAM. Most other systems, even at that time, used a CRC to do the same job more efficiently.

Of course, you can theoretically use the data stored on whichever copy is "good" to reconstruct the file. But the stock KERNAL routines didn't give you any help with that.

  • There was also a parity bit which was checked, but indeed no error recovery. – Michael Graf Oct 30 '20 at 15:34
  • I find myself bewildered by that. It would seem easy, logical, and useful to say that if the first attempt to load yield a parity error, the system should listen to the tape until it finds the start of the second copy and then load that instead of the first, and back in the day I thought that's what the system tried to do. I can't imagine thinking it would be a good idea to write data twice if such recovery wasn't intended. – supercat Oct 30 '20 at 15:39
  • @supercat It could easily be the case that such more intelligent routines exist, perhaps in one of the several fastloader cartridges. A lot of Commodore's design decisions seem baffling in retrospect. – Chromatix Oct 30 '20 at 15:48
  • 1
    I also remember reading in, I think, Mapping the C64, that some storage was reserved to hold the locations of data errors that were found on the first pass through the tape, which would suggest an intention to attempt data recovery. Perhaps a fundamental problem is the lack of a three-way report for "Tape seems good; data loaded successfully", "Tape is bad, but data was successfully recovered and seems reliable, so it should be copied to a better tape", or "Tape is bad; data is partially or totally meaningless". – supercat Oct 30 '20 at 16:20
  • So if the first pass maps the locations of data errors, then what does the second pass do if not to fill in the bad spots? – snips-n-snails Oct 30 '20 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.