Long ago, I was at a back-up event in Toronto where several folks brought their C64s and 1541s, much like your friend that was depicted in the video. Unfortunately, I was stuck using the only system with a single drive. Someone came looking for me as I was out-of-sight in a back room for hours, busy swapping disks over and over. "Here, Steve -- this will make things faster", said my fellow back-up colleague, who handed me an REU. H-O-L-Y K-A-O! What a difference that made! I was able to socialize with other folks at the even shortly thereafter :)
This takes me back to the very early 90's when my friends and I used to use a hex editors & similar utilities to modify game exe files to bypass copy protection. We would collectively buy a game and then crack it so those of us who had a PC could each have a copy. Lots of after school and weekend hacking sessions. Sometimes we spent more time trying to hack games than actually playing them! Those were the days!
Some games had much more insidious way of copy protection. They would not immediately kick you out when they detected pirated version. Instead, they would slowly make harder and harder so that it became unfinishable. One example would be Pirates! Cracking groups had difficulties with such games because they did not know where to make programmatic bypass of protection.
Cracked software is one of the main reasons we have access to so many programs that couldn't have have been copied due to elaborate transfer schemes. It's like those jokes about future anthropologists not knowing much about this period of time because of DRM and the fact their AI's cannot get past the "I am not a robot" schemes.
@@aleksazunjic9672 yup the Amiga game Leander was exactly the same but if it was copied it would just delete a single platform. That let you get 1/3 through the game and not be able to proceed. It also would seem like you just weren’t figuring out where to go
@@judgegroovyman Idea was probably to hook up a kid to a game, so he would then want to buy original release. If someone gets kicked out immediately because of piracy, he may just forget about it and move to a different game.
Bypassing copy protection is the reason I ended up learning 6502 assembly when I was 10 years old, led me into the cracking and demo scenes on the Amiga, and then started my current career in software and computer science. I do remember ordering fairly large ringbound books, with names something along the likes of "Software Compendium." These were enormously valuable to me at the time.
When developing Pi1541 I saw a lot of crazy code in the name of copy protection. Galaxian, published by Thunder Mountain was by far the most complex. It used VMAX4. The drive code used values from the timers and the shift register of the 6522s intermittently through out decrypting data. I suppose they did this so if anyone changed the code by a single cycle it would fail. It made it a good test case to get the 6522 emulation cycle exact. To get working I had to investigate how real hardware executed the code. I connected a Pi to the address and data buses of a 6502 inside a real 1541 using a real disk. I could then capture and analyse the entire bus activity of the game loading. This enabled me to see what data was going in and out of the VIA at a cycle exact time. From this I could infer what was occurring inside the VIA. I then made sure my emulated bus activity could produce the same activity of the real hardware for every single bus cycle. With the bus activity for both the real hardware and the emulator dumped to text files I could isolate sections and used “Beyond Compare” to see if there were any differences. I would love to meet the people who coded the loader and learn the story behind it. The game itself sucks but I was not going to release Pi1541 until it could load it. Another crazy one was Rescue On Fractalus. The drive code would deliberately execute the data (as code) placed at the end of the drive's ROM (including the IRQ/Reset vectors) and loop the program counter back into zero page. All the while it would keep executing BRKs and returning but it eventually ends up recovering and executing its correct loading code. But I had to laugh when I first saw it.
Great story Stephen. I spent a lot of time make a crack of Pirates! back in the day... made a working version but not elegant and definitely no fast loader like original. Recently I re-analysed the code and found SO MANY THINGS the copy protection was doing... surprised me the old '89 code ever worked :) In particular a 'perfect' copy of the game may (or not) work with VICE emulator using "true drive" emulation. It seems the emulation looses cycles/framing when lots of zero bits are present on a track. Fortunately the exact data isn't important, just that enough zeroes are present (but not too many) on a special track. One day I'll write an article... But I must object: Galaxian is a great arcade game! At least for the '80s. God knows I dropped multiple pocket-fulls of quarters into the arcade machines; as I recall the 64 version wasn't too far off.
@@H2Obsession Yes please write a book. Too many zeros in a row is never really explained very well. The way I understand it is that a flux transition is like a 3D gaussian curve. When moving from one transition going up and the other going down the distance between them dictates how many zeros between the ones can be inserted. But the more zeros inserted, the more the slope between the gaussian peeks becomes shallower and shallower. The more shallow it becomes the higher the auto gain amplifier ramps up. If there are too many zeros then the slope can become so shallow it almost becomes a constant straight line. Induction stops in the presence of a constant magnetic field, so this is bad. The next amplifier after the auto gain one is configured as a differentiator amplifier that differentiates the signal and detects zero crossings by detecting when the flux reverses (ie the slope at a true flux reversal at the top of the gaussian peek is flat). The derivative of a shallow sloping, almost constant signal can also be close to zero. So with the first amp with its auto gain maxed out and the second differentiating close to zero, any noise can easily cause a random incorrect zero crossing to be sent through to the one shot and be incorrectly detected as a one. Some copy protection did this on purpose. When implementing Pi1541 floppy drive emulator I had to introduce random flux reversals to emulate this side effect of the two op-amps used in real drives.
And here I was cracking code wheel protection using a sector editor back in the day (14 years old.) The brains people had to come up with this stuff was amazing to me. "Brains so heavy they had to prop their heads on stilts' I'd say when I was a teenager.
It's an experience that I had while growing up. Playing Bards Tale while listening to the faint hissing of the drive head passing over the magnetic surface.
I almost never could get any copies to work, until I got a super snapshot pro v5, the memory dumping feature however always worked. Such a fantastic little cartridge!
Line 153: protect those blocks from overwriting. Because those blocks not containing file data, it may be looks free in BAM. If DOS write a (new) file to a disk, searches free blocks in BAM (where can write the file), and if those blocks not marked as used, can try write the file here. Marking those blocks as used prevents this.
@@d2factotum In a legit, untouched disk, probably already marked as used. But if somebody run a VALIDATE command on the disk, that command repair the BAM, according to the file's used blocks, so track 2-3 blocks marked as unused in the process (because no file pointed to there). If the line 152 code not get the error code 65, that mean the block not marked as used and here the line 153 comes in to play. Some kind of copy protection repair.
Had I known back in the day that a RAM expansion could be used by a single-drive copy program, that would have totally gone on the birthday/Christmas wish list!
I still have my original copy of Maverick from BITD. But I was too cheap to buy the ram expansion. Honestly, at the time, Maverick was basically useless without the RAM (who knows if it would have worked with the RAM). Most of the best games had copy protection like V-MAX which a nibbler cannot defeat. IIRC, there were a bunch of disks that came with it that had cracking codes for specific games. Like if you wanted to copy Bubble Bobble, you needed the disk with the Bubble Bobble routine AND the ram (because it had the V-Max protection).
I still have my originals of Maverick 3-5 and Renegade, which was the predecessor to Maverick and my REU and I still use it a lot to this day, even though with disk images there really isn't a huge need. But I do find the Maverick sector editor is a great tool for checking you disks for errors after all these years. It also reveals information about the copy protection as it can detect most of the schemes used into the late 80s and early 90s.
I used to do this when I was a kid and you could rent games. I ended up with quite a collection! First try a fast copy; then a nibbler; next up was using the AR MK6 to pause a running program at the point of error, I would work out where in the code it was failing - so then I would directly edit the sector on the disk with my crack. Sometimes just reversing the check would work by replacing a BEQ with a BNE (so "work" if copied, or "fail" if legit), or I would just NOP the check out. The important part was not changing the length of the program with different sized instructions. This also worked with programs that asked you a question mid game (e.g. Bards Tale 3 and its code wheel). I did get GEOS copied too - from memory it had data XORed on disk as a sort of encryption. I worked out the crack in the running code, applied the encryption and found and edited that part on the disk.
@@DavidYoud Yes, I had since discovered that there may have been other issues in the software later on. Either I didn't encounter them or assumed the software was buggy. To be fair I didn't use GEOS all that much - I had just copied it from someone else (pretty sure it was a v2.0), and figured out how to get it booting.
I had versions of Maverick and Fast Hack’m as a pre-teen kid. A friend of the family let me copy 200 of his very many disks, mostly games. I remember they had copy busters too. My favorite program was the Sector Editor. One of my favorite accomplishments was fixing a mini-putt golf game. It would never go past the title screen. I noticed there weren’t many files in the directory- only the first sector of the directory (not including the header) had files- but the data sectors seemed to have data on them written in the standard save pattern (1, 10, 20, etc) past the existing files. One existing file had a list of filenames buried in it. I used that list of names and the save pattern order to rebuild the missing parts of the directory with the Sector Editor and viola! It worked! The game was playable. It was sometime in my early teens and I recall how happy I was. Good memories.
Thanks for the good C-64 memories. High level copy, low level (nibbler), cracking. I also remember using a "perimeter" disk that would fix the track sector from a high level copy.
For the B-A stuff @ 17:30 -- my own non-copy-protection-expert opinion is that the actual "protection" is provided by the error checks in 150 & 151, while lines 152 & 153 are simply trying to ensure (for whatever reason) that nothing messes with tracks 2 & 3 in their entirety. The VALIDATE command will defeat block allocations, so if line 152 doesn't return code 65, it can be assumed that the disk has been collected, and 153 will proceed to fully reallocate both tracks before running the program. -- JC
@@jeromewink557 I don't believe that simply marking a block as "allocated" could mess anything up. Its most common use is actually to prevent the DOS from overwriting blocks of the disk into which the programmer has directly written custom data that a program expects to find. The VALIDATE command will treat any allocated blocks that do not belong to a file in the Directory as improperly allocated and free them, hence why some software advises that you never validate specific diskettes. -- JC
An explanation of why the diamonds denoting errors didn't show up until well after the data was read: if you look closely, you will see that the read process makes 3 "passes" of the disk. A total of 3 disk swaps would be required if you were not using the REU. For each "pass", the program reads the data, checks for errors, and only reports the errors after the pass is complete. At that point, if you don't have an REU it will ask for the target disk and write out what it's read. If you do have the REU, it will transfer the data from the main memory to the REU and immediately start the next read pass. Likely, it is not possible to write REU memory directly; you must DMA from main memory to REU memory. This extra step takes time, and would increase the interleave factor required to read the disk optimally, so any writing to REU is delayed until after the main memory is full.
I was going to explain the exact same thing, it only reports after the first segment that would normally be copied without the REU, If you try the samething without the REU, you will notice it only shows the error diamonds after reading in the first pass of 12 or so tracks. A much better use of the REU is with the Burstnibbler1.9R+ that was modified for REU use. It does need a parallel burst nibbler cable, but it will read the entire disk with much more involved copy protections with sync checking and such,. And it can write many copies back! not that you might need more than one copy. There are two different versions on CSDB, they both support REU, but one will allow additional writes of the disk
Chilly night in Thunder Bay! Darn, I missed the spaghetti dinner. Maybe next time. I really enjoy your videos Robin. They take me back to a better time (yes, I am absolutely convinced it was better in the '80s). Thanks for doing this.
I remember as a kid I had a copier utility which did an exact sector-by-sector cooy of a 1541 disk. I could copy every game borrowed from my friends. As I remember, its filename was on my utility disc is "hack 'em all" or "back'em up all" and it looked like the MS DOS "defrag.exe" while cooying. It copied a full 1541 disc image with 3 disc swaps. It copied also the data of the unused sectors, and did a byte-by-byte BAM backup. So the finished copy had the exact protection scheme as the source disc.
Hi Robin, when you mentioned the protection noise on the previous video I was hoping you would do this. Great video. I'd like to see a c64 video where you hack a bit, ie circumnavigate some copyright protection and/or hack a game, such as infinite lives or turn off collision detection.
Problem with disabling collision protection is that if its in the same routine as picking up something the character walks over, that will get disabled too and you wont be able to complete the game anyway!!
Ooih memories, I used to use Fast Hackem, if you had 2 drives you could 'wedge' it into the RAM on a 1541 and then disconnect them from your C64 so they'd standalone and duplicate disks
I had several Electronic Arts programs that hammered my drive so badly that it caused me to have to realign it. They took several minutes to load and the drive got very hot. I finally got a copy program and copied them, stripping the protection off the disks in the process. They loaded smoothly from then on with no hammering of the drive head in just a few seconds. While I was at it I made some copies for friends of mine as well because by then I had very bad feelings for EA. I've hated that company ever since.
I have been waiting for this episode. Those tutorial videos you did are among my favourites, don't listen to RU-vid. Ninja star! The photo of Darren with the raised eyebrows was hilarious.
After watching your latest video I decided to see if I could get a copy of Maverick. Found and purchased a copy with all of the documentation intact and everything. Score!
The thing that I always thought was funny is that on the one hand you are legally entitled (at least in the United States) to make 5 copies of your programs, but on the other hand the manufacturers of those programs are NOT legally required to make that easy or even possible! I guess that's the compromise they reached at the time. The history of various copy protection schemes is like an arms race between the game distributors who don't want people getting their games for free, and the legitimate game purchasers who want a just-in-case backup and of course pirates who find it a challenge to defeat such schemes. I seem to remember that "Bruce Lee" was one game that hackers had a heck of a time cracking back in the day.
Nice, that's a really primitive protection, loved to see this. :) I used to spend hours upon hours hacking my original games back in the day, just for the fun/challenge of it. This is how I got into assembly language in the first place. It's not for everyone for sure. I like to see it as a puzzle box. If you enjoy programming, it can be very rewarding seeing some of the more clever protection schemes unfold! It can however be silly time consuming. :) I kind of lost interest in the 90s when encryption became more popular. That's just not as fun to me, and can be super tedious dealing with.
Personally I am strongly opposed to any form of copy protection. Not because I support piracy, but for backup reasons. I remember a long time ago I hacked my PSP and installed custom firmware so I could save copies of my games on to my PC.
A high school and college friend was known to have a collection of "backups" he was storing for his father, and I asked him how he came across them. Turned out his father worked down the road for a Commodore software dealer who would also rent out programs on floppy. If you were a first time customer, he'd throw in a copy/ nibbler program with a purchase of a box 100 blank floppies. His theory was if you liked a program, you'd buy a copy to keep the program authors employed so they make more programs. His copies would pay for themselves by being rented enough, and he also sold programs through mail order ads in magazines. When I finished junior college and got a real job, my interest changed to PC compatibles.
Wow. I was actually telling a friend about how I used to break copy protection to make my own copies. I didn't use Maverick and didn't even know it could use an REU! I used another program (QCopy?) which displayed all the tracks and sectors. Some copy protection needed individual sectors to be bad. Others needed the whole track. (The B-A is that I believe Bam Allocate which looks to be stepping through 39 sectors.) Anyway, EA especially liked to trick you and if you used a Nibbler you'd write data under the bad sectors however as the source track (pre-Nibbler) was actually blank, the errors would get passed eventually and there'd be garbage data, so it knew it was a copy. Thus the trick was to copy with Nibbler, erase just the track (or specific bad sector), then reapply the "error". Which as I recall was just shifting the head slightly off usually. Anyway VERY cool. I'll have to dig my old 64 stuff out now. And find the 2Meg REU. :)
I'm about halfway through and I gotta say; thanks again for getting down to the technical nitty-gritty of stuff I always wondered about as a c64 kid :) I've read about companies going so far as to temporarily run custom code inside the drive (like fastloaders do) to enable more advanced protections. Could you also dive into those? Kinda crazy how the 1541 had a faster cpu onboard than an entire region of c64's did, and almost nobody ever used it as a coprocessor to make more awesome games.. but it's possible and so much more
Copy Q was my go-to program back in the day. It was amazing. I used it for mostly legal copies but in some cases My friends and I made up weird grey area rules about piracy back in the day… at least one of use had to own the original game but everyone else was free to copy it as long as you didn’t share it to someone who wasn’t a “real friend”
Great video. I have the same I am the C64 bought new way back when. Mine is slightly different in that it has no write protect notches and after it checks the protection it works. But at some point, when loading the next chapter, the disk drive throws an error which is a write protect error. It's like it is trying to write something but fails because it can't. I remember checking this years ago and found the simple protection you outlined in this video. I also found the line that checks for write protect or something, but I don't remember. But now I will have to check it out. Thanks, and keep up the good work.
I managed to crack a game in the late 80s. I had to disassemble the first block or so of the bootstrap program to see what it was doing and I saw the part that checked for the error. So I studied what it was doing past that point, it loaded the game a block at a time instead of as a whole file, and went through some sort of decryption process. Can't remember exactly how, but I managed to get the decrypted game to a new disk with my own bootstrap loader without any need to add errors to the disk, and did it all without any special hardware or disk copy utilities.
I had a C128 and as it always started with the Z80 first I made a short Z80 assembler program that copied almost all of bank 0 to bank 1 when I pressed reset. Then I could examine bank 1 and find the copy protection code usually stored in memory the C64 deleted on reset like the keyboard buffer. :)
Coming from the TI99 world I was surprised to see there wasn't an in-house "Disk Manager" like TI had (indeed they had 3 versions in their short stint). Then poking around Super Snapshot 5 on the Maxi and I saw there is a disk / file management system built right into that .... you should do a video on that as it's quite useful, and to me, again coming from TI99 world, the only right way to go for such utility is cartridge all the way, so I'm glad to see that's there in cartridge form, even if it wasn't from Commodore themselves. (Incidentally if I'm missing something and there IS a disk manager cart from Commodore, let me know as I'd like to check that out).
In the uk where disk drives were very expensive we had mainly tapes. I had a device that was a shape of a T. It connected to the tape port and two datasettes would plug into the top of the T. You then pressed play on one datasette and record on the other - perfect copy no copy protection could stop it - also no copy software required
Huh, I didn't know they made grey 1541 drives with the radial handle locking mechanism. I only know the grey ones with the garage door, and newer white color drives with the radial handle. Wikipedia says Commodore switched styles in 1984, provided by Newtronics, so there must have been some overlap between the handle change and the color changes. Neat!
Great video! In case of assembly program you would need to figure out the test logic and hardcode correct result without spending more bytes. This copy protection was logically checking for invalid parity bits in those special sectors.
I had Maverick and I used to order all the parameter disks. Some of the protection schemes like V-Max required more memory to be installed in the drive. Protection schemes were pretty annoying, such as causing the head to rattle and cause problems later on. They would put a deliberate errors on the disk and have the program check for the error before continuing. Those were easily defeated by Maverick’s parameter disk. To copy disks with RapidLoc, you would need to place Maverick in nibble mode and will copy the disk.
I think that's the first time I've seen a 5¼" disk with write-protect notches AND index holes cut for both sides. In fact even the notches on the disks I have were all cut by myself as far as I recall.
Bringing back memories here. I have all kinds of my childhood commodore stuff and should dig it all back out. Some of my trick kit is an Indus GT (1541 replacement hot rod drive), Warp Speed Cartridge (Cinemaware) and all my Computer Mart software (parameters and copy stuff)..... I was a great little pirate. Cheers! 🏴☠️
"It actually _immediately_ knew that it was an illegal copy." Not actually illegal, though. So the app actually immediately _wrongly assumed_ that that was an "illegal copy."
I recently bought an “Atari mystery cart” on eBay that turned out to be a Commodore 64 cart full of disk nibbler utilities under a menu titled “*STARSHOOTERS* COPIERS.” It was one of those “Jason-Ranheim Company” CPR3 EPROM carts in a PCCH2 shell intended to be used with The Promenade C1 EPROM programmer. No doubt, these utilities were dumped and assembled using the J-R Company’s CAPTURE cart and software to make a save state after each was loaded into RAM the traditional way… after passing their own validations/protection checks. ;)
Who remembers Fast Hack'em with it's parameter disk? Capable of reproducing MANY copy protected titles, provided you have the required 'parameters' to duplicate the copy protection on the destination disk. These parameter disks were continually updated over time. Great program in it's day. A valuable tool when you wanted to 'archive your legally obtained software'. 😉
You got lucky. I recall reversing a C64 game that downloaded scrambled ML code into the 1541 memory, unscrambled it and ran it there to do the copy protection check (unformatted track or extra track, can't recall, it's been a while). A few scrambled NOP's later, voila! This was harder than hardware dongles 🙂
There are archiving disk drive controllers for the PC that will copy basically any format including single sided 8 inch drives and other non-standard formats. It's probably faster too and you end up with a soft-copy of the disk on your harddrive that can be written out should something happen to the copy and original.
Super Snapshot V5 users will know of the built-in fast disk/file copy tools, which are very handy to have on a cartridge ROM. You may also know that the cartridge RAM may be expanded to 32K, but it wasn't until recently that I noticed that the copy tools take advantage of the extra RAM to increase the copy buffer size. I don't think the full 32K is used though (in my experiments).
OK, so this is a very "BASIC" way to implement the protection, and we see that it's easy to beat. But that's why the smarter programmers have written that protection in assembly/ML; the average/"BASIC" Joe doesn't know how to beat it that easily. But then at the next level I guess there's an even more complex level of programming that would make even other ML-savvy people have a hard time beating it. That's why we see some say "Cracked by..." on them. Let's see you work on these also (an "easy" ML one and a tough ML one).
It's a cat and mouse game between developers and "hackers" (quoted because original hackers used to delve into such things, we no longer consider ourselves that anymore because the term has been stolen by those who couldn't program a toaster). There really isn't anything that a developer can do from the local standpoint that can protect anything, and it's not only hilarious but also sad because they waste so much money on the most complex creations and charge decent customers to pay for something that will be broken in a week. The way things are now, with alpha/beta early releases and "buy ahead of time," it just makes no sense...they get their money, and it has been proven that piracy doesn't harm a brand unless it sets out to be harmed by it (like Spore did). From a nonlocal, it's a different world entirely....not completely off the table, but still difficult. Even World of Warcraft was dismantled. Sure, you don't get all the frills from the updates immediately, but that's not the point. When you buy something, you should own it and be able to do with it what you want....we've grown to accustomed to renting everything.
Actually, it was relatively easy to "crack" even machine code protection in a few hours by skilled groups. Essentially, you would get Action Replay cartridge or something similar that could stop program execution at the moment when copy protection happens and then you could find piece of code that does copy protection and simply bypass it like in this video, only in assembly language. Problematic were insidious copy protection like in the game Pirates! where wrong answer would not kick you out of the game. Instead, it would continue but some flag would be set in such manner that game becomes much harder and after a while unplayable ;)
@@aleksazunjic9672 I liken protection like that to the FBI warning messages or annoying anti-pirate messages on BD disks. It is a motivator to pirate the content, since accidentally choosing the wrong year in Pirates would actually screw you over. A pirated version would have that check bypassed completely, so you don't even need to spend the time looking those things up. I would not be surprised at all if those kinds of protections actually increased piracy.
@@RandyFortier Well, problem was it was not easy to crack such protection. All it would would be XOR-ing your answer with some memory locations and doing some other mumbo-jumbo. And if you change the code to skip protection then the game would be still in hard mode. In fact, it looks like hard mode was default, and only proper answer would "unlock" the game. In any case, it took a while for cracking groups to do Pirates!, by that time game was already sold out.
@@aleksazunjic9672 haha, well at least I was able to return my copy. The beauty of that game was that they laid off the physical protections in favour of the softer password protections, which you could work on with a copy of the game.
This is very similar to the protection scheme used on Tiny Pascal for C64. When I bypassed it, I ended up writing a new BASIC loader program rather than modifying the original. Iirc, only the compiler was protected - the editor was freely copyable. Ever seen a copy of Tiny Pascal? Last I looked it up, it seemed to be a lost software..
Hi Robin. I noticed a 'funny' thing. When loading the copied disk, after the nybbler was used (at around 11:43 on the video) the screens turns quickly to "Illegal copy" but enters the program. The original disk didn't do that. Have you noticed that? Love your videos!
You reached around behind your Commodore and hit a button or a switch to access some sort of hardware interrupt -- what was that and where did you get it from?
There is a certain irony in that a simple programming teaching tool carried such an elaborate copy protection in spite of it being programmed in basic, Maybe they would have fared better if they had provided lessons on how to implement disk copy protection :)
1. i have heard that the buzzing of the drive is bad for the drive and you are supposed to turn off the computer when the disk does that.* 2. in addition to nibbling couldnt they copy down to the individual 1s and 0s that make up the data? while even slower it could furtherly duplicate more precise errors that may be used. *= since the buzzing was supposedly bad for the drive i am surprised that the system did that as a protection check. wouldnt a simple crc check be a better way?
1. An occasional clatter while loading a game isn't going to do much wear. I think doing a lot of alternate reading and writing on a disk with a lot of fragmented files, like a programmer would, would cause a lot more wear. 2. The errors were in extra bytes outside the main 256 bytes of data of a block and can't be directly read or written through ordinary means. You would have to write what's called a wedge program which you send to the disk drive's RAM to be able to place one of these errors on the disk, as the drive does not have a built in way to add errors.
They went to the effort to do something with the formatting of the disk but appear to have taken no effort to protect the part of the program that does the copyright check. I can think of five things that could have been done that would have been fairly simple to do to make it harder to bypass the protection system. 1. Move the few lines of code to near the end of the program. 2. Encode the ILLEGAL COPY string to make it harder to spot. 3. Have the program poke some assembly code in to memory and call it to do the protection. 4. Load the assembly code to do the drive check from some fixed sector of the hard drive. 5. Have the assembly program modify the BASIC interpreters variables to alter the return address so the return wouldn't be to some other part of the BASIC program and not the next line after the call to the assembly language routine.
Even with a nibbler, some disks just won't copy successfully. I think the first time I struck this was with _Beach Head II_ . I just couldn't copy it at all with what I had. It wasn't until I managed to get an (illegal) copy of Fast Hack 'Em with a parameter disk that I could make a copy. The Parameter disks became more and more necessary as time went on, with "parameters" tailored for each program that you wanted to copy. They were regularly updated. Of course, the very best way to make a copy was to get a cartridge like Isepic and freeze the game once it was in memory and then save it.
Not sure if thats what its doing, BUT that extra bit of code might be a routine to overwrite a complete block or track, to make debugging a pirate copy impossible as it destroys that part of the disk, or if using a memory image RAM expansion, destroys the original disk that youre copying from. I wonder if you could use a disk image program on an IBM-PC in what is called 'slow' mode where it copies everything low-level including 'errors' and the formatting too. If memory serves correct, a program called 'Pharr-Lapps Ghost' by Binary Reasearch could do that.
Thanks again for another great and informative video. I really appreciate it. I have always (well, since it came out) wanted to hear someone talk about the code behind "Edge of disgrace" by Booze Design. It always blows me away. Would it be possible to do a video breaking down the effects and the code behind the demo? Or is that outside your game-scope, perhaps?
I cracked a program once. I was playing a game using my 128 and 1541. Then I bought a 1571 and the game would not load on it. It was ML, so I used a sector editor to find the protection code. It turned out that commodore changed the error code! Why!!! I just edited it to jump over the protection code and was able to play the game using my 1571. There were some protection schemes that used physical damage to the diskette as part of the protection and could not be copied at all unless you disabled the protection in xoftware.
I fixed a lot of (seemingly broken) games using amiga's xcopy nibble function (until it works). Good to know what it actually does on a deeper level (asuming it works the same).
I remember using Fast Hack'em and I also had Di-Sector or well something like that anyway. I have never seen a disk with 2 index holes but I guess it was a true double sided disk.
Commercial floppy disk duplicators could write any bit pattern they wanted to a disk, it is only an error by the standards of a Commodore disk drive's firmware. The tracks with errors do not contain any program data so loading is unaffected. The mysterious code on line 153 reinforces this by ensuring the drive will never write to those tracks because they are marked used in the disk's Block Allocation Map.
These are just soft errors in checksums. They would have had the master disk, read it into the mass copying machine and change those bits there in memory.
9:30 RAMBOard? I wonder how frequently 'RAMBO' got used in the names of aftermarket RAM expansions of the time... My family had a MacXL (The Lisa with a 3.5" floppy and an HDD, running the Mac system software) and I remember my dad had schematics for a RAM expansion called 'LisaRAMBO'
I had owned an Atari 800 where most programs that would use copy protection would be written in machine code. I would disassemble the beginning of them where the copy check would be done, NOP out the section that would check the disk, possibly add a jmp instruction. Most of the time that worked. But I came across one program where what was read from a few sectors wouldn't be the same, seeming to result in two possible machine code segments. I never could figure out that one to get around the check and just jump into the actual program.
I've heard of that: some copy protections deliberately put floating bits onto specific sectors, if those didn't read back as random (due to floating between 1 and 0) then it had to be a copy.
Back in the nineties I had to make a copy of a disk that had five licenses of a program. It said so when you installed the first copy. After that it had four copies. I could not copy the disk with a normal copy program for it had five bad sectors on it. After the first install it had four bad sectors and the HDD had one. After deinstalling the program from the HDD there were no bad sectors in the HDD and again five on the floppy. Since it was a company setting I did not go further into it. I still wonder if I could have made it work.
That’s funny people would think stacking disks like that would erase them. If formatting or writing to one side of the disk can’t affect the data on the other side of the disk through the very thin plastic sheet, the distance separating the disks through their sheaths or envelopes sure isn’t going to put them at risk of erasing each other.
That brings back memories but I did not use maverick but something else in the UK. Also hiding text in basic programs by adding screen commands into the basic code
The Disk Drive Unit was more of a computer than simply a disk drive (it returned a BASIC listing to describe the contents of the disk). I wonder why not using a cartridge connected to the back of the C64 (amd the disk drive connected to it), with a ROM adding load, save and so on instead.
I wonder if methods like this (or more accurately, its ML counterpart) were still effective at keeping the programs from being spread over the proto-Internet, and that's the real reason the cracking scene was so big. Like, was there a way to upload and download entire bit-perfect disk images similar to the D64 images we have today, or were they limited to PRG files?
Everything was cracked. Some people use parameter-based copy programs to keep a collection of copies of originals, but that was eclipsed by people trading in cracked scene-releases. I've never heard of anything like d64 dating back to the 80's.
Weirdest yet simple C64 copy protection I've seen was a Mastertronic game that had Atari on the same side. You had to have the tracks that the Atari tracks were located on blank. The Atari copy had to have C64 tracks as well. Only coping the tracks for each computer allowed for backups.
Haha, in comparing 1541, 71, and 81, FFR I think you should have emphasized the *"81"* instead of the "15," because I was like, "Uh, they all start with '15'."
