8

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.

Maury Markowitz
  • 19,803
  • 1
  • 47
  • 138
  • 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
  • @MauryMarkowitz There's a big difference between block orientated transmission with feedback, like XMODEM, and tape recording. For tape recording all correction must be provided ahead of time without any feedback. Unlike with professional (real) tapes, these machines didn't have away to rewind and check. That's why some BASICs included a verify mode were a tape recording could be (manually) read again and compared to the programm (still) stored in memory. – Raffzahn Jan 27 '20 at 22:18
  • Writing the same thing twice (and doing nothing else) only detects some errors; it provides no correction since you don't know which copy is the right one. If you write blocks of data twice with a checksum in each one, that's different. – Kaz Jan 28 '20 at 13:44
  • @LeoB.: Formatting a tape by writing bit 0 of every even byte, then a CRC of all those bits, bit 0 of every odd byte, then a checksum, then bit 1 of even, a checksum, bit 1 of odd, etc. and then leaving a gap, and then writing the parity of every even byte, and then every odd byte, and a checksum of everything, would not have been particularly complicated, but in exchange for a 15% increase in file size, would have allowed recovery of any error burst up to 5% of the file size. – supercat Jan 28 '20 at 21:26
  • @Raffzahn: If one were willing to use a few hundred bytes or so bytes of ROM on tape I/O routines, it would be practical to implement a block-based ECC that would e.g. write out 18 blocks and guarantee a correct read if any eight of the even-numbered blocks and any eight of the odd-numbered blocks can be read successfully. – supercat Jan 28 '20 at 21:30
  • @supercat "Prohibitively expensive" in my comment is supposed to be understood in terms of computational cost rather than file size. Try writing that in C, mimicking writing as copying from an array to another array and compare the speed of the bytewise copy and of your algorithm. – Leo B. Jan 28 '20 at 21:41
  • @LeoB.: Remember that a data rate of 2000bps would be about 500 cycles per bit. Parity computation isn't wonderfully fast on the 6502, but even a crude "lda (zp),y / and mask / sta temp / lda #0 / ldy #8 / lp: rol temp / adc #0 / dey / bne lp" [bottom bit of accumulator contains bit to write] would only use a fraction of that. When reading back the blocks holding first eight bits of even and odd bytes, make note of which even or odd block, if any, have a bad CRCs. Then fill in the missing bit from each byte with the complement of the parity bit, and then read the parity bit blocks... – supercat Jan 28 '20 at 23:19
  • ...xor'ing the read bits with the proper spot in each byte. If no blocks failed, read the parity bits anyway but with a mask value of zero (ignoring the values read, but letting one know when the end of the file is reached). – supercat Jan 28 '20 at 23:22
  • @Raffzahn - I think you missed the point about writing the blocks twice? This also doubles file size, like Commodore, but catches way more errors. – Maury Markowitz Jan 28 '20 at 23:35
  • 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
  • @LeoB.: The reason people didn't do such things at the time is that cassette interfaces were viewed as toys, not worthy of the level of engineering effort nor ROM space required to make something good. – supercat Jan 29 '20 at 00:09
  • @supercat In the early days cassette was considered serious storage and cassette interfaces were valued add-ons. It easy outperformed punch tape, the other somewhat available storage. – Raffzahn Jan 29 '20 at 00:47
  • @MauryMarkowitz What point? My comment was about having a verify function to check a recording after it has been recorded, not double recording like Commodore did. Also, right, recording data twice does double the tape length, but could you please elaborate how it should 'catch way more errors'? – Raffzahn Jan 29 '20 at 00:57
  • @Raffzahn: Yeah, the term "toy" was a bit strong, but neither reliability nor performance seems to have been regarded as worth investing much engineering effort nor code space. Among other things, it should have been recognized as useful--and not even overly difficult--to have options to trade off load speed versus reliability, so that one could record archival copies of programs at a slower speed, but use a higher-speed format for copies that would be loaded often, and could be replaced if they became unreadable. – supercat Jan 30 '20 at 00:05
  • @LeoB.: Some systems allowed pausing the cassette motor under software control, while others didn't; many ECC approaches would require either having some extra buffer space, a noticeable amount of dead time between the "main" copy of a program and the ECC info, or a means of stopping the tape while "thinking" to minimize such dead time. If one can tolerate the need for some extra buffer space (e.g. use screen RAM for the purpose) and divides data into small sections with a distinctive marker before each and checksum after, such that corruption in one section won't trash later ones... – supercat Feb 05 '20 at 23:45
  • ...then ECC calculations could be done before recording starts or after loading is complete. On the other hand, I suspect the most common cause of data loss with cassettes was accidentally recording over files, and ECC won't really help with that. Still, I've been playing with VICE and I'll let you know what I come up with. – supercat Feb 05 '20 at 23:48

4 Answers4

9

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.

Chromatix
  • 16,791
  • 1
  • 49
  • 69
  • 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
  • 1
    @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 07: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 08:47
9

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.

Leo B.
  • 19,082
  • 5
  • 49
  • 141
5

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

Quassnoi
  • 493
  • 3
  • 9
3

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)

Jean-François Fabre
  • 10,805
  • 1
  • 35
  • 62