Programming the Commodore 64: the Definitive Guide
Mirk writes "Back in 1985 it was possible to understand the whole computer, from the hardware up through device drivers and the kernel through to the high-level language that came burned into the ROMs (even if it was only Microsoft BASIC). The Reinvigorated Programmer revisits R. C. West's classic and exhaustive book Programming the Commodore 64 and laments the decline of that sort of comprehensive Deep Knowing."
One of the most comprehensive protections at that time was called "V-Max!" which stood for Verify Maximum. What were called "nibblers" for disc copy software couldn't touch it even though those nibblers represented the ultimate in disk copy technology at the time. There were two ways to copy V-Max, the first was to get a dedicated hardware copying unit. The second was to apply a bit of knowledge with a debugger cartridge: the V-Max protection was a turn-key system you gave them files and they wrapped the protection around it and provided a fast-loader at the same time. So what you would do is fill all of memory (the whole 64K) with a value you knew say: $AF. Then you would load a V-Max file from the disc, it's loader would automatically take over and while it was loading you would enter your debugger cartridge and change it's exit point to point to itself. So instead of $0800: RTS you would make it $0800: JMP $0800. Then you would wait for the V-Max loader to fully load the file. Then a quick button press on your debugger cartridge and use the memory monitor to find where the file loaded by seeing what memory was NOT $AF. Then from the debugger cartridge save that memory block out again. Completely de-protected file. Since V-Max used standard kernel-load vectors the program itself needed no further modification, the protection was completely gone you just lost the fast-loader function. Which you then re-added yourself into a chunk of memory wherever the game didn't use it. Relocatable code was best for that. Later versions of V-Max also did on-the-fly decompression of files so occasionally while stripping the protection you would run into a situation where your destination disk ran out of space versus the original protected disk. Again, that was worked around by inserting your own custom loader into the kernel load-vectors which also did decompression. V-Max was impossible for copy software of the day to copy but with a little bit of knowledge and a debugger cartridge it was absolutely trivial to defeat.
Shh.
There doesn't appear to be any section on custom high-speed communication with the external floppy drive unit. IIRC, you could upload a small program to the drive, and then you could in particular read data from the drive a lot faster than the 'OS' normally supported. This technique was also used to do copy protection for a bunch of titles, primarily by stepping the drive head 1/2 between tracks then doing reads. Production disk duplication could write to both the track & between tracks [or could write a wide enough track to cover the whole area], but regular floppy drives couldn't write both [you could either write on the track, or between tracks].
Not that I was interested in this stuff or anything.
Sleep your way to a whiter smile...date a dentist!
I was playing a game with some DRM (either StarForce or SecuROM) and it wouldn't run if I had a debugger present. I asked them why and they were all like "Anyone who has a debugger and is playing the game is a hacker." That's RIGHTLY earned state of paranoia.
And why did I spend time removing protection systems? Funny that part is: I owned an MSD floppy drive which was completely incompatible at a machine-language level with the 1541 drives everyone else owned and that all the game-makers wrote their protection systems for. So my floppy drive would load any of the software of the day. I literally bought a game, had to hack away the protection, and then I could play it on my computer. Of course no one will believe me when I say this but damnit, its the truth! Now get off my lawn.
Shh.
Fast loaders worked because the kernel ROM software didn't fully take advantage of the hardware. Between the C64 and the 1541 floppy drive the connector cable had 4 wires for carrying information. The kernel routines built into ROM only used one of those lines to signal from the drive to the computer. The "fast loaders" simply uploaded a program to the drive which used all four lines to signal information. The "fast" loaders weren't fast magic they just removed a deficiency in the kernel ROM routines. The exact number of lines between the computer and drive I'm not sure of but this is the principle the fast loaders worked by. And tape based fast loaders worked because the kernel routines would save a copy of the information to tape and then immediately save a complete other copy to compare against for error correction on load. The tape fast loaders just skipped saving and comparing the redundant copy to get the speed. Disk fast loaders didn't compromise the integrity of the information in the way tape fast loaders had potential to though. Remember computers back then were full of noise when you were talking to tape drives especially.
Shh.
Yet every day, I put young pups to shame. It does not matter if it is troubleshooting hardware, or software. It does not matter if it is dealing with programing or configuring. My mental map of the problem is different than theirs.
The skills I learned back in the 80's on a computer that you could understand, I still use today. My "concept" of what a computer is was formed by understanding the whole. RAM, ROM, interrupts, I/O, how the CPU works. All from a machine with 64K or RAM and 20K of ROM.
Under the hood, under all of that abstraction. Is a PC that is very much like a C64. With the C64 people learned mastery of their system. With the PC, so much hardware is out there. It is impossible to learn it all inside out and take advantage of every feature of it. So greater power has always been obtained in the PC world by moving to faster hardware, not by utilizing the current hardware better. It is all abstraction running on very fast, underutilized hardware.
The techs coming out of college for the last 20 years do not understand a computer conceptually like those who learned this stuff in the 70's or 80's. When it comes to trouble shooting all of this abstraction, many folks have no idea that there is anything beneath the abstraction.
I recently attended a college programming class as a requirement for a degree. The instructor gave us a quiz at one point and there was only 5 students out of 60 that passed. Why? Because most students did not know how to write a program on a piece of paper. Without intellisense holding their hand they could not code. I learned to program from the manual that came with my C64. I learned to program better by typing in programs from Compute! Magazine. I have written hundreds of pages of code on paper and typed it into a computer at a later time. It is a skill I take for granted. Without the abstraction of Intellisense most of the class was rendered useless.
Something has been gained, but something has also been lost. When I was a kid I dreamed of computers that could do a 10th of what they do now. I learned everything I could about them. Lived, dreamed, ate, slept computers, computers, computers. Now days. My kids can buy a laptop with 3 gigs of RAM for the price of a C64 and 1541 drive. And what do they do with it? Program? Nope. They learn their friends on FaceBook, not programming. They play games, not write them. They pirate music, not create it.
It looks like those who understand a computer and really make it do something will always remain a small, elite Priesthood.
vi +