@KimmoK

AmigaOS is not a soft RTOS either. When the CPU is under load, all bets are off. Soft RTOS still give guaranteed response times for asynchronous events when the system is under heavy load. AmigaOS, traditionally does not.

If you want to try a "soft" RTOS, get a copy of QNX or similar.

_________________
Doing stupid things for fun...

@Karlos

It seems that I've had different AOS then.
(with and without executive, actually executive cause some peviation of the near RT behaviour if it is allowed to modify priorities on the fly. But it can be also used only for automatically setting of process priorities @ system restart.)

Last edited by KimmoK on 14-Jan-2010 at 04:17 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

Quote:

CPU load does not affect AOS at all. (except if priorities are not set properly, same with every RTOS)

Fixed priority scheduling is the issue there, not "wrong" priority values.

You want AOS to be a RTOS, since you think it deserves the label but that's not how the real world works. Fast and responsive under normal conditions is the correct description. RTOS, soft, hard, squidgy or whatever is not the correct description.

_________________
Doing stupid things for fun...

@Karlos

Fixed priorities is one of the core reasons of why AOS is pretty good in near realtime (=soft realtime) needs.

One can really give a very high quarantee that higher priority task is processed before the lower priority one. That does not ever work in windows and other similar OSs (no matter how you set priorities, any task can eat the whole CPU when too much is done in kernel space & highest priority).

((It is not an accident that AOS has been used as the model for some RTOSs.))




Ok, I think now I got the proper "term": AOS is pretty good in near realtime (=soft realtime) needs.


*************
My examples for minimum RT needs to become a usable desktop OS.
- volume control must be accessible without delay (usually it takes 5+ seconds on fast Windows systems)
- printer queue access without delay (on windows, the printing happens before I can access the print manager, on linux I still look for the driver... )

Last edited by KimmoK on 14-Jan-2010 at 04:56 PM.
Last edited by KimmoK on 14-Jan-2010 at 04:24 PM.
Last edited by KimmoK on 14-Jan-2010 at 04:23 PM.
Last edited by KimmoK on 14-Jan-2010 at 04:22 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@thread

you are so far off-topic! If the world wouldn't be a globe you would have fallen over the edge...

_________________
Bite Me!

@brotsalami

XCore has hard realtime capabilities. So it's not 100% offtopic.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@vidarh

Hello Vidarh

You mentioned, that Apple has a ridiculous price/performance-ratio.

Well, when I compare all (and I mean ALL) the relevant technical aspects of a computer, then Apple isn't expansive at all.

If you wanna do a comparison, then please show us facts, instead of blaming Apple.

Just post the facts of your well-priced windows-box. I will put down the facts on the Apple-Side.

_________________
Sometimes we give people a lot of credit just because they're writing nice sentences even if it isn't adding up to much.

@Hyperionmp

I just got to thinking, PCI and Zorro have a vendor/device ID concept, so the system knows which driver to associate with which board. Is there something like this for Xorro slot, so if I make a plugin board, and someone else makes a plugin board, the OS knows which driver to pick to avoid problems? I just hope that we won't have different drivers colliding, or software-only use of the Xcore conflicting with a board driver, etc.

As you suggest things are pretty tightly integrated that this has all been thought through, and it should be easy to deal with via expansion.library.

_________________
All glory to the Hypnotoad!

@Hans

Quote:

Hans wrote: ... I like the idea of having this chip on the motherboard, and a slot that provides access to I/O, and would allow more to be connected. It sounds like the perfect hacker's port for all sorts of hardware projects.

So if I'd build - lets say - a steam operated model steam locomotive and wanted to completely remote control it (including transferring a video stream of the track ahead from a small cam at the front of the locomotive to the control unit) on a model railway, the AmigaOneX1000 should be my choice to control everything?

I would need I/O lines to control e.g. water level in the boiler, water level in the tank, injectors, boiler pressure, boiler temp, gas level in the tank, the throttle, backward/forward drive control, the brakes and a small camera etc. ...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@billt

Quote:

billt wrote: @-pekr- Here's some things that people are already doing with these chips: ...

They even have a project named "Amino":

Amino

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

I'd say for purposes like that it far more reasonable to use some USB-breakout-board (*) and a cheap webcam. Far less chance of frying your mobo (and you can use cheaper HW too).

(*) those boards come only with Win-drivers, but writing an USB-class for Sirion and/or Poseidon might proove less hard than writing a driver to make the XMOS behave like you wish. With a bit of searching one might even find other board that are either fully documneted and/or have open-source drivers.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@KimmoK

I try to explain the problem to you.

The task scheduler is where good in AmigaOS and it has always been, it was never the problem.

The problem is whit how AmigaOS deals whit internal system tables,

if you have two programs trying to add a record in a table the first program will turn off multitasking and chanage things and then trun on multiasking when its done, to avoid corrupt data in tables.

if AmigaOS where to be a RTOS, then AmigaOS most garanti that no program is never interupted, and it does not.

AmigaOS4 does provide Semaphore's, what Semaphore does is provide a way to lock only one table; so only programs that access that table gets effected, programs can ask if table is ready to be used if not do other stuff as well, the problem whit Semaphore's in AmigaOS is that it can not be retro fitted.

AmigaOS4 provides also Mutex its basicly a better Semaphore.

Last edited by NutsAboutAmiga on 08-Feb-2010 at 01:52 PM.
Last edited by NutsAboutAmiga on 08-Feb-2010 at 12:35 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS