If you search the betza.txt file he does that himself. I'm not sure why but it works.
Beware that not everything in betza.txt might work. The continuemove that occurs in HandleMove is in a code branch that would try to resolve a remaining ambiguity, e.g. in case the first leg of a multi-move that had just been entered could also be a move in its own right. Most variants don't have such situations, so bugs there would not be quickly discovered.
I notice that the other occurrence of continuemove in betza.txt is actually in GameEnd (i.e. the Post-Game section), and that it is basically a deferred execution there: HandleMove discovers the entered move is incomplete (and could continue in multiple ways), and then sets a variable ok to 2 to relay that information to GameEnd, so it can do the continuemove there. I might have done things in such a round-about way because of what Fergus says.
I am not sure what the problem would be with using continuemove in the Post-Move section. I understand it should only be done after all moves of the game have been executed before invoking it, or the user would be presented a wrong position when prompted for entering the second part of the move. And using it in the Post-Game section guarantees that, as GC only executes that after the Post-Moves of all moves. But the Post-Move after the last move is basically executed together together with Post-Game, with nothing happening in between. So I could very well imaging that things that should not be used during execution of the Post-Move section of earlier moves are harmless in the Post-Move of the last move. (But this is just speculation.)
The HandleMove routine in betza.txt makes this distinction, as for efficiency reasons it only does a proper legality test there, and that is also the point where it would discover the entered move is still ambiguous. So it might get away with invoking continuemove in the part that is only executed for the last move. In that case using it in your Initial routines conditionally (when move 2 is not yet entered) would work too, as this can only happen on the last move of the sequence, just before invoking the Post-Game section; in the stored moves the prelude should always be present as a pair.
Anyway, in the Post-Move 2 for black's initial turn, which will be followed by the normal GameEnd when you are entering black's placement, you could simply do set ok 2 on an incomplete move, so let GameEnd invoke continuemove. After Post-Move 1 your own Post-Game-1 code will be executed. You could also use ok as a signal that the move found in Post-Move 1 was incomplete, and in that case let the Post-Game-1 code highight moves for the second placement, rather than the first, before making it invoke continuemove.
Beware that not everything in betza.txt might work. The continuemove that occurs in HandleMove is in a code branch that would try to resolve a remaining ambiguity, e.g. in case the first leg of a multi-move that had just been entered could also be a move in its own right. Most variants don't have such situations, so bugs there would not be quickly discovered.
I notice that the other occurrence of continuemove in betza.txt is actually in GameEnd (i.e. the Post-Game section), and that it is basically a deferred execution there: HandleMove discovers the entered move is incomplete (and could continue in multiple ways), and then sets a variable ok to 2 to relay that information to GameEnd, so it can do the continuemove there. I might have done things in such a round-about way because of what Fergus says.
I am not sure what the problem would be with using continuemove in the Post-Move section. I understand it should only be done after all moves of the game have been executed before invoking it, or the user would be presented a wrong position when prompted for entering the second part of the move. And using it in the Post-Game section guarantees that, as GC only executes that after the Post-Moves of all moves. But the Post-Move after the last move is basically executed together together with Post-Game, with nothing happening in between. So I could very well imaging that things that should not be used during execution of the Post-Move section of earlier moves are harmless in the Post-Move of the last move. (But this is just speculation.)
The HandleMove routine in betza.txt makes this distinction, as for efficiency reasons it only does a proper legality test there, and that is also the point where it would discover the entered move is still ambiguous. So it might get away with invoking continuemove in the part that is only executed for the last move. In that case using it in your Initial routines conditionally (when move 2 is not yet entered) would work too, as this can only happen on the last move of the sequence, just before invoking the Post-Game section; in the stored moves the prelude should always be present as a pair.
Anyway, in the Post-Move 2 for black's initial turn, which will be followed by the normal GameEnd when you are entering black's placement, you could simply do set ok 2 on an incomplete move, so let GameEnd invoke continuemove. After Post-Move 1 your own Post-Game-1 code will be executed. You could also use ok as a signal that the move found in Post-Move 1 was incomplete, and in that case let the Post-Game-1 code highight moves for the second placement, rather than the first, before making it invoke continuemove.