(Flame suit on) Isn't it funny how we can miss the point and drift of
    into a tangent (Flame suit off), one has to ask the question of what
    the operating system is for, and is there any other way. Remembering
    that the requirement is to not use interrupts. If this is so then the
    programmer will have to spend much time counting instructions in order
    to control the task switching.

ok.  Here is a basic lesson in multicasting.  I'll use a C-like syntax.

This is part 1 - a very basic multitasking setup.

Your most basic form of multitasking looks something like this:

scheduler() {
    while (TRUE) {
        task1();
        task2();
        task3();
        task4();
         :
        taskN();
    }
}

Obviously, this places rather severe constraints on how each task must
operate.  They have to be well behaved and not sit in loops waiting for
something to happen.  They can't run for too long even if stuff is
happening.  And they have to return (at their "top level") when they're
done.  Still, even in this simplistic environment, you can accomplish
useful things.  Consider:

    task1() { /* Uart receiver */
        while (uart->status & RXRDY)
            char_enqueue(uart->data);
    }

    task2() { /* Uart transmitter */
        char c;
        while (uart->status & TXREADY) {
            if (NULL != (c = char_dequeue()))
                uart->data = baudot2ascii(c);
        }
    }

    task3() { /* flash an LED at slow rate */
        static boolean savedbit;
        boolean thisbit;

        thisbit = (0 != (timerreg16() & 0x0080)); /* get HALFSEC bit */
        if (thisbit != savedbit)
            toggle_led();
    }

There - you now have a system that reads data from a uart, translates the
character set, and transmits the translated character back out, and blinks
an LED at a timed rate, all while continuing to do task4() through taskN()
as well.  Not bad.  The limitation is that the sum of the execution time of
all the tasks can not exceed the time it takes the data link to fill up the
uart's receive fifo, or you'll lose data.  If the link is slow, the fifo is
big, and the processor is fast, you can do quite a bit.  You also can't take
so long that task3() will miss the bit change, and if you don't call it at
a fairly frequent interval, people will notice an uneven duty cycle.

There are a couple of things to notice here.  First is that the tasks
themselves have no "permanant" context other than what they save for
themselves off in what are really global resources.  The stack (such as
it is) is shared by all tasks.  The global resources really ARE global,
and a badly behaved task can easilly screw up everyone else.

Still, I have a hard time imagining anything much more complex than this
operating on the small PICs.  Shucks - the entire CHIP doesn't have as much
"context" as the register set on a modern CISC chip :-)

The rest of multi-tasking is mostly a matter of allowing each task to have
more in the way of private context, more flexibility in giving up control to
"the scheduler", more control of deciding when it needs to be "woken up",
and more protection from the actions of badly behaved tasks.

More in part 2.

BillW