Oh, really? Well, I think as faster the task switching is, as faster a task can update the screen or react on user input or on messages from other tasks. Maybe the problem is the idle task, which takes the not used CPU time (it does nothing else than increasing a counter, and this makes it possible to have the "CPU load display" in the task manager). On a 50Hz task switching base, it would probably grab a lot CPU time which better could be invested in faster task switching which results in faster reactions.
I will do some tests on the CPC now, if breaking down the frequence from 150 to 50 would have any consequences.
Prodatron / SymbiosiS

you don't use the HALT instruction for idle mode?

Processes can be in idle mode (they release the CPU time when there is nothing to do) or even in sleep mode (they are not executed until they receive a new message from someone else). But what do you mean with the HALT instruction? I think, it just would waste CPU time, as the CPU is doing nothing until the next interrupt appears.
In SymbOS the multitasking is based on priorities:
- first all processes of the highest priority will be executed.
- only if they all release the CPU time by themself (if a process is working too long, it will be interrupted by the OS, so it didn't release the CPU time by itself), the processes with the next priority will be executed
- the idle process has the lowest priority and will only be executed, if ALL processes released the CPU time by themself.

That means, that on a 50Hz switching base the idle process will work nearly 1/50second until the next process can be executed, if before all processes released the CPU time by themself.

I will test these two things:
1.) is there a problem with the reaction time of the tasks, if switching is at 50Hz?
2.) does 150Hz waste much CPU time compared to 50Hz because of the higher amount of task switches?
If 1 is false, it will be fine for MSX
If 2 is false, I can stay with 150Hz on the CPC, doesn't matter what the result of 1 is.

Cheers,
Prodatron

if wast or not too much depends on the quality of the code.

