We would be interested in how you decided to do the multi-tasking and multi-processor system. Both ideas have interested me, although I've never really done either of them. Would the proceesors be very tightly coupled, or just share some "mailbox" memory to pass things to each other (which would almost be more like a network of single-processor computers), or something in between? How many processors do you plan to have, what kinds of jobs are waiting for them, and how would you split up the work without having so much overhead that the whole idea becomes counter-productive? I'm sure there are many ways to do it.
I'm rather new to this forum. Although it's not a magazine to put articles in, anything the members can contribute, whether by short postings or by direction to a website, would be helpful to all. I hope to have a website up in a few months covering various projects, including my extensive 65c816 Forth and the home-made workbench computers I use regularly in my work.
Although I've never done real multitasking, I have an interrupt system in my 65c02 and '816 Forth that makes for easy installation and deletion of multiple prioritized interrupts and alarms. If you don't use the interrupt prioritizing, a single high-level Forth ISR runs with zero overhead. Otherwise, the ISR control loop adds a small amount of overhead.
In an experiment last week, I had audio sampling going in the background at 45,000 samples per second while remaining able to interpret, compile, or assemble in the foreground, so I could change parameters on the fly. This was accomplished with interrupts though, not multi-tasking. (Actually, the speed requirement ruled out doing it with multitasking in this particular case.)
One type of interrupt is the alarms. Alarm interrupts occur when their time comes instead of when a port needs service or something like that. This means I have to have the real-time clock running, which I turned off for the audio sampling mentioned above to avoid the jitter from the non-maskable RTC interrupt that hits every 10ms. An alarm would typically point to a Forth word (which is like a subroutine in Forth) that does a job and then usually sets another alarm for the next time the job should be done. Several alarms could be pending at any given time. The overhead to do this slows the system down by 0.034% if an alarm is pending, or 0.014% otherwise, which is negligible.
You can see how these things can do a type of multi-tasking, but they don't really have their own environments like the foreground task does. Before they return to the foreground task, they have to put the stacks and possibly other resources back the way they found them.
One of our products I designed in '93 is flying in nearly a thousand aircraft, using interrupts on a 65c02 to "switch tasks" 4000 times per second. It was developed on the home-made workbench computer.
Garth Wilson
_________________ 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?
|