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
10 MODE 1:OPENOUT"d":memory &3A97
20 |TAPE:LOAD "!loader"
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 DATED 0,26,10,3,7,8,9,10,2,6,26,24,14,26,15
40 LOAD "lancelot.ecr", &C000
50 LOAD "lancelot.prg"
60 POKE &8456, &C9
70 CALL &7918