50hrz is just fine.... for switchs between threads but not for switchs between events... (I must suppose that you don't assign a task to every event able to be in the GUI (like assign a thread to each button or something)....

Quote:

if wast or not too much depends on the quality of the code.

I really need help with this one, Fly. What the heck did you want to say here?

If you askme all the GUI tasks (like redraws or any event) is divided between the appls that owns GUI's objects... and is a task of the appls. to see if there is events waiting on the objects that owns.... and then to reply to the events of those using the appl. thread's time....

that is the more logical for every O.S. incl. windows and VB programming way.

greetings

Quote:

Quote: if wast or not too much depends on the quality of the code. I really need help with this one, Fly. What the heck did you want to say here?

sorry CORRECTION right now

if IT wast or not too much, THAT depends on the quality of the code.

I'm sorry, Fly. Still don't get it.

Anyway, there's suddenly a new OS frenzy race going on in the MSX scene! I like it!

Hi Flyguille,

sorry, I still didn't understand you exactly.
In SymbOS the GUI is controlled completely by the GUI process (called "desktop manager" ) . If the user clicks something (maybe a control inside a window) the desktop manager process sends a message to the process, which owns the clicked GUI object. The process will receive the message and can react. As an example it can redraw something. To do this, it sends a message back to the desktop manager, that it should do the redrawing (only the desktop manager can draw something).
That's it, hope I could explain it in a clear way.
Btw, MNBIOS looks very impressive and I liked to study the documents!

Cheers,
Prodatron / SymbiosiS

I understand perfectly how you did it... that is another way to do that.

but, the use of messages between tasks makes delays.... I thought other way for MNBIOS.

in MNBIOs is a event buffer on the instance of the objects... in others words... the GUI hasn't a thread by itself.... it not needs one... the GUI is just a main library where is possible to hung objects codes.

saving time....

and the kernel hasn't a GUI... just standarize the place for it and how to use it... that opens it like a puzzle....


but i must admin ... I am stuck in real life stuff and family stuff...

Speed isn't that much of an issue in my opinion when it comes to message events, as they are fairly rare occurences in processing terms, so how they are handled isn't that much of an issue. And Symbos doesn't produce the variety of events that Windows can, as you'd probably expect. Not that I'm saying its slow, becuase it isn't

The messages though are invisible to the coder (unless they want them to be). When an event happens it jumps straight to the necessary code if it exists. The piece of code below is based on three objects/gadgets which are scroll bars holding a value between 0-15 each representing Red, Green and Blue (all created with the form editor). Any click or change of value in these bars will call the code, and effect the palette. Its pretty darn simple to use really.

;**** Code called on event occuring on RedScroll
Function RedScroll_Event
call CombineColorScrolls
ENDF
;**** Code called on event occuring on GreenScroll
Function GreenScroll_Event
call CombineColorScrolls
ENDF
;**** Code called on event occuring on BlueScroll
Function BlueScroll_Event
call CombineColorScrolls
ENDF
;****
Function CombineColorScrolls
ld a,(RedScroll_Value)
And %1111
ld l,a
ld a,(GreenScroll_Value)
rl a ;Multiply 2
rl a ;Multiply 4
rl a ;Multiply 8
r1 a ;Multiply 16
And %11110000
ld d,a
ld a,(BlueScroll_Value)
And %1111
Or d
ld d,a
ld e,0
call SyDesktop_ColSet
ENDF
;*************************

Obviously if you need to test for a specific event happening on a object you can test A

Function OkayButton1_Event
cp DSK_SUB_MMCLICK
jp Middle_Mouse
...
ect

But what happens, if the GUI library is drawing something for a process, and suddenly the process is beeing interrupted (because of the multitasking) and another process receives the CPU time and also wants to draw something? Then it calles the GUI library, too, but the library is already in a "froozen" state because of the other process. Or do semaphores protect the library from "double calls"? Or do you add the instruction for the library to a buffer? (but that would sound nearly like the message system)
Btw, the overhead generated by messages is very low compared to the time, which is needed, if something is plotted to the screen, so it has no effect in SymbOS (on CPC).
The GUI is not a part of the kernel. The kernel is only responsible for multitasking/process handling, memory management/ram banking and the process messages, nothing else. The GUI is a service of the desktop manager process (one of many processes), which application may use, if they want. Other applications may use nothing, and other ones may use the text shell:
http://www.symbos.de/files/symshell1.gif
(this text shell can run in full screen mode or in the desktop - then it uses the desktop manager again, but the application inside the shell doesn't know about that, it just knows about STDIN and STDOUT).

Cheers,
Prodatron

Quote:

But what happens, if the GUI library is drawing something for a process, and suddenly the process is beeing interrupted (because of the multitasking) and another process receives the CPU time and also wants to draw something? Then it calles the GUI library, too, but the library is already in a "froozen" state because of the other process. Or do semaphores protect the library from "double calls"? Or do you add the instruction for the library to a buffer? (but that would sound nearly like the message system) Btw, the overhead generated by messages is very low compared to the time, which is needed, if something is plotted to the screen, so it has no effect in SymbOS (on CPC). The GUI is not a part of the kernel. The kernel is only responsible for multitasking/process handling, memory management/ram banking and the process messages, nothing else. The GUI is a service of the desktop manager process (one of many processes), which application may use, if they want. Other applications may use nothing, and other ones may use the text shell: http://www.symbos.de/files/symshell1.gif (this text shell can run in full screen mode or in the desktop - then it uses the desktop manager again, but the application inside the shell doesn't know about that, it just knows about STDIN and STDOUT). Cheers, Prodatron

what happens? nothing... it works.

why?... because the libraries by its nature are multisession.... why? because they don't share data segments & any of the three stacks between threads...

if the library needs a common data for to organize tasks it is a internal work of them.-

Ok, that sounds good.

I just wonder how such cases are managed:
- Process #1 draws a sprite inside window #1, that has focus. During the drawing process it will be interrupted.
- Process #2 gets the CPU time and puts window #2 to focus. This window will overlap window#1 partially.
- Process #1 can continue, but a part of the sprite is now overlaped by window #2. Does the interrupted sprite drawing routine now knows, that suddenly an other object is overlaping it?

If yes, I am not sure, if all the overhead to handle this would be less than the SymbOS message overhead. In SymbOS every resource (desktop, disk drive etc.) is managed by only one process, so there are no problems with competing tasks, as the responsible task is working all request one after the other, which makes everything quite easy.

Cheers,
Prodatron

speed executing itself isn't a problem...
The Lag between the event generated (a click or a key press) and the appl. reacting is a problem.

if it depends of a message passed from a thread to other.... that means that can be some times a cycle of delay... needed to that the thread of the GUI is executed and the thread of the appl is executed then.

I not knows about symbian but in MNBIOS one cycle is 1 seg... being executed high priority threads first then the appls threads careless of the modality of being executed. (rythmic mode or continous mode or freetime mode)... but that is another agent.

in MSX the only one interrupt by sure is 50hz... and the best way to handle user events is on the interrupt... with the procedures hunged on it, (keyb mouse etc.), the best and direct way it from that place to fill a event's buffer of the target object.

and then let to the appl. to check for events just reading a property.