The simplest way would have been to manually track exactly how many processor cycles were required for each subroutine. That seems crazy, but even in highly optimized code today you wind up doing it.

Once they had the final optimized versions of the code, they could store the current number of cycles used, and the number of cycles that the next subroutine was going to need. When a subroutine enters, increment the counter by that amount. When the subroutine exits, decrement the counter. If the counter is every above the maximum clock speed, you have to make a decision about which subroutine is executed, which could be done by manually selecting the priority for given subroutines and storing in a second register the rank of s given subroutine. If the next subroutine would make the processor exceed it's limits, and the next process was more important than the current one, exit the current subroutine and begin the next. Else, maintain the current one.

Then you could keep a queue of processes and go through them based on priority using the same logic.