I'm not sure this is the article I was thinking of, but I came across one of Brad Rodriguez's, "Forth Multitasking In a Nutshell," on paper in The Computer Journal, issue #58, Nov/Dec '92, and asked him if it was online since I couldn't find it there. He said he would try to find it on an old disc and convert it to html and post it, which he did in record time, at http://bradrodriguez.com/papers/mtasking.html.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Interesting article and I'm pleased to note that he clearly differentiates between "multiuser" and "multitasking." The former is implicitly the latter, but not vice versa.

The Forth multitasking method, while efficient in the use of system resources, has a theoretical risk of deadlock if one of the tasks misbehaves. Avoidance of deadlock is one of the key benefits of using a jiffy IRQ to suspend the current task and restart another. However, an IRQ-driven task scheduler adds to the processing load and doesn't guarantee that any one task will meet required processing deadlines, often a requirement in Forth applications.

An IRQ-driven task scheduler isn't all that difficult to implement with the 65C816, thanks to the relocatable direct page and stack. Reentrancy is also relatively trivial, thanks to stack pointer relative addressing. Something similar could be accomplished with the 65C02 if the glue logic supports memory banking in a way that allows each task to have its own zero page and stack.

I've tinkered with a crude task scheduler on POC, which I had briefly incorporated into the firmware as an alarm function. I later removed it after deciding that I could better use the ROM space for other things. The principles are fairly basic:

1. Push all registers to the stack, including DB and DP.
2. Write SP to a "shadow" location that only the current task can access.
3. Load SP from the new task's "shadow" location.
4. Pull all registers from the stack in the reverse order of how they were pushed when the task was suspended.
5. Execute RTI, which will restart the task.

Starting a new task involves setting the initial stack pointer, loading the stack with dummy values for the .C, .X and .Y registers, loading the stack with the proper values for DB, DP, PB and PC, and then continuing at step 4 above.

Obviously, there's more to it, but the above covers the elemental parts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have no experience on the insides of multitasking OSs of any kind, but although what Brad is telling about in the article may have more luxuries than needed (that's my perception anyway), it still does not require pushing any more than four registers in a task switch. That's pretty economical in terms of overhead! I've been tending toward advocating for the benefits of cooperative rather than preemptive, as our 65-family software will be our own and not commercial, and we have control of everything to fix our bugs and prevent the deadlocks from misbehaving tasks.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I have a new 6502-oriented article up on my website on simple methods for doing multitasking without a multitasking OS, for small systems which may not have the resources for a multitasking OS, or where hard realtime requirements may rule one out. The article is at http://wilsonminesco.com/multitask/index.html.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Multitasking with 65xx hardware is not something on we've seen much discussion, so your page (which I have read) comes at a good time.

As Garth notes in his article, if your system is intended to be a single user system, as most 65xx hobby systems are, you will do fine with simple cooperative multitasking. Such an environment is less demanding to develop and is much better suited to real time applications. The primary caveat is that all applications must behave, since the failure of one may cause system deadlock.

While a cooperative multitasking system that performs with alacrity may be implemented on a 65C02 system without an exorbitant amount of effort or fancy hardware, preemptive multitasking on that same system could potentially be a nightmare of trying to protect page zero and the stack, as well as keeping one application from stepping on another's space. A preemptive multitasking kernel is no trivial thing to develop for the 65C816. However, that MPU has features that can be harnessed with programmable logic to provide the necessary hardware support. Doing so is a long-term goal of mine.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

One view of multitasking that I haven't seen discussed much is semi-preemptive checkpointing. This is used often in larger machine VMs, to interrupt threads cleanly for garbage collection, message passing, or other background processing.

The basic idea is that you write straight-line code, instead of continuation/event based handlers like typically found in cooperative multitasking. But at certain known safe points, outside of atomic actions or when the registers are free, you perform some quick check which may result in a yield. The program can then resume from there when its time comes around again.

In the main Java JIT, these safepoint checks are done by putting an memory read instruction to a fixed location at the end of subroutines and loop bodies, and the usage of all registers at these specific locations are known from the debug info for safe introspection & GC. When the VM wants to interrupt a thread, it sets that memory location to unreadable, causing a software fault at that some expected safe location. For the 6502, the simplest and fastest checkpoint test I can think of is to work with interrupts disabled, then run a CLI, SEI as the test. Just 2 bytes and 4 cycles would allow interrupts to be asynchronously raised and interrupt only at safe points of the program. This does require code injection, but again it does allow you to write straight line code, more suitable for desktop & application style programming.

In AcheronVM, the ISR uses self-modification to adjust the main VM dispatch to call out to a service handler instead of the next instruction processor. I believe the "zero overhead" Forth ISR does something similar. These can also be considered checkpoints, where the VM is in a known "safe" state outside of instruction processing that allows the whole VM state to be migrated much easier than if it were fully preemptive.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

It's up, at http://wilsonminesco.com/stacks/ . The '816 and Forth are mentioned plenty, but it's really about 6502 stacks.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?