As far as I know, every EP OS bootup sequence have to go through all of the 256 segments,
paging those to a page (b0,b1,b2,b3), and make read/write operations on those, detecting the state of the segment.

Zozo knows the exact rules of the detection only ...

And the results will say, what is the current memory configuration of that particular EP running the OS ...

The OS have to use what memory configuration it found ...

I do not know ... I am not sure ... but I'm sure, that EXOS is not a BIOS ... It can have memory resources allocated ...

I'm sure!

FF segment is always allocated by EXOS, and can be others, too ...

Yes, but you also got it as shared segment.

For EXOS compatibility need to preserve the system data and page zero segment.
With a little trick the page zero can be moved to the system segment, then only 16K needed for EXOS.
I think this is not a problem on expanded machines.

If it is done then at the Shut Down menu can return to the normal EXOS operation.
When pressing reset button, Hot Restart can be done by SymbOS not need a full reboot.
When select normal Enterprise program in File Manager, instead a ugly error message (this is not a executable program) can ask the user: Needed to exit SymbOS for execute this EXOS program. Are You sure? If yes then the SymbOS free up the memory and start the EXOS program.

About the mouse: I think the Boxsoft type will be good for primary standard.
It is use MSX protocol, which are already supported by the SymbOS, only the low level I/O routines needed to make Enterprise version.
It is true not too many old mouse exist, but very easy and cheap to reproduce: using a existing PS/2 -> MSX converter circuits then only few 74LS ICs needed, then ready to use PS/2 to EP interface. Gflorez tried it and working.
This solution can be used with any, unmodified Enterprise without any extra hardware. (And the interface also can be used for joystick interface for autofire joys)

Thanks guys for all these additional information!
Keeping EXOS alive is a good idea on expanded systems.
After Zozosofts post about the different memory extensions I was thinking how to handle it in SymbOS. Usually SymbOS expects to have up to 16 banks of 64K one after another. Some of the extensions, which Zozo mentioned, seem to have the ram wildly spreaded around the 4MB area. But most seem to have it as one block.

Now I think that there are two possibilities how to handle it in SymbOS:

- the fast way:
The zero bank is at #fc-#ff. Bank 1-15 can be placed anywhere in the 4MB address space one after another. It is possible that in this area of up to 960K some 64K banks are missing, but the area can't be larger than 960K. With this solution memory banking will be as fast as on the MSX/PCW.

- the slow way:
The zero bank is at #fc-#ff. Each other 64K bank can be anywhere in the 4MB address space (the 4x16K blocks of one bank have to be still in one row). We have a table with 15 entries, which specify the first 16K block of each 64K bank. This solution will be slower because of the required table look-up. I wouldn't suggest using an entry for every single 16K block, as it would slow down banking too much, and it seems, that at least 64K in a row is mostly given.

So what makes more sense? I would like to choose the "fast way", but what do you think?

The problem is that access of FC-FF segments are slow, because these segments are used by NICK chip also.
I think the 2nd solution would be the best, but zero page should be chosen elsewhere if SymbOS has active code on it, for fast solution zero page should be asked from EXOS, and if EXOS returns the page(s), it should be write into the code everywhere of SymbOS where zero page is used.

I think put bank 0 to FC-FFh are very wrong idea!
Because these are the video memory which are very slow because the Nick have the access priority. In the worst case the Z80 needed to wait about 770ns for the access window. It is independent from the CPU speed. Running code from video memory will be slow, and hard to calculate the execution speed, because the Nick and Z80 running at different clock signals.
Putting the kernel to video memory will be dramatically reduce the performance

If you always want a fixed Bank 0 then I suggest F8-FBh, or F9-FCh in this case 16K video memory will be the block 3 of the Bank 0.

I think "the slow way" are acceptable compromise. Using 64K blocks table enought flexible for the most of the existing configurations.
Msx running on 3.58Mhz, Enterprise 4Mhz, it is compensate the little slower banking. And todays exist a 10Mhz Turbo Enterprise

The fixed bank 0 why needed? It is not possible the loader program put the actual segment number to inside code where it is needed? (I used this trick many time when convert old fixed addressed program to "compatible with all configurations")

Oh ok, after some more thoughts I think the slow way is the better one. And such a lookup table shouldn't require too much more additional time...

lookup_table: ;256byte aligned
db x,x,x,x,x,x,x,x,x,x,x,x,x,x

;a=bank (0-14)
LD (patch+1),a
patch:
LD a,(lookup_table)
;a=first 16K block

Add two RLCA then full 64 bytes table can used!