In this section I will discuss a few aspects of the Suspend/Resume mechanism.
The above diagram illustrates the Suspend/Resume mechanism.
The Resume instructions retrieves a previously saved program location from RAM, and resumes the program from that point. That means that:
The resume address must be "primed" by initialization code.
The Suspend instruction saves the current location and then executes a Return. That means that:
The Suspend must be executed inside a subroutine.
Suppose that inside the subroutine where you do the Resume, you call another subroutine. Could you do a Suspend from within that "inner" subroutine? Well yes, you could, providing the inner subroutine has a separate designated pair of RAM bytes to store its suspend address. If it doesn't, then bad things will happen.
Another important thing to note is that there is no automatic mechanism for saving what's in the registers (X, Y, W, Q etc) between calls into Task1.
You should always assume that doing a Suspend will result in every register being altered.
The following diagrams illustrate a few of the possible permutations of subroutines and suspend/resume. In all these examples the resume address is assumed to have been initialized.
The first diagram (below) shows a 2nd level subroutine call and return from inside a first level subroutine that has a suspend/resume mechanism. That is perfectly OK, because the suspend and resume are at the same subroutine nesting level.
In the next diagram below the second level subroutine also has its own suspend/resume. As long as it uses a separate place in RAM to save its resume address, that's fine (mind you, I've never had to resort to a structure that involved). This case was also mentioned above.
In the next example, we GoSub a level 1 subroutine which subsequently does a Return (rather than a Suspend). What will happen? It will return to the main program as expected. The next time it is called, it will simply resume from exactly the same place as the first time, as the resume address in RAM is unchanged.
The next case is a possible trap for young players. In the level 1 subroutine we resume, then call a level 2 subroutine and do the suspend from there. That suspend will return SPLatty to the level 1 subroutine, not to the main program.
You may be wondering why Suspend performs a subroutine return and yet Resume does not perform a subroutine call. Surely it would be more logical to make them behave symmetrically? The reason they are not symmetrical is this: By making it so Resume must be executed inside a subroutine, it gives you the opportunity to place any code that is common to every state of the subroutine (task) before the Resume. This can save a lot of code. The most common instance is a task that is always synchronized to either a time event or an InputK.
Special note: This tutorial and the multitasking mechanism it covers have largely been superseded by the newer MultiTrack mechanism. MultiTrack achieves everything and more, with considerably less programming effort. The only time you would use this older multitasking mechanism would be if the controller you are using is unable to handle as many tasks as you need using MultiTrack.