How much data could a home computer store on an audio cassette?

Question

The use of audio cassettes for storing data for home computers was a great example of repurposing an existing invention. Cassettes were sold in a variety of capacities, and labelled with their audio capacity, e.g. a C60 cassette would hold 60 minutes of music.

Cassettes sold for use with computers tended to have a far smaller capacity, typically 15 minutes or less. But while floppy disks were labelled by capacity in bytes, data cassettes were still labelled according to their length (in time). One reason for this is that different computers used different formats, so there was no universal figure to quote.

The Kansas City standard (or Computer Users' Tape Standard) of the 1970s used a 300 baud data rate. After wrapping every 8 bits with a start bit and two stop bits, each byte uses 36.7ms on the tape, making for a raw capacity of ~27.2 bytes per second, or ~1.6 kilobytes per minute. A C15 cassette would therefore have a capacity of just under 24 kilobytes per side. Arranging data into blocks, or the addition of a file name or CRC checks in more advanced formats would reduce this.

A shortcoming of the Kansas City standard was the low data rate, which meant long program load times, and so most home computers used their own, higher capacity formats instead.

I'd like to know how much data the user of a typical microcomputer of the 1980s could expect to store on their cassettes, for comparison with the more clearly stated capacity of floppy disks. As there are too many different formats to ask about in general, I'll narrow the question down to the highest capacity achieved by a commercially released home computer, to give a high-water mark to compare with. Answers in terms of "X kilobytes on a C15 cassette", or "X kilobits per second" would both be acceptable.

So my (rephrased) question is: What was the highest capacity format used by a home computer to store data on an audio cassette?

Answer 1

As other answers note, the data rate varied considerably between machines. I'll give two concrete examples from popular machines - the BBC Micro and the Commodore 64.

---

Acorn adopted the 300-baud "Kansas City" or "CUTS" format for their early machines, and adapted this for higher performance with the BBC Micro. The basic baud rate is 1200, stored using ordinary TTY-modem style 1200/2400Hz FSK, but there is a lot of byte and block level framing which dilutes this in practice.

The standard block size is 256 bytes, plus 24-33 bytes of header and trailing CRC (depending on length of filename), each byte taking 11 bit times (8N2 serial framing). This totals 3080 bits per frame with a 1-character filename, taking 2.5667 seconds on the tape. Add 1.3 seconds of sync tone to allow stopping and restarting the tape motor between blocks.

A long file might thus approach 256 bytes per 3.8667 seconds throughput, or 66.2 bytes per second, in the standard format on the BBC Micro. It was possible to use longer blocks to speed up bulk loading directly into memory, but these files would then not work with the standard byte-by-byte file reading routines; probably some commercial games used this trick to speed up loading and reduce tape manufacturing costs.

At this speed a C30 tape (15 mins per side) could hold a little under 60KB per side.

---

The C64 had a standard format supported by the KERNAL ROM, and additionally many "fastloader" formats supported by first loading a tiny program in the standard format. Let's start with the standard format, which was designed for robustness rather than speed - its lack of the latter naturally inspired the many fastloader formats.

Instead of FSK, the C64 uses square-wave pulses of three different lengths (352, 512, 672 µs). Each byte consists of 9 bits stored as either a short then medium, or a medium then short - so the total length of each bit is constant. This is followed by a 10th marker bit which includes a long pulse and usually a medium pulse. Thus the total length of each byte is 672+9*352+10*512 = 8960µs, or 111.6 bytes per second raw.

However, like the BBC Micro there is also overall framing which dilutes this somewhat. Most notably, every file is stored on the tape twice in four blocks (HEADER, HEADER REPEAT, DATA, DATA REPEAT). Unlike the BBC Micro however, the data block is continuous (except for SEQ files) and not broken up into smaller blocks. So for large files the data rate for calculating C64 tape capacity approaches half the raw data rate, so about 55 bytes per second. However you could technically use a tape of half that length, and only lose the backup copy provided afterwards.

At this speed a C30 tape could hold about 48KB per side.

C64 fastloaders generally adapted the standard format at the bit level by dropping one of the two pulses needed to store each bit - so either one short or one medium pulse made one bit, and the overall bitrate would be somewhere between the two. Then they would make the pulses themselves shorter and remove some of the less essential robustness features of the standard encoding. There is usually not even an explicit marker between bytes!

An average bitrate of 360µs or 2778bps was typical for fastloaders, though some went significantly faster than this. The overall speed of a large C64 Fastloader file would thus be about 347 bytes per second.

At this speed a C30 tape could hold about 300KB per side, and would be practically as fast as the (rather sluggish by any standards) 1541 floppy drive.

Answer 2

The SAM Coupé had a ZX Spectrum compatible tape data format with programmable save speed and automatic load speed detection. According to the Technical Reference Manual:-

Speed 112 is spectrum speed, 35 is much faster. Faster speeds are less reliable - but 3*spectrum speed should be feasible with many recorders.

The Spectrum saves at ~1500bd average. 3 times that equates to 4500bd average, or 563 bytes/second. So, ignoring the lead-in, header, sync and checksum bits - a C15 tape would theoretically be able to store 15*60*563 = ~500kB on average.

Answer 3

Update: Well, with the question being edited to ask for kilobytes per second,

So my question is: What was the highest capacity format used on an audio cassette, in terms of kilobytes per second?

the whole answer becomes rather simple (*1):

Divide the baud rate by the average number of bits a format used per data byte to get an average KiB/s value.

Thus, it again comes down to the Baud number (see all the way down).

---

Original answer:

Cassettes used with computers tended to have a far smaller capacity, typically 15 minutes or less. But they were still labelled according to their length, not their data capacity. One reason for this is that different computers used different formats, despite an attempt in the 1970s to create a universal standard.

No, it wasn't. These cassettes featured nothing computer specific. They are simply music cassettes (*2), thus made to run in the same devices (cassette recorders) at the same speed, 4.7625 cm/s (or 1.875 inch/s), thus ~2.85 meter equals one minute, or 42.75m for a C15.

That standard, the Kansas City standard (and the related Computer Users' Tape Standard)

CUTS is Kansas City (see this Question/Answer) - the naming just depends on what association was intended (or avoided). Kansas City if association with Byte magazine was OK, CUTS if not - or in the case of Processor Technology, because they defined it under that name. For more information see this Question/Answer.

used a 300 baud data rate. After wrapping every 8 bits with a start bit and two stop bits, each byte takes 36.7ms of tape, making for a raw capacity of ~27.2 bytes per second, or ~1.6 kilobytes per minute.

Part of the failure of the Kansas City

You wanted to state that CUTS wasn't a failure, as it had been adopted by many manufacturers and sold with millions of computers, right?

So my question is: How much data could these other formats fit on a 15-minute cassette?

Since there in an almost infinite number of formats and use cases, it would be way too broad to answer this. But there's a simple way to get close for machines you're interested in:

• Step 1: Multiply the baud rate (as its bit/second) of the format in question by 900 (eliminating time and reducing it to the medium in question) to get a gross capacity in bits.

• Step 2: Divide that by the number of bits this format records per byte (like 10 for many) and you'll get the gross capacity in bytes.

• Step 3: Subtract the overhead and you'll get the net storage capacity in bytes.

Step 3 may be the most difficult, as block structure and length may depend a lot on what is stored. One large file or many smaller, each with their own headers. Similarly, how much space a user will leave between files to find them later on..

Writing one large block with next to no header will result in almost the gross capacity, while a recording like those used by Commodores, with small blocks, long headers and double recording (for program storage), will yield way less than 50% - with more than one program per tape easily as low as 20%. Since a tape can also store data as well as programs, and data may even be formatted in its own way, it's a pure guessing game.

All of this makes it almost impossible to give even a close number without exact specification of the existing/intended usage.

Following on from that, Which cassette format could store the most data on a C15 cassette?

Look for the one with the least bits per byte and the least overhead. In any case it'll be less than the gross capacity calculated in step 2. In some cases maybe 10% less, in others more than 50%. Your guess is as good as mine.

Bottom line, for a rough comparison, the baud rate will do the job - everything else is application specific.

---

With that in mind a baud rate table like this can be made:

• TRS-80 Model I: 250 (Level 1)/500 (Level 2) Bd
• ZX 81: 300 Bd
• CUTS: 300/600/1200 Bd
• Acorn (CUTS variant): 300/1200 Bd
• Atari 400/800: 600 Bd
• Amstrad/Schneider CPC: 1000/2000 Bd
• Apple II: 1500 Bd (average)
• IBM PC 5150: 1500 Bd (average - Apple II alike)
• ZX Spectrum: 1500 Bd
• ZX Spectrum may reach (non standard) 9600 Bd or even more

It might be noteworthy, that depending on recorder and tape material the theoretical maximum when using real cassette material and existing heads is somewhere between 20,000 and 35,000 Bd. But that would need encoding techniques way past 1980s micros.

---

(Microcomputer) tapes aren't a blocked random access media like disks (or mainframe tapes) - they are in themselves random :))

---

*1 - Which in turn makes it somewhat ridiculous.

*2 - Except eventually being sold at a higher price per minute :))

