;name In Search of Efficient Code (7) ;strategy Triad of mutually repairing scanners intended -- ;strategy but not guaranteed -- to crush everything that ;strategy does not use SPL bombs or imps. ;author Robert Macrae ;assert 1 ; CORESIZE == 55440 ; MAXPROCESSES == 8 ; Ins8 doubles rate of self check. ; Ins7 revises life check so only one process can lurk, => 5 8 7. ; Better, but still too sensitive. Have to trace in detail... ; Ins6 Result *incredibly* sensitive to life check delay, ; EG 20 => 7 7 6, 40 => 6 4 10. What is going on? Perhaps several ; processes are lurking in check code? ; Better to revive BOTH partners or check only 1? Both might ; need a lock so to prevent 2 proc entering on simultaneous ; check... Should calculate the minimum acceptable life check. ; Mechanism seems to work, though less efficiently than I hoped. ; Is rescanning a problem? Move to different steps? ; Ins6: tries unequal steps. ; 269,283 used without any check on efficiency. ; Use clean SPL #0,#0 and JMP #0,0 to avoid triggering antifang? ; Better, use small offset to place DAT bomb somewhere useful? ; Ins5: Problem may be time wasted on life checks before ; the damage is repaired. Better to start life check _only_ on ; real repair, not when just at end of loop? Seems to work, ; winning 2/7 against weak Dat bomber DB1! Often seems to have ; 4-7 proc active. Faster way to do life check? ; Ins4 managed to repair one error, but succumbed to 0.6c DAT ; bomber DB1. ; Insear3 puts SC in main loop. Note bug in earlier versions; ; I was using an in-code DJN #70 to time clear! ; Currently no reanimation, so hurt by DAT bombs and imps. ; Runs, late self stun d.t. MUL not MOD. ; To stagger selfchecks, change P1P2 not scan! ; Insearch2 raises scan rate to 0.8c ; A should also compare B with C to reduce the number of ; failure modes. However, looks as if SC rate too low to ; be effective, so put SC in main loop. ; Scan at 0.5c. Length ~27x3 so self scan every 700 scans ; => 1400 cycles. Starting clear after 3x70 self scans gives ; a run of 3x70x1400 ~ 300k? ; Obvious attack is Imp or J0, but SPL/JMP beats scanners? ; Vulnerable to step sizes close to GAP. ; Imps should be dead so clear can be shortened? ; Currently all will selfcheck at same time. Stagger? ; New failure mode -- if SPtr is overwritten,scan will fail ; for equal steps. => unequal! ; Perhaps I should check for overwrite of SPtr. Copying own ; SPtr (.x?) would prevent some kinds of rescans... but ; might also lead to looping. ; Add some increments to SPtr in selfcheck and bomb code to ; guarantee I pass life test. ; Better to do life test only every scan reset? ; Should second life check be at start or end? ; Better resistance to imps if I check forwards and lifecheck ; only after a complete scan? ;---- Constants STEP1 equ 269 ; Work on this! STEP2 equ 283 ; Work on this! SCANAT equ 300 ; Start relative to self OFF equ 100 ; Phasing between scanners GAP equ 18480 ; 55440/3 LENGTH equ (Top+1-SPtr) CFROM equ (Top+2-P1P2) ; Start check 1 after end BLEN equ ((LENGTH+3)/4) ; 4 proc boot SPtrCp equ (SPtr-1) ;---- Variables SPtr DAT SCANAT, SCANAT+30 ; Scan pointer FPtr DAT 0, 0 ; Fang pointer P1P2 DAT CFROM-GAP,CFROM+GAP ; Self check SelfP DAT 0, 0 ClrCtr DAT 70, Clear+4-T1T2 ; # Selfscans to do ; Idea is to keep all the variables here so that the code ; from T1T2 is NOT self modifying. ; Think of it as an address space 8-) ;---- Self-Check Constants / Bombs T1T2 SPL #CFROM-GAP,CFROM+GAP ;b-reak Stepper JMP #STEP1, STEP2 ;---- Code ;b-reak SAttack MOV.b SPtr, FPtr ; Antivamp .b field ADD.b SPtr ; SPL/JMP Bomb MOV.i Stepper,@SPtr ; Note > to SPtr... SLoop SEQ.i