| Author: | Antitrack (guest: search) |
|---|---|---|
| Date: | Tue, Dec 27th, 2005 @ 09:14 ( . ) |
You get it wrong. The FILENAME of a tape file can be up to 183 chars or something, but only the first 16 chars are displayed while using standard CBM load commands. So where is the rest? It is in the tape buffer area at 033c-0400, and you can actually store not just filenames there, but also whole little evil machinecode routines, many times, parts of the autostart loader. If you look at the normal load routines, you'll notice that a JSR $f7ea (at around f533) will fetch just this tape header. So do your own fileopen routines based on that, and you have the data you want. ATT |
 | Author: | Chuck Cochems (guest: search) |
|---|---|---|
| Date: | Fri, Mar 04th, 2016 @ 20:50 ( . ) |
Many types of tape protection existed. The simplest was the cassette buffer protection. This was done by including an ML routine or two in the tape header, which were called by the program. You could transfer the file easily enough, but the routine in the cassette buffer wouldn't be there, and the game would not work. The fix to this was to also save out the cassette buffer after loading the game, and write a simple basic loader that loaded the cassette buffer, then the main game. The d64 if snakman that says "ass presents" in the directory is a simple example of that. Another protection was to change the load address of the main game, but store it's real address in the header. so if you tried to load the main game by hand, it would crash the computer because it tried to store it at the wrong place. The loader on the tape would use a modified load routine that looked in the header instead of the program data for the load address (and that didn't blank the screen). this is fixed by copying the load address in from the header. Many old synapse tape games for c64 did this. Zeppelin was one example. this can of course also be combined with the cassette buffer protection. Later, fastloaders were developed, which provided extra protection by keeping the stuff in special formats. The higher bandwidth output formats were much more sensitive to sound quality, and thus were much more difficult to dub. also they tended to have pulses that confused the automatic gain control of consumer tape decks, so the copy wold fail. |