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.
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!
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.
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.
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
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.
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
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!!
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.
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 have been waiting for this episode. Those tutorial videos you did are among my favourites, don't listen to UA-cam. Ninja star! The photo of Darren with the raised eyebrows was hilarious.
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.
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.
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. :)
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!
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.
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
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 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.
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.
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
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.
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
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.
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”
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.
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.
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).
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! 🏴☠️
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 🙂
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'. 😉
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..
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!
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).
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.
"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 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).
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.
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.
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.
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
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'
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?
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 :)
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.
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.
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?
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.
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.
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.
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'."
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.
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.
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.
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.
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 :)
You really should've put "GREETZ" before the list of Patrons on an episode like this. :)
"Greetz to the elites!" ;)
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.
@@IcyTorment LOL
@@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.
The ancient ones were clever. I
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.
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!
The sound of the 1541 drive chugging along is so relaxing to me, almost like rain on a window. Yeah I know, I'm weird.
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'm the opposite, since I know what the sound actually means and its painful to hear.
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.
Surely that should already have been done if it was a legit copy of the disk, though?
@@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.
I didn’t know you could nibble copy only the parts needed. I thought you always had to copy it all! For decades I did it that way! Lol!! BLAST!!!!
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.
Yeah Right?
Many memories of packing a spare drive back and forth to my fiends house on my bike... I had modified one of mine to switch between 8 & 9.
I would have loved a second disk drive myself.
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.
There was some fun stuff in GEOS, ask google for "Copy Protection Traps in GEOS by Michael Steil"
@@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.
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.
6:26 For a moment i though somebody was calling me...
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
Is it maybe trying to mess up your bad copy worse by trashing it more?
@@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
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.
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
Fast Hack'em from Mike J. Henry was the pirate bomb. Loved that program.
@@Trenchbroom On side 2 of my Face Hack'em I had Mr. Nybble.
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!!
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.
That sounds like Fast Hack’em
@@juliavixen176 It could be...
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.
DOOD! I used to live near the KAO plant in Fremont, CA until it was offshored in the 90's. And yes "Kaow" is the correct pronunciation.
Robin, you know quite a bit about copy protection schemes on the Commodore 64 please make more videos about it!
I have been waiting for this episode. Those tutorial videos you did are among my favourites, don't listen to UA-cam. Ninja star!
The photo of Darren with the raised eyebrows was hilarious.
Liked that song at the end - I recognized it was about phone phreaking.
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.
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.
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. :)
Nice!
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!
Man, this brought back some memories. Maverick was my go-to copy program. Best investment I ever made for my C64, next to my Final Cartridge III.
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.
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
I had forgotten about the idea of checking into the copy protection. Those other two vids on "I am the C-64" were some of my favs, so, thank you!
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. :)
X-Copy?
I remember the Maverick program, most of our C64 software were copies made with that software. Including our copy of Maverick.
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.
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.
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
KAO = cow. You are correct. I had a KAO rep tell me the correct pronunciation when I worked at a computer store back in high school in the late 80s.
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.
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
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.
Great video - I need to share this on my "C64 Copy Protection Blog" - Please make a few more of these.
What a coincidence. I watched the I am the C64 videos a couple days ago. Wondered if I had just missed the promised copy protection. Glad to catch it.
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”
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.
Computer Mart had a piece of software called Bull's Eye that speicifcally copied RapidLoc. I still have mine!
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.
9:41 OMG I used to buy so much from SSI for my C-128 and later for my Amiga 500. I used to love getting those catalogs in the mail.
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).
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! 🏴☠️
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 🙂
I'd love to know the title of that software. I'm an old pirate too.
I love every clip of yours . Truly appreciate the detail and always look forward to the next one
I've been hoping for a video from you about copy protections. So this was great, thanks!
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. ;)
Apparently I follow you here already. And not just on TikTok
god I miss those early computer days
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'. 😉
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..
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!
I always thought the D64 format that so many emulators use should include the block metadata so disk errors could be emulated.
I believe that’s what the G64 format is for.
Recently i read that D64 even does not store the disk ID. There are some multi disk games which check for these...
Great video. I have used many commodores back in the day. I do have a question how are you showing the video from the commodore in the video .
We used a program called Copy-Q for floppies back in the day.
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).
So finally I am learning BASIC :) Nice video.
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.
"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."
It also wrongly assumed there was still a disk in the drive at all, which is doubly funny.
Not really, @@stevethepocket, because it doesn't say anything about the disk's presence.
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).
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.
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.
What is the song playing over the patron list?
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.
@@SkyCharger001 in my case though the flippy bit sectors seem to hold actual code rather than just a hard to duplicate object to test.
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
I don't know why those videos of presentation of this program had bad reviews. For me, they are nice ones!
3:40 it’s important to have off site storage of your backup in case major issues is the primary site.
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'
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?
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 :)
The end credits and the song... 💚
what song is that?
How did they write the errors to the disk in the first place, but make it so that those errors don't impede the loading?
Good question. I wondered that. I'm sure Robin is on the case!
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.
I'm having PTSD from some depth charging.
There is a good book on copy protection systems that were used on the c64.
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.
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?
I believe there is a reset switch on the super snapshot cartridge with the debugger.
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.
Great video, good explanation too..I enjoyed it very much 😀
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.
Great Video again, very interesting! If only i had all that knowledge 35 years ago... but better late than never i guess, haha ;)
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.
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'."
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.
Interesting video for sure, but it left me with the urge to play silent service. lol.
Same. Remember tense nights running deep listening to the pings of the destroyers roaming overhead.
What is that multi-cart adapter you have on there? Are the carts both active at the same time?
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.
Thanks so much for sharing. 😉👌🏻
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.
I think that GOTO160 is either a typo or a false hope trick that allows you to use a semi-successful copy once.
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.
I remember doing something similar on my Amiga 500.
I used to crack games/utilities back in the day. I learn machine code to do this. Lots of fun.
Lol " Help each other archive your legally purchased disks"
12:55 you mention that the nibbler doesnt support the reu so its slower. I dont see any reason why it couldnt though. Do you?
I can't think of any technical reason it didn't support REU, so I suppose they just didn't get around to implementing it.