That sounds to me like the best general-purpose solution, BigEd. Now we just need to figure out how to shoe-horn
everything we want to do into 64KB ... man, I can still remember a time when 64K sounded like a generous amount!

Mike

It still is—if you know how to write tight code.

BTW, the PDP-11 machine that Ken Thompson and Dennis Ritchie used to rewrite UNIX into C only allocated 64KB per user. Most of that space came from lots of swapping...
--------
Edit: I had typed 8KB. I was thinking about the PDP-7.

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

I used to use that technique quite often back in my days of writing code for the C-128. One of my "library" functions was input, which was a programmable keyboard input routine that had keypress filtration, input limiting, defaults, etc. I seem to recall a total of 12 parameters were required to "program" the function, which I passed through a parameter table:


Theoretically, you can pass any number of parameters this way, limited only by RAM. I have to say I've gotten spoiled by the 65C816's 16-bit stack and the associated stack addressing instructions. I keep looking at creating a 65C02 version of my 65C816 machine language monitor but shudder at the thought of "regressing" the code to work with the 'C02's smaller instruction set and more limited stack. Maybe some day...

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

You could even extend that parameter table idea to the mulititasking idea.

In my GeckOS operating system, I have to pointers in zeropage:
- the first one is unique within a process
- the second one is unique within a thread
The operating system switches them on thread switches.

This effectively gives local variables even in a shared memory environment. I use it for the lib6502 functionality.
It adds to the interrupt latency though.

BTW: Ed and I have recently written a small summary on multitasking on the 6502 on out google+ page: https://plus.google.com/108984290462000 ... nNiRUCTudq

André

(Edit: g+ link has a new video demo of my GeckOS multitasking OS )

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Watched the video. Pretty cool!

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

Hi,

Related to "multi tasking", there is an Applesoft extension I designed which offers a concurrent coroutine behavior with a round robin strategy to switch from routine to routine.
It is not a "true" multi tasking monitor as:
a) it is not based on some hardware interrupt signals and thus can run on every Apple 2 model with Applesoft in ROM;
b) it does not have to save the *whole stack* content upon every context switch; only a tiny part of it and a bunch of page zero locations (Applesoft context description like text pointers, line numbers, error handling settings, ...)
c) it plays with the interpreter eval loop within Applesoft: the switching occurs as the count of Applesoft instructions processed by current co routine since it was entered reaches a threshold value; however a "protection" mechanism exists which forbids such switch while a "critical" section of Applesoft code is run for instance;
d) As the co routines do not have to be designed to release the CPU at multiple points in time, the mechanism could be considered as "preemptive mutli tasking";
e) As Applesoft is a flavour of MS Basic, it can be easily ported to other MS BASIC versions whether written for 6502 archictectures or not. Briefly stated, the way it works is illustrated by the sample screen dumps below (as you can see it provides other enhancements like variable default typing according to name's 1st character, but I disgress ).

g) The mechanism described here is going to be developed further in the months to come (given my contingencies) in order to implement further abilities within the engine (like resource allocation such as the keyboard or the disk drive or part of the screen or any peripheral card).
h.1) The URL to download from is this one: http://bgilon.free.fr/apple2
h.2) The files are: "D34Peersoftv15.do" for the executable and "D34Merlin - Peersoftv15.do" for the assembly source files (Merlin format) and "ShrinkIt_1.5.2.2mg" for the hard disk image to be used with CiderPress and finally a CFFA board (compact flash interface) in a real Apple2 hardware.

HTHATS (HopeThisHelpsAsTheySay)
Benoît

The round-robin scheduler is co-operative insofar as there is no (timed) interrupt to take control away from the currently executing task. Therefore the task must voluntarily give up control. Once you introduce a timed interrupt you have a pre-emptive multitasking scheduler.

Well, I knew what I meant, anyway!

Potentially preemptive.

Unless the jiffy interrupt service routine actually has the ability to suspend one process and restart another the system remains cooperative. In UNIX, task switching may occur any time a process returns from kernel mode to user mode. That could happen following a routine kernel call (e.g., opening a file) or could occur as an interrupt service routine (any ISR, not just the jiffy ISR) finishes up and is ready to resume foreground processing.

In practice, task switching is often occurs within the foreground part of the kernel, not in the ISR. For example, if a process calls open() there may be some delay in terms of wall clock time while the disk seeks to the block containing the inode. The process is suspended for the duration (put to sleep), at which time the kernel will start some other process that is in the ready-to-run state but is not awaiting disk I/O. Later on when the inode of the file that is to be opened is accessed, the suspended process will be restarted. The goal, of course, is to maximize MPU utilization at all times.

It's not a particularly simple procedure.

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

Hmm, yes I see..

I'm doing essentially this with a cyclic executive now, and came across this topic again when looking for something else, so I thought I'd comment.

