Patches Sir Lancelot (Melbourne House) After long years of vain search, I finally could get to me an original cassette of this play. Which was not my surprise to discover that the author of the software had malicieusement incorporated in his work a small protection... * To make the transfer of the program with the following listing: 1 ' Sir Lancelot to Disk 2 ' 10 MODE 1:OPENOUT"d":memory &3A97 20 |TAPE:LOAD "!loader" 30 |DISC 40 POKE &3AB2, &C9:CALL &3AA7 50 POKE &3AC3, &C9:CALL &3AB5 60 SAVE "lancelot.prg", B, &4268, &5208, &7918 70 SAVE "lancelot.ecr", B, &C000, &4000 Up to this point, there is nothing private individual. Sir Lancelot is charged by a not protected routine using vector &BCA1. But, if you carry out the program transferred LANCELOT.PRG, when you are in the principal part of the play and that you select an object, the program blocks itself with a beautiful PIRATE message with the screen! After hard research, the solution of the enigma is as follows: The main program makes a checksum to check the presence of the binary loader cassette. That occurs in &8444. If the result of the test is not that awaited, a bit &7 to 1 is put in &7A55. Further in the program (in &90A7), on the level of the routine managing the principal room and the collisions with the objects, the program reads the contents of the box &7A55 (LD A, (iy-&7E)) and if bit 7 is not to 0, starts the "pirate mode". There are several solutions to inhibit this protection. 1) To charge in memory the loader cassette before the program! 2) To make a judicious POKE so that the checksum is always good. 3) To block the execution of the "pirate mode". One finishes with a loader BASIC allowing to make turn Sir Lancelot. 10 MODE 1:BORDER 0:INK 0,0:MODE 0:OPENOUT"d":memory &4025 20 FOR i=0 TO 15:READ a:INK i,a:NEXT 30 DATA 0,26,10,3,6,7,8,9,10,2,6,26,24,13,26,15 40 LOAD "lancelot.ecr", &C000 50 LOAD "lancelot.prg" 60 POKE &8456, &C9 70 CALL &7918