People have such fond memories of it (granted its mainly to do with the awesome loading music that the likes of Martin Galway, Peter Clarke and Jonathan Dunn wrote over the years).
I'm asked more questions, and have been interviewed more times about Freeload in the last couple of years than any of my C64 games (which actually isn't a bad thing, I can assure you.)
Over the years its come to be known as "The Ocean Loader" - however that is a bit of a misnomer, as although it was mainly seen on more or less every Ocean, Imagine and Hit Squad title from 1988 onwards, it didn't actually start life at Ocean.
I wrote the first version of what would become the Freeload Mastering System in 1985 after tearing my hair out waiting for code to load off tape, or even worse waiting for a game to slowly trudge into the C64's memory. Back in 1985 a game for the 64 could take anything up to 30 minutes to load with nothing but a completely blank screen to stare at. At the end of the load, the screen would switch back on... and... in many cases the C64 would just reset! Aaaarrrgh!
I wasn't by any means the first person to write a "turbo loader", I remember the day I first saw one, I was stood in a local computer shop when the assistant popped Jeff Minter's "Revenge of the Mutant Camels" into the cassette deck. About five minutes later up pops the game! Turns out that Jeff had licensed a new fangled fast loader from a German company called Kingsoft.
I've gotta do one of these! To cut a long story short, I took a look at the ROM load and save routines and was just flabbergasted at just how poor they were; No wonder loading was slow; it effectively stored more than four times the data it needed to! Every byte stored required 20 pulses (two for each bit sent, plus a couple of parity bits and a couple of bits to mark that this byte was the last byte (!). This data was then stored again to verify to load!
I took a different approach to the IO timings; everything in Freeload was done with Non-Maskable Interrupts, which meant that the timings could be really tight so I could seriously shorten the pulse lengths and more importantly I could free up the main processing loop to do other things whilst the load was going on in the background.
The first, somewhat ropey, incarnation was called "Surelock", at first, wanting to be the fastest Turbo, it loaded at around 4000 baud (which I'd quickly discover was a bit too much for the best high-speed duplicators to reliably fire off the conveyor belt), and it had a couple of interesting features...
"Cor! Raster splits, music and smooth scrolling during loading!"
Back in the early eighties, I was friendly with Steve Turner and Andy Braybrook from Graftgold (authors of the superb Uridum, Paradroid, Gribbly's Day Out to name but a few). We'd been discussing ways of stopping the new fangled "freeze" cartridges that could take a snapshot of the game once it had started and save it out to disk for later (and, heaven forbid, to allow people to copy the games!). I'd come up with a cunning ruse to stop the likes of Isepic and Freeze Frame from stopping the game post Freeload.
(For the curious, at the end of the load the system setup a non-maskable timer interrupt with a very short countdown. When the interrupt went off and jumped to the interrupt manager it "forgot" to acknowledge the interrupt had happened. When the punter pressed his "Freeze" button the cartridge generated a new interrupt, which unfortunately wouldn't do anything because there was already an interrupt blocking the queue).
The first version of a "tuned" Freeload went on Uridium - it didn't do anything too fancy - but it loaded fast, could keep the screen on during the load, and was a pain in the ass to copy both tape-to-tape (more on this novel solution later) and to disk.
Another of Stephen "SIT" Thompson's incredible loading screens.
Having put a few versions of Freeload out, tweaking it and improving both its protection and reliability along the way, I joined the in house development team at Ocean in Manchester.
A couple of months after I joined a really smart programmer called Bill Barna that did all the tape protection left, and Ocean were left with a chunk of very cryptic undocumented code, which no one really understood, and a whole bunch of games to put out.
Thanks to Martin Galway (thanks Mart!) who mentioned to Gary Bracey (Ocean's supremo Software Manager) that I'd done "a few loaders, and a bit of tape protection" I ended up being roped into every tape, disk, and compilation that came out of the Ocean doors for the next five years (and the systems continued to be used after I left).
If you need to know why there were so many Ocean loading tunes, its simple; its because I did the mastering for so many Ocean / Imagine games that the music drove me nuts! Luckily, for my sanity, Jon Dunn was very accommodating with the new tunes.
Rastan and Slapfight featured little sprite animations (note the twinkly star on the Rastan logo) during the load.
Rastan screen by Martin McDonald.
As the months went by I tweaked Freeload, constantly battling the hackers to change methods and obfuscate the data just long enough for the games to sell some units before they got cracked, which of course, they all did.
Over time, the load times improved, the mastering software became fully automated, the multi-load routines had proper cyclic redundancy checking to minimise duff loads, and the loader itself started finding things to do during the load...
It started with keeping the screen on and flashing the border as each new bit streamed in, then a countdown timer, then I introduced loading music, animations and smooth scrolling finally culminating in playing mini games during the load - I did versions of Breakout, Space Invaders and Asteroids to pass the time whilst the games loaded! (Note: Not to be confused with Ivade-a-Load by Richard Aplin at around the same time for Interceptor/Players)
Target Renegade loading screen by Martin McDonald.
In the early nineties budget games were getting big, and seeing as Ocean / Imagine had a HUGE back catalogue they introduced a new label - "The Hit Squad" which featured re-releases of classic Ocean games, and over time including other companies' back titles too.
These games retailed at £3.99 and so the price had to be kept down; the packaging changed to the old fashion, simple single cassette plastic box and we changed duplicators for the budget titles to further reduce the price. One problem. The new duplicator couldn't reliable duplicate Freeload. I'm not entirely sure why not, but it had something to do with Freeload's short pulse widths when duplicated at high speed on cheap duplicating equipment caused very dodgy yields.
And thus, Hit Load was born. A significantly slowed down version of Freeload so that the tapes could be duplicated. However there was one practical upshot of this; as the load now took longer, the Ocean loading music ran out way before the load had finished, so I had to get Jon Dunn to write a new piece of music that lasted a minute longer!
Tedious info, only for the seriously interested / curious / nostalgic / nerdy
Over the years the outer layers of Freeload changed with new protection schemes, new sneaky methods of detecting Freeze cartridges, and new encryption and compression techniques, but, fundamentally the core save and load routines stayed the same.
All Freeload titles load in 14 parts (excluding the initial boot load that pulls in the loader) at roughly 3000 baud (which is x10 faster than the original Commodore routines).
At three points during the loading sequence Freeload loaded the "Free-Loop" control software - once to actually kick things off, loading the music and scrolling the boot messages, and twice more during parts of the load (over the top of itself) to counter any changes that a hacker may have made to the initial loading software.
Some Freeload titles didn't actually "jump" into the game code at the end, the loader actually loaded the start address directly into the stack, fudged the stack pointer and just executed a RTS to start the game.
Once Martin Galway left Ocean I wrote a new music driver for Jon and Matt with a more compact data format and faster playback. All of the loading music (including the driver code) post Hyper Sports was just a fraction over 4K bytes.
Nearing the end of the C64's tape life, Freeload started doing some crazy stuff under the hood to deter the hackers; The freeload code and the incoming data was encrypted. The protection code would decrypt multiple times over the top of itself and the executing code would "fall in" to the newly decoded sections. At one point the decryption key was based on how long certain parts of the loader took to execute - if you changed any of the loader it would mess the timings and thus scramble up the incoming data.
In the end, all protection gets cracked - its fundamental - anyone that says their system is un-hackable quite frankly has a screw loose!
Stopping Tape to Tape duplication...
So, back in the eighties, the cheap "all-in-one" music centres were all the rage; You got a turntable, an AM/FM radio, storage for your Vinyl record collection, and twin cassette players (generally with a "high-speed dub" button for fast copying of cassette tapes). This made duplication of cassette based software even easier - no hooking up two recorders together via the EAR and MIC sockets and finding the correct levels, just push a button and you're done.
Not unsurprisingly the publishers didn't like these contraptions, they helped the epidemic of "school yard piracy".
I came up with a rather novel solution to thwart a good cross section of these dubbing systems; the first part of the puzzle was somewhat serendipitous; having spent many long months figuring out the ideal pulse timings for duplicating Freeload, I came up with the ideal baud rate that could just be duplicated correctly by professional duplicators, however the cheaper high-speed dubbing tended to "stretch" the timings and the overall tone causing load errors. So that kind of took care of the cheap-o high speed copying, but what about the regular dual deck tape-to-tape dubbing?
Now, this I was quite proud of; reading up in electronics magazines on how these twin cassette decks worked I discovered that a good chunk of the cheaper (sub £1000) all in one units had a really simple ALC circuit (auto level control) under the hood that fiddled with the audio gain to get the best level for "dubbing".
So, what I came up with was a system that between data chunks on the cassettes I recorded several long, shrill tones of various lengths that were ignored by the loader, but the ALC circuits would kick in and pull back the gain during the copying process to get a better audio balance (they were of course designed for duplicating audio cassettes and so getting an even audio level was its goal). The upshot of this, however, was that the following sections of actual tape pulses would then be recorded at a much lower volume, in many cases causing the loader to miss the signal and cause loading errors.
By all reports this gambit worked rather well, though it didn't stop the soon to arrive "Freeze" cartridges which dealt with "backing up" in a different way.
Disk versions were the catalyst to my data compression fascination; With disk versions the fewer disks you crammed the compilation on, the more profit Ocean made, so it was always an "interesting" challenge to find newer and unique ways to compact the games down. I had many long nights trying to save a disk here and there to maximise revenue.
The really tricky stuff however were the third party games; nine times out of ten I wouldn't get raw data, or code, or even a master maker, I would just get a tape copy of the game. In order to get it on the compilations I'd have to first break the original copy protection (with the third party's blessing obviously!), and, in the case of a multiload title, patch in my own Freeload routines, and finally put the Freeload protection on the main load.
Let me tell you, there were a lot of very clever protection systems back then!
Freeload? For other companies?
I did an interview with a Retro gaming magazine a few years ago and they were asking about all the other companies that used Freeload for their 'C64 games. I looked on blankly - huh? Once I joined Ocean I only ever wrote protection code for them (I didn't have the life force left to do EVEN more tape loaders) whaddya mean?
So, I go looking at the .TAP archives (actual images of C64 tapes loading for the emulators) and see hundreds of supposed Freeload based titles. No, says Paulie, they're just confusing the pulse widths with some other loader from the day.
To cut a VERY long story short I got curious and started disassembling a couple of the game loaders, and lo-and-behold hundreds of games did indeed use Freeload that were line for line, byte for byte identical.
So it looks like industrial piracy was rife even back in the 80's and 90's. Not that I'm bitter - its actually quite a compliment I suppose that the system worked well enough for people to reverse engineer it and reuse it.
Freeload in the Public Domain
About eighteen months ago someone that was still creating C64 games asked if I still had the source code as he'd love to see how it worked, and could potentially use it on his own titles.
As I wrote Freeload before I joined Ocean and held the copyright on it I decided to stick it out in the public domain for nostalgia's sake.
I managed to find and convert a bunch of old 'C64 disks, and so you can find the 6502 source code for Freeload, Freesave and Freeload Multiload on my DOWNLOADS page.