Early kernel relocation of SvarDOS flavours is difficult to trace
The copywords function is used twice and the data that it copies seems to include itself in both cases. This is a problem when lDebug is used to trace/proceed, either with tp or p on the rep movsw or a p on the call copywords, as they will cause the copy to copy the int3 breakpoint to the destination rather than the original data.
My programs do a lot of relocation but I have seldom had problems like this yet. Fortunately with the debugger support enabled we can skip past the early relocation / depacking by running an lDebug g command.
The double copy is not actually needed on the uncompressed freedos load protocol. could be optimized by a single move. maybe I revisit this at a later time...
You'll have to move backwards to directly move from 00600h to 00700h. And you need a small relocator stub to execute outside the kernel data.