• There's a string-editing subroutine STR_EDIT_TASK that's called from MAIN_LOOP, along with other tasks. If the edit flag variable EDIT_FLAG is clear (meaning editing is not supposed to be in progress), it just exits immediately without doing anything. Next it checks NEW_KEY_FLAG for any new keypress, and exits if there's none. So usually it will be out in a total of 4 or 6 instructions including the subroutine call and return.
  
  
• If there is a keypress, it handles it (including cursor keys, INS/DEL, etc.) and exits. Enter and Esc do the same thing (turning off EDIT_FLAG) but the routine that wanted the string entry/edit sees which key was last and determines whether the user wanted it to accept the string as edited, or abort and go back to what was there before, discarding the edits. A half-dozen variables are used, plus the string variable itself. These include the current cursor position in the LCD, and type (insert or replace), minimun and maximum cursor positions (so the user can't type over parts of the display that they shouldn't), what the last keypress was, and whether or not it has been handled yet.
  
  
• The keys routine KEY_TASK is separate, and handles the scanning, debouncing, shift key (which other routines don't see, as it basically only modifies other keys' output), delay before auto repeat, repeat rate, and which keys are allowed to repeat. Timings for these are not affected by other things going on.

It's really not a very complex routine, especially with program structures, and doesn't need to operate like a state machine. Audio signals continue to be produced, uninterrupted, at a 39kHz sampling rate, based on timer interrupts. There are no stack gymnastics other than a couple of levels of subroutine-return addresses on the hardware stack.

_________________
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?

Miro Samek and Robert Ward wrote an interesting article in Embedded Systems on the subject of single stack multi-tasking in 2006. The article can be found here.

Their multi-tasking concept is not universally applicable in the sense that processor utilizing Harvard architectures may have some problems implementing the concept as presented in the article. However, a von Neumann processor like the 6502 should be able to implement the concept with little difficulty.

The basis for their multitasking concept is the use of a task that Runs To Completion (RTC). The RTC concept relies on the fact that if a task runs to completion, it may exit back to the executive/kernel using RTS or RTI. Tasks preempted by a scheduler function, are held on the common stack, and the new task is scheduled by a simple JSR.

The RTC model achieves its use of a single stack because it exits to the executive/kernel whenever it blocks. Thus, it simply does not require its stack to maintain state information. A task in a traditional multitasking environment never completes. These tasks are generally implemented as infinite loops using a while(1) {...}; construction. Because the task never completes, signalling that it no longer requires any information contained in its stack, a traditional multitasking executive must generally provide each task its own private stack.

There are some issues with the RTC model. I find that you have to be committed to building your tasks as state machines. Each task requires a static variable that defines its state. Each task requires its own dispatcher that redirects each call/restart from the executive to the appropriate subroutine, which must complete and return to the executive. Thus, state transitions are implemented within the task or the executive. If implemented within the task, the completion of a state transition should return to the executive. Handling of events is implemented in a similar manner.

Miro Samek has written extensively on this subject, and I think that his concepts warrant some consideration. The RTC concepts that he discusses in his book "Practical Statecharts in C/C++" are applicable to many problems. He takes a UML tack in presenting the material.

_________________
Michael A.

You or someone else posted a link to that recently, and I read it at that time, with perhaps 30% comprehension (probably from going through it too fast). Now a little more sinks in, but it still looks like it is intended for more complex systems. I'm doing projects with just a few tasks, up to about ten max, and the ones that don't have anything to do at the moment exit almost as soon as they're called. The SST method in the article still does task preemption beyond just normal interrupts that the processor services and then gets back to the same task it was working on; and the scheduler, looking for higher-priority tasks, will eat up at least several instructions' time each time, probably offsetting its own claimed benefits if the task list were as short as what I've been working on. I was surprised to read when we were discussing this kind of thing a couple of years ago that PCs may have anywhere from 50 to 200 tasks loaded at once though. In that situation, when you know most of them are domant an any given time, I can't imagine using my cyclic executive and calling them all up for nothing. It would take too long to make the rounds, and something that causes an interrupt and needs a task activated would be left waiting too long. That's a different world though, one I don't intend to ever get into. :p

Edit, 4/18/14: MichaelM, What you're saying in your last post there is what I'm doing, although I'm not doing the preemption and the prioritizing that the article talks about. The state-machine stuff recently got more complicated when I added menus and sub-menus and prompts for the user to enter info, and in some places a timed message of a couple of seconds has to be displayed in a 2x16-character LCD when transitioning states while also allowing the user to abort the function before the scheduled end of the message. The PAUSE function of a cooperative multitasker would be much easier to program for, but I did get the problem figured out, and the performance is still good and interrupts are never delayed more than two instructions' time.


This is one of the advantages the 65 family has over the PICs. The 65's let you have a list of JSRs that can be directly modified, not needing indirects and data tables and tests to see when you've reached the end of the table, etc.. It's quite efficient.

_________________
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?

At the risk of getting terribly off-topic, this is not unlike JavaScript semantics. This is particularly important for Firefox where large portions of the browser are in JavaScript, too.

The thing about SST, to my understanding, is that it's still interruptable by higher-priority tasks. The return from the higher priority task will then continue the lower priority one. Javascript's event & continuation handling model simply blocks until return before starting anything new.

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

There was an Firefox idea called supersnappy that would have been able to run a chrome task on top of a content task, actually, but it never got finished and it's all irrelevant here anyway.