Robocop - Chart longevity vs piracy

General software. From trouble with the Banyan Tree to OCP Art Studio, post any general software chat here. Could include game challenges...
Post Reply
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2641
Joined: Mon Nov 13, 2017 3:16 pm

Re: Robocop - Chart longevity vs piracy

Post by Ast A. Moore »

ZXDunny wrote: Wed Jul 04, 2018 2:31 pm I thought that stuff like Speedlock et al were just ways of loading faster. Bleepload was obviously there to help against loading errors.
Well, yes and no. The primary goal of Speedlock, Alkatraz, and the like, was data protection, rather than copy protection. They used sophisticated multilayered encryption schemes and unusual loaders to prevent other people from looking into the code. Obviously, that was rendered mostly moot by devices such as the Multiface, which dumped the RAM contents after it’d been decrypted. For a casual hacker, however, loading chunks of game code from tape was impossible without reverse-engineering the decryption scheme.

Granted, early versions of Speedlock didn’t use encryption, but modified the standard loading scheme to, say, skip the flag byte, but that quickly changed.

The loaders themselves thus became quite bloated (sometimes they weighed in at 6K or more!), so, perhaps to compensate for that, loading speeds were increased.

Note, that higher loading speeds required a better tape recording setup. While original tapes that came from duplicating plants were almost guaranteed to load on low-end off-the-shelf tape players, their copies (even first-generation copies) were not. That worked as an additional deterrent.

The various tape copiers, which relied on loading game data in chunks into the computer’s RAM and then saving it onto tape—thus creating the highest quality copy—couldn’t deal with most complex protection schemes. Some games used an even simpler trick. They created a standard–speed, non-encrypted but very large single data blocks—over 48K in length. Most of the data there was just junk needed for padding. Since a tape copier would need some room for its own code, it would not be able to load a block that exceeded the size of the remaining free area RAM.

Bleepload’s idea of using the flag byte and loading data in small chunks is hardly a conscious effort to help with loading errors. Each chunk is also encrypted. After each chunk loads, it is decrypted and moved into place.

But yes, some loaders were more forgiving of tape loading errors and user intervention than others. (Some would just reset the machine if they didn’t like something—a terrible user experience decision.) Others—like Bleepload—allowed you to rewind the tape and reload individual blocks.

TL;DR: Fancy loaders were designed to protect IP, rather than to prevent piracy.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: Robocop - Chart longevity vs piracy

Post by ZXDunny »

y'know, it's almost as if I never actually wrote an emulator sometimes. But thanks for the explanation anyway! :)
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Robocop - Chart longevity vs piracy

Post by Joefish »

Not sure how that response was meant, but anyway, I didn't know all that above.

I always thought, when I read about the layers of encryption and packing when Fairlight loads, what a waste of time it all was. I guess with compression there are advantages to the load times, but what's the point of encryption? It could always be circumvented as there was no way of hiding your decryption code or algorithm, and as has been pointed out, hardware add-ons made inspecting running code easy enough for anyone who was desperate.

I just assumed most of the alternate loaders were there to hasten the deterioration in quality of making tape-to-tape copies. I certainly never saw anyone trying to copy a game with a load / save system. Though I suppose if you were an industrial-level pirate making bulk copies that might be your preferred method, to keep the quality up.

As for Robocop, don't forget the cachet associated with having anything to do with a film that most kids would have been too young to actually have seen. That immediately gives it appeal; in fact, Ghostbusters was rated 15. Just look at the fuss over kids who want to play GTA (and the moron parents that let them, ad the other idiots - including many prominent MPs - who call for a change in the law over something that's already illegal).
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2641
Joined: Mon Nov 13, 2017 3:16 pm

Re: Robocop - Chart longevity vs piracy

Post by Ast A. Moore »

