Way to implement multi threading on a MOS 6502 type CPU [closed]

There is not much room on a typical 6502-based system to multitask many different tasks at once without incurring a lot of runtime overhead, but basic multitasking can be done pretty well.

You'll need a routine that transfers control from one task to another; this is the crux of the matter. Each task will also need some place to store its context (read: the processor's internal registers will need to be saved somewhere, perhaps in the zero page, and then read back into the processor).

This routine, the task switcher, could be called from the tasks themselves, for cooperative multitasking*, or you could have a timer interrupt which calls the task switcher (preemptive multitasking).

Each task you want running will probably needs its own region of stack. You could split the stack page into four areas - one for each of your three tasks, leaving one for your multitasker - or some other such scheme.

It's not clear what exactly you're finding difficult about this, so forgive the vagueness of my answer here.

So let's say you have some small number of tasks. You could reserve an area of memory, having space for the context of each task. To suspend a task, you need to store the flags, A, X, Y, the stack pointer and the program counter to the corresponding area of memory. Then, to resume the task, you need to load A, X, Y, the stack pointer, the program counter and flags from the same region of memory. Doing this will mean that the corresponding task resumes. I would suggest initializing this table to a state where all tasks can be considered suspended. That can simplify the task switcher.

If that's your setup, then your multitasker just needs to suspend the running task, if any, and then resume the next task. A simple multitasker can simply switch between two tasks. More complicated, but still doable, is switching between an arbitrary number of tasks. More complicated still is managing task priorities, letting tasks sleep and wake back up. The possibilities are endless.

Depending on what you're doing, you could do variations on this theme. For example:

• are you going to use IRQ to switch to the next task? In that case, you probably want to leave the flags on the top of your stack, instead of explicitly saving them to an area of memory.

• Do you have a lot of tasks, or very deep callstacks? In that case, you might need to end up saving and restoring a task's stack itself as well, which will increase the overhead a lot. Then you might need to implement priorities, so that your most important tasks still get enough CPU time.

• Are you going to use cooperative multitasking only? In that case, you can probably get away with saving/restoring much less data between task switches.

• Can you make guarantees about what resources your tasks use? For example,

  • it will simplify things a lot if your tasks never trample each others' memory, be that the zero page, the stack, or any other memory.
  • Maybe you want to support stackless coroutines. It's trivial for these to task switch between each other cooperatively using a single jmp.

Related considerations:

Since you mention that you're writing an operating system for the 65C02, you might want to consider the following:

• Interprocess communication:
  • Unix has pipes, signals, shared memory and others. FreeRTOS has mutexes. Your multitasking operating system might want to implement the same.
• Ability to suspend a task while it's waiting for something
  • For example, if one of your threads is waiting for a mutex, timer or read from stdin, then it has no need to be using the CPU. What FreeRTOS does in such a case it is stops trying to resume the task. FreeRTOS keeps track of when to resume a sleeping task.