Answer 4

The Nascom II reached 2400 bps with synchronous keying of 2400Hz and 1200Hz and had discrete logic for recovering data. It was very robust and even damaged tapes with audible flutter and loudness variations were often properly read.

I do remember that at the end of the cassette storage era (and beyond) people built cassette interfaces and/or decoding software that put remarkable data rates (approaching IDSN modem data rates) on stereo tape decks with the caveat that you needed to replay them on the same device because identical head alignment was crucial (holds for best analog audio similarly of course). But those devices/software were not standard equipment in any manner and so likely did not exist in numbers exceeding a few hundred.

Answer 5

Back in the days I owned a ZX spectrum clone (still working today). My favorite game was the Elite and after the screen it loaded "large" ~35KByte file containing the game and it loaded in ~5 min That gives The MG cassette loading speed:

35*1024 / 5*60 = ~119.4666 Byte/s

counting just the useful data (no parity bits or CRC ands stuff so just useful data transfer rate).

Back in the days we usually used 90min audio tapes giving approximate capacity of:

119.4666 * 90 * 60 = 645120 Byte = 630 KByte

This matches my experience as latter on when I was transferring my old tapes onto floppies (5.25" DS DD formated to ~420 KByte) single 90min MG tape used cca 1.5 floppies to store the same amount of data...

Of coarse there where turbo loaders and comprimation loaders out there improving the total MG capacity even further.

Answer 6

In 1977 I had a portable cassette recorder with an RS-232 interface that supported 9600 baud. So the capacity depended on the length of the tape. I only needed 64k so that was not an issue with a 30 min tape. It was error-free and I used it (prior to modems) to transport MC6800 code from University ( Prof Compilers was contracted to do the work) then back to Work at Bristol Aerospace Ltd. to burn into UV erasable EPROMs. They never failed. It was downloaded from compiled code on a PDP11? then uploaded to an MOT Exorcisor.

Other times I monitored half duplex data on both Rx Tx using diodes with 3K to ground in a Diode OR arrangement, knowing the threshold for RS-232 was the same as TLL = 1.3V, I didn't need bipolar levels. This helped me monitor my SCADA designs with up to 1 hr data logging and test results between a couple HP9825's that interfaced to smart HP terminals. But the HP9825's had high-speed cartridge drives in 1978 for supporting the autosave of program parameters for instant POR reset recovery. My first HP Basic computers for my 2nd SCADA project in 1978. It was the first time I used DMA and mapped the keyboard into a custom pushbutton SCADA remote control console with real-time ADC and digital feedback.