Back in the day, I owned a Commodore 64, and I noticed that essentially all games on tape, provided their own code for reading the tape, instead of using the code provided in ROM. This had two benefits from the vendors' perspective: copy protection, and the ability to load many times faster than the ROM code would've done.

As far as I know, running I/O at a fraction of its potential speed was a Commodore-specific quirk, which means on other platforms, custom code would not have been necessary for that reason. I'm curious whether copy protection alone sufficed to motivate custom loader code. so to take a specific contemporary platform with many similarities:

Did games on tape on the BBC Micro and Electron, have custom loader code?

1 Answer 1


Only very rarely because the tape hardware is completely distinct between the two machines, it’s very lightly documented and somewhat peculiar on the Electron, is fairly fixed in its functionality, the built-in routines are pretty good (including rewind and retry), and using the standard routines gives you a trivial pathway to adapting your title to ROM or to disk.

Re: hardware differences; the BBC offers a ULA that signals decoded bits to a standard ACIA (i.e. a one-slot UART) for byte accumulation. The Electron does the whole process in its ULA, making no effort to emulate the ACIA.

Re: the Electron; interrupts are offered for received data full, transmit data empty, and high tone detect but most people tend to assume that the first two are labelled the wrong way around as documented, though the truth is that all three are simply always active; if you are writing bytes, the received data interrupt will still fire if enabled, provided it hasn’t fired recently and what looks like a start and stop but pair shift through.

In both cases, because bit recognition occurs in hardware, there’s no leeway for the usual approaches to turbo loading. On an Electron you can’t even discard start and stop bit requirements — the byte packaging is hard-wired.

Acorn also did a great job abstracting filing systems so if you stick within usual load and save calls then the door is usually open to disk, ROMFS, etc releases for free. The only caveat is that some disk filing systems reduce available RAM slightly.

That all being said, an occasional title has a custom loader. Off the top of my head: Way of the Exploding Fist is an Electron example, which omits the usual 256-byte chunk structure for a single block of data and either loads the whole thing successfully or doesn’t.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .