Due to the recent discussion of self-checkers, I've decided to post my most successful specimen of this type. The only reason I haven't tried it on the hill is because a process limit of 8000 makes SPL 0 bombs far too effective. However, with a process limit of 64 (which is the limit used in official tournaments, I believe), Checker will beat Crimp, Agony 2.1, Synch 4, and Charon 3.0. (Of course, Synch 4 is pretty old by now, and a big part of Charon 3's losses lie in the fact that it scans locations exactly 4000 addresses apart, which means it compares two copies of the checker.) Checker has a lot more trouble with small, blind bombers - against Small 4, it will repair itself a few times, but eventually the bombs will overwrite one too many copies. However, the fact that it does repair itself a few times before succumbing gives me hope. I haven't bothered to try it against slavers such as Sucker 3 or Scissors88, because it has no way of killing the captured processes. I tried once to add in an anti-vampire section, but this increased the code by about 10 lines, so I dropped it. Checker (without the STARTUP loop) contains 33 lines of executing code, along with a few data statements at either end. In its complete form, there are 4 copies of the checker scattered around the core, each one 2000 addresses away from its neighbors. Each of the 4 processes normally executes 4 lines of code which compare a line in the current copy with one in the next copy, then increment the bombpointer by 6, then scan that location, then loop back to check the next address. If something is found, it checks to make sure it hasn't found the next copy, bombing if it hasn't. If it has, it changes from SPL 0 bombs to DAT 0. If, while comparing its code, it finds a discrepancy, it checks the copy 2000 back. If a difference is found there too, it suicides. Otherwise, it goes into sterilization mode. First, it sets up a DAT beyond the end of the bad copy to interrupt any trail of SPL 0 bombs, keeping any/all extra processes within range of the sterilizer. It then drops a DAT in the beginning of the copy's sterilize code, preventing it from killing off the next copy. Next, it drops a DAT in front of where the error was found - this either prevents the copy from executing the error or kills the SPL 0 part of a SPL 0/JMP -1 bomb. It then bombs the major loops, preventing processes from looping back into SPL 0. Finally, it does a complete sterilization of the damaged copy, beginning at the DAT it set up ahead of the copy - thus, any/all processes that followed a SPL 0 trail get killed first - and ends by recopying itself and starting up the copy once more. If an enemy cannot bomb faster than Checker sterilizes and copies, it is very difficult to kill it off. Of course, there are a few vulnerable moments (such as when it is copying), but on the whole, this is a very robust program. I believe that a reduction of the process limit on KotH would be worthwhile, making it possible for programs like this to do well against small and stupid programs. Modifications/improvements/feedback/etc. are welcome. ;Checker 5.4 - Kent Peterson ;6/9/92 opc3 equ 37 opc equ 33 ;program length, without bomb opc2 equ 36 ;prog length, with bomb (to copy) osc equ 2009 ;9 to sterilize any SPL 0 trail opp equ 1998 ;points to positive program for checking opp2 equ 2000 ;points to positive program for copying killc equ 15 ;time to spend sterilizing startup:mov