Paulie’s Perfunctory Game Dev Website

Video Game Development Since 1981

Freeload - a potted history Well, here's my little shrine to a wee bit of software I originally wrote in the early eighties. I'm totally flabbergasted by people's fascination with what has become known as "The Ocean Loader". 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). Alongside the music, who could forget the incredible loading screens of Stephen Thomson, Martin McDonald, Simon Butler and Steve Wahid. 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.) For the curious, or just plain geeky (a category in which I include myself), I present to you a potted history of this wacky "bit of code". 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... Back in the early eighties, I was friendly with Steve Turner and Andy Braybrook from Graftgold (authors of the superb Uridum, Paradroid, and 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 set up 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 Alleykat - 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. 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. 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... Freeload started with keeping the screen on and flashing the border as each new bit streamed in (I wanted it to look like a Spectrum loader!), then a countdown timer, then I introduced loading music, animations and smooth scrolling finally culminating in playing mini games during the load. In 1985 I programmed simple versions of Breakout, Space Invaders, Centipede and Asteroids to pass the time whilst the games loaded! Alas, for Ocean this was a non-starter; by now we were known as the company that bucked the trend and officially licensed intellectual properties, so having a knock off version of Centipede on, say, an officially licensed Konami title wasn’t deemed particularly ethical. We even mulled the idea of licensing these mini-games, but the return on investment would have been either non-existent or loss making. Note: Just to clear up a common misconception; the aforementioned Freeload games are not to be confused with Ivade-a-Load by Richard Aplin at around the same time for Interceptor/Players titles - (I imagine the licensing issues were less of a problem for them). All said and done, Richard was the first person to ship a titles with a load-a-game - props to him. Slow Down! Hit Loading! 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 reliably 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 less expensive 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! “Behind the Scenes” - for the nostalgic and / or curious 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! Protecting against Tape to Tape copying 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 the 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, as they helped fuel 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. Making Game Compilations Some of the really big sellers in the nineties were the compilation boxes that Ocean used to sell. Little did people know what an absolute nightmare they were to put together! When the compilation contained purely Ocean titles the cassette versions weren't an issue as I had more than likely mastered the game myself. When it came to disk versions and compilations with third party titles on, well, that's when the fun began. Disk versions were the catalyst to my thirty year data compression obsession; With disk versions the fewer disks you crammed the compilation on, the more profit Ocean made due to a lower cost of goods (COGs). 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! Irony; Pirating the anti-Piracy! I did an interview with a Retro gaming magazine about a decade 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 after work I can assure you) 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 some of the now released master makers, and lo-and-behold it transpires that hundreds of games did indeed use Freeload’s code; 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 it bothers me - its actually quite a compliment, I suppose, that the system worked well enough for people to either reverse engineer it or acquire the source code via nefarious means! Roll up, roll up, get your Source Code here… A few months ago the very lovely and very talented Vanja Utne of Pond Software, a little company still creating packaged C64 games, asked if they could use Freeload for the cassette release of their new game “The Bear Essentials”. As I’d released the source code to Freeload into the public domain many years ago, I was more than happy to see it still used; I have a copy of the game now, and it looks awesome (with ace loading music by Vanja too!) As I wrote Freeload several years prior to Ocean I still retained the copyright to the code; I managed to find and convert a bunch of old 'C64 source disks, and so you can find the 6502 assembler source code for Freeload, Freesave Mastering System, and the Freeload Multiload routines on my DOWNLOADS page for your delectation. Enjoy!