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.
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.
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
@@JayAlfredoG 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 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!
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.
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.
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.
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.
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
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 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. :)
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.
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 TH-cam. Ninja star! The photo of Darren with the raised eyebrows was hilarious.
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. :)
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.
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 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.
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.
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!
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.
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 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.
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
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'
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.
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”
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.
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.
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).
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..
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.
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!
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.
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.
4:52 How does Maverick detect the disk is not write-protected? Does it write something to the disk to test or is there a way to ask the drive to check if the write-protect notch is covered? If it has to write the disk to test, that does sound slightly dangerous, or at least unexpected and unwanted to write to old precious disks you want to keep pristine.
Not dangerous: According to my research, you can check the write-protect notch without needing to write to the disk. Inside Commodore DOS, page 226, says the 1541 drive's memory address $1C00 bit 4 is "write protect sense". Debugging Maverick's single 1541 copier, I found it checks this address by sending a MEMORY-READ command to the drive, and if bit 4 is set it shows the warning message the disk is not write protected.
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).
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 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.
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 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. ;)
"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."
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!
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.
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.
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.
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?
3:24 Never heard the term "Softwire" before. 3:38 Have you been "out-bearded"? 4:34 You ought to be able to copy a 1541 disk in 170 / 57 = 3 chunks on a stock 64. 8:30 Does SuperSnapshot have a one-key option to LOAD & RUN the first program from disk 8? 8:37 Would you have better luck putting a disk over the 1541's transformer? 9:43 It wasn't until the 1581 that Commodore drives had enough internal RAM to cache a full track of data. They should have done that with the 1571. Sector interleave be gone! (I suppose they take static RAM, making it a little more expensive.) 10:00 Blasphemy! This program uses the Atari font! 10:45 Asynchronous serial has the same logical-bit density. 11:06 That seemed about as fast as the non-nybbler. 12:53 Nybbling could be done in 170*5/4/54 = 4 chunks. They could have a mode to detect if nybbling is even needed for a track and shrink the data if it isn't. 16:06 Do they really need to waste time checking for more than the first error? 21:34 You phreak! 22:12 Looks like you recorded this episode over an old video tape!
Minor nit-pick: "It wasn't until the 1581 that Commodore drives had enough internal RAM to cache a full track of data" This isn't strictly true as the dual 8" floppy drives for the PET (8060/61/62 & 8280) had 8KB of SRAM. For practical purposes though I believe you are more or less correct as the RAM on the dual 8" drives is split into 4KB chunks between the *TWO* 6502 processors, iirc.
@@csbruce They were definitely aimed more at the more "serious business" type users, although eventually people who ran Commodore BBSes grabbed them used, etc since the quad density 8" disks held 512KB per disk side. Especially the 8280 was coveted as with two dual sided drives that was a full 2MB of storage without swapping disks. A much cheaper alternative to the *very* expensive 5MB and 10MB Commodore hard drives.
@@csbruce Yes, that's true iirc. I think the only difference is 8250 only has 4KB SRAM (2KB per controller) and 8280 has a slightly higher version of CBM DOS. Very equivalent unless you actually needed the compatibility with using IBM 3740 format disks which only the 806x/8280 drives could do.
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.
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?
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'. 😉
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
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 :)
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.
Does anybody know how GEOS was copy-protected? I remember (I was 11) that my GEOS disc had a special sector that generated random readings and GEOS tried to read that sector twice and compare those values - they should be different and copy had always the same value...
Check out the C64 Preservation Project website which has some excellent articles on copy protection. I'll leave a link in a 2nd comment but youtube might censor it.
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.
This copy protection via deletable lines in basic make me think they did this so schools and whatnot ordered copies of the game for every computer not just a couple copies. Or that a school wouldn’t make their own copies of the disk. Idk anything about this game in particular or if it has any educational value to it but just a thought.
Odd. Apple ][ can do 35 or 40 tracks, Atari 8-bit can do up to 40 tracks but can do fewer tracks if the SpartaDOS formatter detects format errors in the last 5 tracks (and in turn can mark bad sectors as In Use but would you want to trust a floppy with a bad surface?), and the Commodore drive can do only 35 tracks? It should be able to do 40. I'm surprised you didn't use Fast Hackem to make the copy.
The 1541 drive can typically handle 40 tracks fine, but the default CBM DOS format is 35 tracks. Some copy protection schemes use the extra tracks, while custom disk formats (used by some commercial games) would use the extra tracks for data.
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.
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.
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?
@@JayAlfredoG 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 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!
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.
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.
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.
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.
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
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
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.
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!
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.
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!!!!
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.
I have been waiting for this episode. Those tutorial videos you did are among my favourites, don't listen to TH-cam. Ninja star!
The photo of Darren with the raised eyebrows was hilarious.
6:26 For a moment i though somebody was calling me...
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?
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.
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.
Robin, you know quite a bit about copy protection schemes on the Commodore 64 please make more videos about it!
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.
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.
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.
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!
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.
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 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!
Great video - I need to share this on my "C64 Copy Protection Blog" - Please make a few more of these.
Liked that song at the end - I recognized it was about phone phreaking.
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
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.
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.
I love every clip of yours . Truly appreciate the detail and always look forward to the next one
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've been hoping for a video from you about copy protections. So this was great, thanks!
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.
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.
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 remember the Maverick program, most of our C64 software were copies made with that software. Including our copy of Maverick.
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.
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.
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).
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.
So finally I am learning BASIC :) Nice video.
3:40 it’s important to have off site storage of your backup in case major issues is the primary site.
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..
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.
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!
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.
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.
4:52 How does Maverick detect the disk is not write-protected? Does it write something to the disk to test or is there a way to ask the drive to check if the write-protect notch is covered? If it has to write the disk to test, that does sound slightly dangerous, or at least unexpected and unwanted to write to old precious disks you want to keep pristine.
Not dangerous: According to my research, you can check the write-protect notch without needing to write to the disk. Inside Commodore DOS, page 226, says the 1541 drive's memory address $1C00 bit 4 is "write protect sense". Debugging Maverick's single 1541 copier, I found it checks this address by sending a MEMORY-READ command to the drive, and if bit 4 is set it shows the warning message the disk is not write protected.
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).
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! 🏴☠️
Why does it show *ILLEGAL COPY* at 11:43 ?
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 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.
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 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. ;)
What is the song playing over the patron list?
"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.
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!
I think that was just left over from the previous attempt.
Thanks so much for sharing. 😉👌🏻
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.
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.
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.
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...
What if the program is compressed using Base64 so if the Base64 decompressor is not found or disabled the game will not load and execute.
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.
I wanted to see what happened @ 23:59:59 FRI DEC 31, 1999! What do I have to do become a patreon?
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?
3:24 Never heard the term "Softwire" before.
3:38 Have you been "out-bearded"?
4:34 You ought to be able to copy a 1541 disk in 170 / 57 = 3 chunks on a stock 64.
8:30 Does SuperSnapshot have a one-key option to LOAD & RUN the first program from disk 8?
8:37 Would you have better luck putting a disk over the 1541's transformer?
9:43 It wasn't until the 1581 that Commodore drives had enough internal RAM to cache a full track of data. They should have done that with the 1571. Sector interleave be gone! (I suppose they take static RAM, making it a little more expensive.)
10:00 Blasphemy! This program uses the Atari font!
10:45 Asynchronous serial has the same logical-bit density.
11:06 That seemed about as fast as the non-nybbler.
12:53 Nybbling could be done in 170*5/4/54 = 4 chunks. They could have a mode to detect if nybbling is even needed for a track and shrink the data if it isn't.
16:06 Do they really need to waste time checking for more than the first error?
21:34 You phreak!
22:12 Looks like you recorded this episode over an old video tape!
Minor nit-pick:
"It wasn't until the 1581 that Commodore drives had enough internal RAM to cache a full track of data"
This isn't strictly true as the dual 8" floppy drives for the PET (8060/61/62 & 8280) had 8KB of SRAM. For practical purposes though I believe you are more or less correct as the RAM on the dual 8" drives is split into 4KB chunks between the *TWO* 6502 processors, iirc.
@@JeremyLevi: I didn't know Commodore ever made 8" floppy drives.
@@csbruce They were definitely aimed more at the more "serious business" type users, although eventually people who ran Commodore BBSes grabbed them used, etc since the quad density 8" disks held 512KB per disk side. Especially the 8280 was coveted as with two dual sided drives that was a full 2MB of storage without swapping disks. A much cheaper alternative to the *very* expensive 5MB and 10MB Commodore hard drives.
@@JeremyLevi: The 8250 5¼" disk drive had the same capacity.
@@csbruce Yes, that's true iirc. I think the only difference is 8250 only has 4KB SRAM (2KB per controller) and 8280 has a slightly higher version of CBM DOS. Very equivalent unless you actually needed the compatibility with using IBM 3740 format disks which only the 806x/8280 drives could do.
Great video, good explanation too..I enjoyed it very much 😀
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.
Apparently I follow you here already. And not just on TikTok
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.
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.
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'. 😉
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
god I miss those early computer days
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 :)
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.
Does anybody know how GEOS was copy-protected? I remember (I was 11) that my GEOS disc had a special sector that generated random readings and GEOS tried to read that sector twice and compare those values - they should be different and copy had always the same value...
Check out the C64 Preservation Project website which has some excellent articles on copy protection. I'll leave a link in a 2nd comment but youtube might censor it.
c64preservation.com/dp.php?pg=protection
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.
What is that multi-cart adapter you have on there? Are the carts both active at the same time?
Great Video again, very interesting! If only i had all that knowledge 35 years ago... but better late than never i guess, haha ;)
This was very intersting!
This copy protection via deletable lines in basic make me think they did this so schools and whatnot ordered copies of the game for every computer not just a couple copies. Or that a school wouldn’t make their own copies of the disk. Idk anything about this game in particular or if it has any educational value to it but just a thought.
I don't know why those videos of presentation of this program had bad reviews. For me, they are nice ones!
There is a good book on copy protection systems that were used on the c64.
Odd. Apple ][ can do 35 or 40 tracks, Atari 8-bit can do up to 40 tracks but can do fewer tracks if the SpartaDOS formatter detects format errors in the last 5 tracks (and in turn can mark bad sectors as In Use but would you want to trust a floppy with a bad surface?), and the Commodore drive can do only 35 tracks? It should be able to do 40.
I'm surprised you didn't use Fast Hackem to make the copy.
Were 5 tracks reserved for the Table of Contents or somesuch?
The 1541 drive can typically handle 40 tracks fine, but the default CBM DOS format is 35 tracks. Some copy protection schemes use the extra tracks, while custom disk formats (used by some commercial games) would use the extra tracks for data.
JiffyDOS and many others can do 40 tracks just fine, it worked on almost all disks.