The Commodore systems famously wrote everything to the Datasette twice as a form of error correction. Most other formats I've looked at - Atari, CUTS and CoCo - lack any form of correction.

Is anyone aware of a format that used ECC on cassette storage? I assume this was not uncommon in non-cassette formats of the era.

  • 5
    Due to the nature of typical errors, simpler ECCs, like Hamming, would be of no use, and more complex ECCs would be prohibitively expensive. – Leo B. Jan 27 '20 at 16:49
  • @LeoB. Sounds like spot on - mind to format this comment into an answer? – Raffzahn Jan 27 '20 at 17:55
  • 1
    @LeoB is correct - there is a difference between the kind of ECC you use to protect RAM and the kind of error-correcting code you use for burst errors that occur on magnetic media (due to bad spots on the oxide) or in data transmission circuits (due to general bursty electromagnetic noise). – davidbak Jan 27 '20 at 19:30
  • I'm not talking about the sort you would use to protect RAM, but one more suitable for burst noise. XMODEM would work, for instance, double-writing the packets and discarding if the first failed. In that case you'd fix maybe 99% of all errors, but only have to read one extra packet in the case of a failure instead of the entire file. There are many possible solutions, and I assume other transports used something. – Maury Markowitz Jan 27 '20 at 21:31
  • 1
    @supercat Would you care to try implementing what you've described and testing it with a simulator? Given that a lot of likely much more highly motivated people have not done that at the time, I'd conjecture that there were obstacles which you don't readily see. – Leo B. Jan 28 '20 at 23:56

Use of error-correcting codes was not common in home computers until at least 33.6Kbps modems and/or gigabyte-sized hard disks were available. One of the earliest consumer applications of ECC (in the form of two-dimensional Reed-Solomon codes) was the Compact Disc.

Until then, error-detecting codes such as parity and CRC were reasonably common, including in TCP/IP packets and floppy disk formats. If an error was detected, the computer might try a second time to read the data. Often this worked, and the extra time taken would alert the user that renewing the media might be a good idea.

  • 1
    "the computer might try a second time to read the data". That means that the computer controls the rewind and is able to retry a cassette read? – Jean-François Fabre Jan 27 '20 at 18:28
  • 4
    @Jean-FrançoisFabre if it's an Acorn, it just asks the user to rewind a bit. That machine uses 256-byte blocks, and has an on-screen count of the current block. So if any block fails its CRC check, it asks the user to rewind and the feedback is present to tell you whether you rewound too far, or not far enough, or whether it is currently re-reading that block. It has play/pause motor control, as do some other machines, but probably only the Coleco Adam with its weird tapes has full-on rewind/fast-forward control? – Tommy Jan 27 '20 at 19:21
  • 2
    @Jean-FrançoisFabre I did say "might"; it's relatively easy to arrange on a floppy disk, and in TCP/IP the corrupted packet is treated as dropped to trigger a retransmission. As noted, the BBC Micro also has a way to request a re-read on tapes. – Chromatix Jan 27 '20 at 23:11
  • @Jean-FrançoisFabre My home-made Z80 computer of the 80s had a cassette drive with solenoids for every function. There were no buttons to operate, but for ejecting the cassette. – the busybee Jan 28 '20 at 7:06
  • 1
    how modern it was :) I only had a manual tape player that operated only on batteries. If you plugged in A/C the interference of the mains made the data unreadable... – Jean-François Fabre Jan 28 '20 at 8:47

Due to the nature of typical errors, simpler ECCs, like Hamming, would be of no use, and more complex ECCs would be prohibitively expensive.

For example, a burst of noise will corrupt several bits in a row, and if we're unlucky, and depending on the encoding mechanism, the synchronization may be lost, thus rendering all bits up to the end of a block or the file incorrect.


The Oric Atmos (not the Oric 1) had some kind of error detection (that was broken in the first version of the Atmos ROM) which printed "errors found" (without any further details) when loading encountered an issue. It wasn't based on a checksum, but rather on detecting a proper read of each byte of the tape (if it was using parity, it's at the hardware level).

When you saw that message (on a machine with the corrected ROM), it was generally too late (or the tape volume/speed required adjustment)

The Oric Atmos ROM also introducted an option to check the saved tape. Basically the user:

  • saves the data to tape (CSAVE "MYPROG")
  • rewinds the tape
  • loads the data back using "verify" option (CLOAD "",V)

That option loads and compares against the machine memory (not storing the data twice, but saving+checking doubles the time needed to save the data). If everything could be loaded once, at least it means that the save was successful (repeat process with another tape/another volume settings until it succeeds). And unless the tape rots, there's a good chance that the tape can be loaded again in the next future.

Those were heroic times, on amateurish computers, where it was admitted that you could lose your data from time to time (I lost a lot of work, just because sometimes I was too lazy to check my saves)

At least the Oric Atmos proposed a way to make sure that the save worked, without needing a second computer to load the saved data…

(Well, better save it on another tape from time to time, just to be sure)


Not sure if VHS counts as a cassette storage, but ArVid did use ECC (Hamming in older models, Reed-Solomon in later models).

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.