ZXDunny wrote: Wed Jul 04, 2018 6:27 pm y'know, it's almost as if I never actually wrote an emulator sometimes. But thanks for the explanation anyway! :)
We aim to please. :D
Joefish wrote: Wed Jul 04, 2018 6:52 pm I always thought, when I read about the layers of encryption and packing when Fairlight loads, what a waste of time it all was. I guess with compression there are advantages to the load times, but what's the point of encryption? It could always be circumvented as there was no way of hiding your decryption code or algorithm, and as has been pointed out, hardware add-ons made inspecting running code easy enough for anyone who was desperate.
Sure, if you have a Multiface, it’s a piece of cake. If not, however, just the sheer amount of time spent reverse engineering something like Alkatraz, for instance, will put many people off. I have to admit, some custom loaders used batshit crazy encryption, XORing and ANDing data, “on-the-fly” changes of data loading address so it jumped from one place to another without an apparent (audible) break in a block, etc. Even with modern monitors/debuggers I gave up on quite a few of them. Now, couple that with task of creating the actual masters for duplication (i.e encrypting data and writing a “saver”) . . . an extraordinary amount of effort. Granted, Alkatraz has the best loading screen animation.
Joefish wrote: Wed Jul 04, 2018 6:52 pm I just assumed most of the alternate loaders were there to hasten the deterioration in quality of making tape-to-tape copies.
That would have been easily achieved with 3x and faster loading schemes with no encryption. (I believe the fastest commercial tape loader peaked at somewhere around 2.5x speed of the ROM loader.) Still, that bumped the upper frequencies to just over 6 kHz, and not all low-end tape recorders could pull that off. The irony is that the Spectrum is quite capable of loading speeds of 10x of the standard ROM loader via the regular EAR port given a high-quality audio signal—almost comparable to some disk-based systems. The problem was that back in the 80s, that would have required the expensive Type IV tapes and high-end tape decks (or 15 ips+ reel-to-reel recorders) for playback. The price of tapes would have skyrocketed and the numbers of users capable of loading them without errors would have been very, very low. ;)

That said, there were quite a few custom loaders that didn’t do anything crazy (well, almost) in terms of data obfuscation and merely sped things up a tad.

P.S. Nether Earth is a good example of the kind of “copy protection” meant to fool the load/save types of tape copiers and some inexperienced hackers. The BASIC loader contains a few hundred bytes of useless garbage. It then loads a simple machine code loader, which differs from the standard ROM loader in that it adds rainbow border colors. It then loads a single 48KB block of data starting at address $4000. About 20KB (20KB, Carl!) is pure garbage: either repeated bits of data or contiguous strings of zeroes. I cleaned up the BASIC loader, incorporated the machine code loader into it, and got rid of all the garbage in the main data block. As a result, I cut down the loading time from the original 4:28 to 2:52.

Crazy times they were, the 1980s. :lol:
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
AndyC
Dynamite Dan
Posts: 1405
Joined: Mon Nov 13, 2017 5:12 am

Re: Robocop - Chart longevity vs piracy

Post by AndyC »

Joefish wrote: Wed Jul 04, 2018 6:52 pm As for Robocop, don't forget the cachet associated with having anything to do with a film that most kids would have been too young to actually have seen. That immediately gives it appeal; in fact, Ghostbusters was rated 15.
Ghostbusters was rated PG (BBFC) in the UK. Though the wider point about the appeal of things with more taboo ratings is certainly true.
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Robocop - Chart longevity vs piracy

Post by Joefish »

Was it? I never got to go to the cinema as a kid. Maybe it was Gremlins I was thinking of as being a 15.
AndyC
Dynamite Dan
Posts: 1405
Joined: Mon Nov 13, 2017 5:12 am

Re: Robocop - Chart longevity vs piracy

Post by AndyC »

Yup, Gremlins did indeed get a 15 (BBFC) as another one of those films which fell into the controversial bubble somewhere between a PG and 15 rating, with another notable one being Temple of Doom which got a PG (BBFC) in the UK after some cuts (and which lead to the creation of PG-13 in the US as they had nothing between PG and R-rated, which is roughly equivalent to a UK18). Eventually that all lead to the creation of a 12 cert, with Batman being the first film rated that way and yet another classic Ocean licence.
Post Reply