Have you ever tried to load one of those Mastertronic tape games that use an early version of Burner just to find yourself facing the following sort of puzzling screen output?
Early Mastertronic Burner load breaks unexpectedly
Loading from the cassette interrupts due to a “BREAK” condition detected but you have neither willingly or unwillingly pressed the RUN/STOP key. So what is going on here?
Well, first thing is that if you hit RUN/STOP and RESTORE together, you can then issue a RUN command and keep loading the game. Example:
All is well – just hit RUN/STOP + RESTORE and issue RUN
Burner loading resumes from here
Back on the question: what is going on here? Some people might not even have this issue at all when loading the tape on their C64. In fact, I believe these early Burner tapes used to work on earlier C64s (1984 or thereabout). I won’t go deep into the details of this, but basically on later models of the C64, including emulators, the ISTOP vector (at $0328/$0329) seems to be erroneously set to $F6E0 rather than $F6EF or $F6EA: these are the values one would expect to find in order to disable the detection of RUN/STOP and RUN/STOP+RESTORE respectively. Disabling RUN/STOP+RESTORE prevents users from stopping and listing the BASIC program currently being executed (the one with the “hit a key to continue” message in the above screenshot): it is a sort of source code protection as the BASIC program is auto-executed and unstoppable.
$F6E0 is right in the middle of the CBM Kernal function that reads the real time clock. Such code happens to leave the flag register in a state that triggers a false positive detection of the STOP key press. That’s why the READY prompt is returned with a BREAK condition. The Kernal code that tests the STOP key is at $F6ED (which is what ISTOP points to normally).
The interesting thing about this is that the vector manipulation is made via an illegal/undocumented opcode (used along with other invalid opcodes by the coders in order to achieve code obfuscation):
SAX $0328 ; Set LSB of ISTOP (this results in $E0 in later C64s and emulators - meant to be $EA or $EF in older ones)
I believe the results of the execution of the obfuscated code above depend on the C64 in use.
Later versions of Burner do not use illegal/undocumented opcodes, but clearly set ISTOP as per below, possibly due to the fact its authors were reported about issues with later models of the C64:
That is it from me :)