On Thu, 17 Mar 2005 02:16:39 -0600, Jim Leonard <trixter at oldskool.org> wrote: It's also been converted to the Amstrad CPC and the C64, it looks quite good. Dan

Er, minicomputer, before I get lots of pokes and prods. Open mouth, insert Dr Pepper. -- ---------------------------------- personal: http://www.armory.com/~spectre/ -- Cameron Kaiser, Floodgap Systems Ltd * So. Calif., USA * ckaiser at floodgap.com -- Dihydrogen monoxide -- the leading environmental pollutant! www.dhmo.org ---

Cameron> Thanks for the suggestions -- maybe I should be a little Cameron> more specific. Jim L suggested Contiki, but actually Cameron> Contiki is precisely *not* what I'm after (even though it's Cameron> a quasi-multitasking environment for small systems); it's Cameron> unsuitable for the task because: Cameron> - source is in C (I should have specified I want assembler Cameron> if possible) - it needs more than 16K to be useful anyway - Cameron> it doesn't have a "classic" feel to it - it's not Cameron> preemptively multitasking You didn't explain why it has to be preemptive. If possible, non-preemptive is often better. If you need pre-emptive, an RTOS is likely to be a good choice. uC/OS is one; there are other open source RTOS. Typically they will be in C. So compile it -- by hand if you don't trust the compiler. paul

On 18/03/2005, at 7:04 AM, Paul Koning wrote: Anyone who's used a Macintosh before OS-X might want to disagree here. Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au Melbourne | "If soccer was meant to be played in the Australia | air, the sky would be painted green"

Rumor has it that Eric Smith may have mentioned these words: True... [snip] It isn't! ;-) Joking, but having used a pre-emptive multitasking OS on an 8-bit machine for a lot of years, which ran better / more stable, heck - quicker than Win31 on a 386, one may be able to see why I have a bit of a jaundiced eye towards cooperative multitasking systems... ;-) Which is why I'm still kind of surprised no-one's brought it up yet: OS-9 for the 6809 CPU. Granted, it's for a micro and not a mini (but heck, so's winders, MacOS & AmigaOS) but there is a freeware version out with source and everything (and the last updates were less than a year ago, and there's nightly CVS snapshots available) here: http://www.nitros9.org/ Originally, NitrOS9 was a set of patches to use the enhanced capabilities of the 6309 under OS-9 Level 2 - but they've basically rewritten the OS around the patches, not only for Level 2, but even backported it to Level 1, which will run on the coco 1 and 2, and possibly even the Dragon. Oh, and it's even rather unix-like! ;-) I had OS-9 Level 1 easily running in 24Kbytes (altho 64K RAM was necessary in the computer), and IIRC just to see if I could do it, I had a bootdisk that shoehorned it into 16K, but there were precious few modules in memory for that. It's written in 6809/6309 assembly, so that might get you started... That's kinda like saying "Sword swallowing can get you into trouble if you're not careful..." ;-) Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers zmerch at 30below.com What do you do when Life gives you lemons, and you don't *like* lemonade?????????????

Eric Smith wrote: This much is true. For one, race conditions are practically non-existant if it's designed right. And a cooperative kernel lends itself to architectures that don't support interrupts. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/

Paul wrote: True. You wouldn't believe how many times I've seen other engineers trying to set the priority of their task higher than those of other tasks just because they have some vague idea that their task is "important", rather than any understanding of actual relationships between the tasks. A good rule of thumb is that in the absence of a rational basis for one task having a higher priority than another, all tasks should have the same priority. Far too often a person's intuitive idea of what the relative task priorities should be is wrong. Eric

On 18/03/2005, at 12:36 PM, Paul Koning wrote: I suspect a lot depends on how much control over the total environment you have. For a small embedded/RTOS you probably have (or at least should have) total control. If you don't you're depending on the writer of one (or more) of the processes "doing the right thing". Now probably they will try to do this, but any subtle bug may lead to one of the processes failing to relinquish the CPU and then "bad things happen (TM)" - this was the typical Mac experience. Of course, having said that, Macs worked remarkably well for many years. Are the risks in preemptive scheduling just ones of complexity? I guess that it is much harder to "prove" that this type of scheduler is going to to the right thing at the right time. I know that, for example, the scheduler for VMS has gone from a couple of pages of assembler to something like 75 pages of BLISS! Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au Melbourne | "If soccer was meant to be played in the Australia | air, the sky would be painted green"

It was thus said that the Great Huw Davies once stated: The biggest risk is still CPU starvation. The AmigaOS (at least up through 1.3) used a simple round-robin with priority scheduler. Dead simple to implement but can lead to process starvation (three CPU bound tasks, two at priority 100, the third at 0---the one at 0 would not be scheduled; the other two would switch off though). But generally speaking the two styles of multitasking just shove the complexity around---in cooperative the complexity is handed off to the application programmer, while in preemptive, it's handed off to the systems programmer. -spc (Hmmm ... Linux 2.0 has 1800 lines in sched.c, while 2.4 has only 1300 ... )

jimmydevice wrote: I should mention that all interrupts were handled with an ISR and then defered to a high priority process The internals: A linked list of process control blocks, each containing the register state of each process, The process priority (bid), the accumulated bid, a countdown timer ( preempts all bids at T-0) and a link to the next process control block. Sorry, St Patricks Day... ;-0 Jim Davis.

Huw> On 18/03/2005, at 12:36 PM, Paul Koning wrote: Huw> Are the risks in preemptive scheduling just ones of complexity? Huw> I guess that it is much harder to "prove" that this type of Huw> scheduler is going to to the right thing at the right time. I Huw> know that, for example, the scheduler for VMS has gone from a Huw> couple of pages of assembler to something like 75 pages of Huw> BLISS! It's not so much the correctness of the scheduler itself that's the issue. The real issue is the correctness of the decisions it makes. That depends primarily on the settings you assign to the processes. For complex schedulers (like VMS) it also depends on all the various dynamic adjustments it makes, which are typically very hard to understand. The result is that you often end up with a system whose dynamic properties are not known and perhaps not even knowable. For a timesharing system, that's not so bad; if it doesn't act right, people just grumble a bit. For a real time system, it's a bigger issue. If somet things don't get done on time -- or not at all -- the result can be that the system doesn't do the job it was designed to do. A real world example (names omitted): a decade or so ago, there were routers whose designers thought that the job of a router is to forward packets. So they made packet forwarding the top priority. Unfortunately, that's a misunderstanding. The job of a router is to have an up to date view of the network topology, and to communicate that to the other routers. Its *secondary* job is to forward packets. What happened is that a routing loop formed -- which is normal. But there were enough packets circulating in the routing loop that the forwarding process was taking 100% of the CPU time. So the route update process didn't run, so the routing loop was persistent rather than transient as it is supposed to be. Result: the network was down until the operators could shut down enough routers to break the loop. To avoid this, you have to realize that routers are real time systems and that every process in it must be guaranteed a non-zero fraction of the system resources. (That's the absolute minimum -- a better answer is to set specific non-zero lower bounds on the per process resources.) This is why, in a previous life when I built routers, I used single priority non-preemptive schedulers (sometimes as simple as the "for loop" one I showed) to schedule the router functions. The result was that they were stable and reliable and operated correctly under all loads, including overloads. paul

Huw Davies wrote: Or any DOS-based version of Windows (ie Windows 1.0/286/386/3.x/95/98/ME). These were all "round-robin" if I am not misremembering... (I certainly remember one application crashing and not passing control to the rest of the services well enough :-) -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/