Redrawing a window, which is partially overlapped by other windows, is done in a recursive way. It is splitted into sub-rectangles, and for each rectangles a full redraw is done (all low level routines can work in a clipped square area). Once you have such an algorithm everything is quite simple again. The apps don't care about such problems, they don't even know, if the window is visible or not, and if yes, in which way.
So you have it easy when implementing the screen split.
So by example, if an app lets says PAINT a big rectangle, and just was overlapped another window in the middle of this big rectangle, Symbios cares all about the geometrics and ordered just paint the wanted area, and that for each wanted area.
Symbios has support for full screen, realtime apps?, like for video games in full screen without losing performance?
How about the memory layout for apps?
For painting individual stuff inside a window you use a bitmap control (also known as "picture box"). Here you can paint everything you want in 4 or 16 colour mode. At the end it's only a rectangle area which has to be updated on the screen.
Full screen mode is supported as well, have a look at the screen saver or the SymShell command line interface, which can be switched into fullscreen.
Regarding the performance: That depends on what you want. It's still a Z80 system, so if you want, you can shut down the OS for a while and take over the whole CPU. If you still want the multitasking to be active you have to accept, that the user may run some other tasks at the same time, so you won't have 100% CPU time.
An app always runs inside a full visible 64KB area, where only 1KB is reserved for OS stuff. Additional memory can be reserved as well.
Any intentions to resurrect MNBIOS?
so, from the point of view of the memory layout is looks like DOS2 does, how about the executable file loading?
It will load up to those 63KB?
How about the OS calls, it is a jump table?, a single entry point?
Have you done some Getting started docs for ASM developers?
---->>> Here you can paint everything you want in 4 or 16 colour mode ? <<<-----
What? I saw those screenshots it looked like it is screen8 (256colours).
PD: About the MNBIOS it is in standby from a while ago, as I focused the interest in other things, as "another OS" is not the more popular thing, overall between a bunch of old wolves dealing directly with all the hardware as if it were food and sex.
But, someday ... who knows.
What I mean about Realtime capability, is not the thing of just disable the interrupts, in the ISR sure is wanted services like KB decoding, maybe mouse handling, but as any MT OS that each process can have a priority level, low , normal , high or realtime, (windows by example), so when a process has the focus & have the realtime priority, the task switcher cares that no other app gets a time slice in the cpu.
With that, full performance games can be done under the O.S. rules, and is how Windows games works, they request realtime or high priority, todays normaly is high priority, but in old days with slower cpus some of them requested real time priority.
Now there is two categories of process, system, and user, app with realtime status + focus don't dissable system processes, because with that works, all I/O accesses.
It is a simple rule, but open the door to good games.
The core part can be up to 63K which will be loaded by the OS. More code/data has to be loaded after the application has been started.
The OS is reachable via several RST calls.
The task scheduler of the SymbOS microkernel supports 9 process priorities (0-8, 8=low; used by the idle process, 0=high; used by the kernel process; apps usually use priority 4, system tasks use priority 1). If a process with a high priority use most of the CPU time, these ones with a lower one won't receive any until the higher one is finished. I didn't give names for the different priorities yet, but it's like you described.
"Timer" processes can be called the real "realtime" ones, as these get guaranteed CPU time every 1/50 second.
The core part can be up to 63K which will be loaded by the OS. More code/data has to be loaded after the application has been started. (as DOS2 but it is up to 53K, so symb is better because don't deal with preexisting MSXBIOS stuff).
The OS is reachable via several RST calls. (great, short, quick, nice).
The task scheduler of the SymbOS microkernel supports 9 process priorities (0-8, 8=low; used by the idle process, 0=high; used by the kernel process; apps usually use priority 4, system tasks use priority 1). If a process with a high priority use most of the CPU time, these ones with a lower one won't receive any until the higher one is finished. I didn't give names for the different priorities yet, but it's like you described. No, system & user processes are not just different *level* of a scale of priorities, it is categorizing for avoiding an user process be able to override O.S. service processes, needed by example, for disk I/O processing. If there is not a categorizing, a called HIGH priority can be waiting an eternity waiting for disk I/O. Ofcourse the high priority process can command to release the cpu when waiting for I/O to be completed, but that is a fix and in modern OS is done anyway for get more performance, but, is not the correct way to have that only path <--- corrected.
"Timer" processes can be called the real "realtime" ones, as these get guaranteed CPU time every 1/50 second. <--- ah, maybe this one is how you call system processes, or maybe you are referring to ISR hookable code.
I will apreciate a good getting start document programmer manual.
You do know there’s [ quote ] markup right? 
The core part can be up to 63K which will be loaded by the OS. More code/data has to be loaded after the application has been started.
(as DOS2 but it is up to 53K, so symb is better because don't deal with preexisting MSXBIOS stuff).
The OS is reachable via several RST calls.
(great, short, quick, nice).
The task scheduler of the SymbOS microkernel supports 9 process priorities (0-8, 8=low; used by the idle process, 0=high; used by the kernel process; apps usually use priority 4, system tasks use priority 1). If a process with a high priority use most of the CPU time, these ones with a lower one won't receive any until the higher one is finished. I didn't give names for the different priorities yet, but it's like you described.
No, system & user processes are not just different *level* of a scale of priorities, it is categorizing for avoiding an user process be able to override O.S. service processes, needed by example, for disk I/O processing. If there is not a categorizing, a called HIGH priority can be waiting an eternity waiting for disk I/O. Ofcourse the high priority process can command to release the cpu when waiting for I/O to be completed, but that is a fix and in modern OS is done anyway for get more performance, but, is not the correct way to have that only path <--- corrected.
"Timer" processes can be called the real "realtime" ones, as these get guaranteed CPU time every 1/50 second.
<--- ah, maybe this one is how you call system processes, or maybe you are referring to ISR hookable code.
I will apreciate a good getting start document programmer manual.
Bat to The Future - This is an under development game, and is not yet finished. Started as a Symbasic project, but was converted to assem for speed reasons within the symstudio IDE. At the moment i'm concentrating on the next release of Symstudio (Now called Unify), which will alpha released and shown at Nijmegen later this month. Bat to the Future will be finished in a few months, once Unify reaches a 1.0 release.
Unify is a heavily upgraded version of symstudio. Hopefully Edoz will start testing this week.
Since last week I am working on Network support for SymbOS. This is (first) based on the DenYoNet ethernet card (Wiznet W5100), which is quite cormfortable to use. Here is a first screenshot...

...showing the test utility, which is loading the homepage of NYYRIKKIs website WWW.MSX.FI .
The driver is designed in a way, that it's very easy to exchange the used hardware by dividing the code into three layers. The low level code is for accessing the W5100 hardware directly, which is different between the MSX and other platforms like the CPC. The mid level is for working with the hardware, which is the same for all systems using the W5100. Other hardware like the ESP8266 Wlan module or own TCP/IP stack implementations/Obsonet would require another midlevel code. The high level is for managing the connections and communicating with the processes, which want to do networking.
All TCP routines seem to work now, now it's time for UDP to make DNS and DHCP possible.
Amazing work! But, for what I understand, you are not using the UNIAPI, right?
It would be great if more Denyonet are produced.
No, it's a little bit different from Konamimans code. The network driver is running as a "Daemon", which is an own background process in the multitasking environment. Applications can send messages to it, like asking for opening a new connection, sending data to an already opened connection etc. They will also receive messages from the network daemon, if there is new incoming data or if the status of a connection changed etc. This makes it possible to run multiple applications at the same time, which all can have open connections (though the maximum number of connections is limited to 4 due to the limitation of the W5100/DenYoNet, but it should still be ok
).
The code itself is different, too, as it's divided into these 3 layers. So there is no direct access to the W5100 registers with LD r,(IX+x) and something like this, as on the CPC the W5100 is not memory mapped but I/O port based, and so the access code has to be abstracted. This is blowing up the code a little bit, but at the end it shouldn't be slower, as the important thing - the data transfer - is still running at the maximum speed.
