Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!kth.se!cyklop.nada.kth.se!news From: d89-zke@dront.nada.kth.se (Zoltan Kelemen) Newsgroups: comp.sys.cbm Subject: Re: Super Snap Shot Cart Detection?? Message-ID: <1990Sep28.142814.19193@nada.kth.se> Date: 28 Sep 90 14:28:14 GMT References: <418@news.nd.edu> <1990Sep15.171530.12692@xenitec.on.ca> < <436@news.nd.edu> > <438@news.nd.edu> <+VJ%*-+@rpi.edu> <1990Sep24.162347.24968@jarvis.csri.toronto.edu> <449@news.nd.edu> Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 29 As already mentioned, the easiest way to protect against snapshot cartridges is to use write-only registers. That is a common method used in many games, for example The Last Ninja. The programmer of that game, John Twiddy, is also the author of the Expert cartridge. I take two concrete examples: the real time clock and the timers of the 6526 chip. You may program the alarm (which is a write-only register) to a value only known by your program. When a snapshot cartridge freezes your game, it cannot read the setting of the alarm. The only thing your program has to do to check, is to set the real-time-clock to this value, and see if it triggers an alarm. There is another way (among many) involving two timers of the 6526. You start both timers, but the trick is to start the second timer a bit later than the first. The time-distance between the timers is only known by your program. A snapshot-cartridge will probably not take that in account. Now your program may periodically check that this time-distance is kept. Unfortunately, these methods are not future-proof, because if the author of a snapshot cartridge knows about them, he can update his software to handle them. He can for example read the alarm by setting the clock to all possible values, and see which one triggers the alarm. Perhaps this is already done in the cartridges, it was a couple of years ago I was in the protection business. /Zoltan (d89-zke@nada.kth.se)