A Question About Multitasking

[airship]

From the Wikipedia article on the C128:

Multiple zero page and CPU stack locations can be defined by twiddling some bits in the C128's MMU, which theoretically would make multitasking a possibility. In practice, the lack of hardware memory protection would create a difficult-to-manage environment in which to run a preemptive kernel. Moving the zero page does not affect the CPU's built-in I/O port, which always remains addressable at Addresses 0 and 1.

So... I understand about hardware memory protection being a problem. But has anyone come up with an environment that uses the 'move zero page and the stack' MMU trick to enable 'pretty good' multitasking?

[airship]

I know I'm beating a dead horse here.

Hydrophilic came up with his great little N-Progs hack in this thread: http://landover.no-ip.com/forums/index.php?topic=1234.0
which also has a link to an old Transactor article that addresses the same problem, but also ran into the non-protected memory problem. I'm just wondering if this is the best that can be hoped for.

I know LNG (LUnix) also makes a stab at multitasking. I'm just not clear on what's the best case scenario.

[BigDumbDinosaur]

From the Wikipedia article on the C128:

Multiple zero page and CPU stack locations can be defined by twiddling some bits in the C128's MMU, which theoretically would make multitasking a possibility. In practice, the lack of hardware memory protection would create a difficult-to-manage environment in which to run a preemptive kernel. Moving the zero page does not affect the CPU's built-in I/O port, which always remains addressable at Addresses 0 and 1.

<Chuckle>  I'm the one who wrote that Wikipedia comment about the MMU and multitasking.

Without hardware memory protection, any pre-emptive kernel is going to run into the potentially deadly problem of keeping one process from stepping on another process's memory space.  Naturally, the kernel itself will be at risk for such contretemps.

As far as trying to run BASIC in a multitasking way, the principle issue to be resolved is what to do about all of the BASIC stuff that runs in common RAM (that is, page zero, page 2, the runtime stack, etc.).  Each time context was to be switched you'd have to not only save the processor state somewhere, you'd have to copy the aforementioned memory ranges to safe storage.  You can, of course, relocate pages zero and one, but only at the cost of having the relocation addresses swapped into page zero and one space.  So it becomes more of a real swap than a save for later operation.

Also, since a context switch would normally be triggered by an IRQ, a potential nightmare will ensue, as there isn't enough RAM in RAM 0 to store all that crud and still have room for the currently executing program.  Using RAM 1 would be more than a little difficult, as cross-RAM transfers inside of an IRQ handler are very tricky -- you can't use the kernel calls for that purpose.

The basic problem (no pun intended) is the 128 simply isn't organized in a way that will support task switching.  I played around with it a lot back in the day and never did come up with a satisfactory solution.  It all comes back to memory protection and finding enough room to store the variables associated with each idle process.  On a system designed to multitask, this would be accomplished with some sort of swap device.  Other than an REU, there is no way to emulate a swap device with the C-128.  Have fun with this puzzle!

[airship]

Other than an REU, there is no way to emulate a swap device with the C-128.

So why not use an REU? I'm okay with a multi-tasking solution that uses a common (albeit not ubiquitous) and even 'official' piece of CBM-branded hardware.

If you said 'REUs welcome,' what could you do? Could you solve the problem?

[commodorejohn]

Yes, an REU would make it much more feasible, I think, but if you're going to do that, you might as well go all-out and simply swap whole processes into and out of memory (except for maybe a common "message space" in case applications need to communicate with each other.)

Keep going on this, BDD. I'm interested to hear more about this from someone who understands it better than I do, since it coincides with a (non-CBM) project I've been tinkering on for a while.

[BigDumbDinosaur]

Yes, an REU would make it much more feasible, I think, but if you're going to do that, you might as well go all-out and simply swap whole processes into and out of memory (except for maybe a common "message space" in case applications need to communicate with each other.)

Keep going on this, BDD. I'm interested to hear more about this from someone who understands it better than I do, since it coincides with a (non-CBM) project I've been tinkering on for a while.

If the process being swapped out is BASIC, you also need to swap out RAM1 to protect the variables.  Although the REU is very fast by Commodore standards, the real time performance would be such that a context swap would be perceptible to the user.

The DMA controller in the REU is theoretically capable of 1 MB/sec transfer rates.  Therefore, an idealized transfer time would be 62.5 milliseconds to read or write either of the two RAM banks.  In practice, the ever-present problem of repeated bank switching to alternately expose RAM and then the I/O block (which is where the REU hardware is visible) would substantially add to the swap time.  I don't see it as a practical thing to do on the 128.  But don't let that stop you from trying!   

[brain]

LUnix did multitasking on the 64, and BOS (Craig Bruce) was a proof of concept multitasker for the C128.

Jim

[airship]

The DMA controller in the REU is theoretically capable of 1 MB/sec transfer rates.  Therefore, an idealized transfer time would be 62.5 milliseconds to read or write either of the two RAM banks.  In practice, the ever-present problem of repeated bank switching to alternately expose RAM and then the I/O block (which is where the REU hardware is visible) would substantially add to the swap time.  I don't see it as a practical thing to do on the 128.  But don't let that stop you from trying!   

So, you might need a full 1/10 of a second to swap out one RAM bank for a M/L program, or 2/10 of a second to swap out both for BASIC. Sounds to me like that's reasonable for a task-switching system on a 2 MHz machine.

As commodorejohn says above, it makes sense to keep a page or two of RAM somewhere as a "message space" so programs can communicate with one another.

This suggests a kind of modular programming environment where each module - BASIC or M/L - would do one job and do it well. To be perfect, it would require a resident task manager that would essentially be a kind of scripting language. This would set parameters and call programs in the order in which they need to be run. It would also have to manage REU space and load in modules from disk to the REU begin with, and load and store later modules if they all wouldn't fit into the REU at once.

What could this be used for? Hmmm... How about fractal generation by one module which would generate a sequence of frames in memory, and a separate module that would display them as an animation? You could create small M/L modules, each of which would be optimized to create a certain type of fractal, to enable storage of the maximum number of frames in RAM/REU. The display program (perhaps in BASIC) could then be a generic slideshow/animation module that would display any kind of graphics in memory. That's just one half-baked idea. I know there are many more possibilities.

A perfect task manager would allow options to enable/disable 40/80-column modes, set up graphics screens (resolution, interlace, etc.), enable use of unused 80-column RAM for storage, memory and REU management, program loading and execution sequencing, disk file management, etc. I want environment variables, too. 'Standard' modules like a file manager and text editor would be nice additions. The key would be creating a system where all the modules respect one another and work well together. But that's the trick, isn't it?