My colleague and I have just had a conversation and we were wondering how the process of developing an application was done in the era of cassette tapes.

Today we have HDDs, backup HDDs, FTPs, repositories in the cloud, etc. -- so we don't care: we just save, send and share our data, but...

I myself, as a child, had a Timex 2048 (ZX Spectrum clone) in the 90s and I remember that creating an application involved saving my work on the tape, then next day I loaded it into Timex's memory, made changes, saved on the tape again and so on. But I worked alone for my own happiness and the applications I created weren't complex.

But what about cases when there were two or more developers? How did they share their code?

What about complex applications? Graphics (simple, but still) for games?

What about the durability of their work? We all know that cassette tapes were very unreliable: errors during saving and reloading data were common. (Eventually FDDs became available for computers such as Spectrum, Atari and Commodore, but as far as I remember they were quite expensive; and they weren't available from the very first moment, were they?)


Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.

Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.

So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.

Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.

In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.

So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.

  • 6
    The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it) – Frédéric Grosshans Aug 29 '18 at 16:45
  • 1
    @FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer) – jacek.ciach Aug 29 '18 at 17:46
  • 2
    "*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter. – scruss Aug 29 '18 at 21:50
  • @scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it. – Will Hartung Aug 29 '18 at 22:52
  • 1
    @WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources. – J... Aug 30 '18 at 13:38

Probably, no serious software development was done purely on tapes. Floppies were used extensively, as well as cross-tools, ROM emulators etc.

This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.

  • 1
    That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ... – scruss Aug 30 '18 at 4:38

What about complex applications?

You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.

Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.

The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.

But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.

I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.

  • 2
    “The period where cassettes were the only form of storage on micros was basically zero.” That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives). – Stephen Kitt Aug 29 '18 at 18:04
  • I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist. – scruss Aug 29 '18 at 21:52
  • @scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s? – Maury Markowitz Aug 30 '18 at 19:14

It depends a lot on the machine, the job and your team size and what time we're talking.

Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.

Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.

Compared to today it was way more a world of single coding heroes than teams.

At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.


If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.

I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.

The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.

I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.

In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.

Each module initialized its locations in the jump table when it was loaded.

The process of creating the program was:

Assemble each module, writing its object to tape as absolutely located binary.

Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.

Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.

I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.


What about complex applications?

Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).

Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.

Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.


What about complex applications? Graphics (simple, but still) for games?

You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.

Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.

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.