The module 4A/Flyer had some similar copy protection. As the module was in ROM in the >6000 to >7FFF memory space, it would attempt to modify an address. If it was ROM, it would not change. If it was being run in RAM without the memory write protection switch turned off on the GramKracker, it would would write to the instruction. Then, when code was run in that area, it would stay in an endless loop and hang.
These are still simple ways of copy protection. If you have the source code and find this test routine, it suffices to modify a single word (e.g. the address where it writes to). Also, in those schemes that I mentioned, the boolean check must be removed, and things should work well.
I myself used an integrity check in my Fractals program (which I am a bit embarrassed about now) which did the following:
- Calculate a checksum over the used memory (adding all bytes, maybe doing some other voodoo)
- Add a constant a0 to that value to calculate an address a
- Add another constant v0 to that value to create another value v
- Add (or xor or whatever) that value v to the existing value at address a
If something has been changed, you get another value for a and for v, which probably breaks some other instruction, but at least does not modify the instruction at address a.
So I assembled the program, then I had another tool that runs the checksum routine and calculated the values a0 and v0, which I wrote into the program code. The target address was set to be in the main menu loop, so it had a broken instruction that immediately locked up the program.
This is slightly more complicated to remove, since you must find out which instruction is bad, requiring you to disassemble the program and find out where I put the bad instruction. But not impossible. (Note that with today's tools like emulators with debuggers, you can possibly find out rather quickly, just need to compare the memory dump of the running program with the program code.)
I don't know detail of the copy protection of MG. What is indeed possible:
- Use a non-standard track layout. You may then try to read the whole track and check the sector sequence. COPY-C should handle that.
- Use a non-standard sector size. You can indeed change sector sizes whereever you want, since the sector size is defined in the sector header of each sector. Not sure whether COPY-C can cope with that.
- Things are becoming rather ugly when the program loads data from that sector that is supposed to be executed. If you cannot copy that sector, or if you kill the protection check routine, this code will be missing.