I do not understand a (many ) thing ...

When somebody made a storage device in the past, it was an EXDOS EXTENSION device.

There is the IDE card from Zozosoft, what can use IDE devices like HDD,IDE-TO-CF Memory Card,or anything ... and this IDE card has an EXDOS EXTENSION interface towards EXDOS.
There is the cartridge SD card what is an EXDOS EXTENSION device, too.
Saint's combined SD solution was planned to be an EXDOS EXTENSION device, too.
And the original floppy drives, as well.

So when this OS would be ported to the EP, every single hardware device have to get a new driver, towards SymbOS ?

Afther that, making a hardware device will require making two drivers, one to EXDOS and one to SymbOS ?

Probably it left out from the "news":

http://enterpriseforever.com/hardware/exp1-and-exp2-pinouts/msg34847/#msg34847

Somebody can easily get an internal 512K/1024K expansion from saint, what can be assembled in place of the original 64K expansion.

, they have quite different scopes.

Yes, you are right, only it is strange ...

When one thinks of the EP then thinks of EXOS, too.
Everything was bounded to EXOS.
But with SymbOS we may have choice, using EXOS or SymbOS.

Multi - boot EP ...

I think the best thing if the EXOS still accessible under SymbOS.

Probably Zozo you make the same mistake I did.

With SymbOS there is NO such thing that EXOS. EGI is an extension of EXOS. SymbOS (probably) replaces EXOS.
SymbOS uses the hardware, and all of it. SymbOS (probably) will not check memory segments allocated by EXOS. Its a standalone and different thing.
SymbOS's applications runs inside SymbOS. SymbOS is not a Current Application Program to EXOS, or probably only at its bootup.

So that would be a different effort to make SymbOS to keep EXOS intact.

I think the best thing if the EXOS still accessible under SymbOS. Can be opened EXOS window like as EGI
Then normal Enterprise programs can be started from SymbOS file manager.
Warm reset feature also only can be used when the system segment preserved.
If this is only work with memory expansion, don't problem. Todays very easy add megabytes to the Enterprise

That was what I suggested too. Let's SymbOS loader to allocate as many memory segments as it can, and what it can allocated, it's marked to be used by SymbOS, and already used segments (system segment, page 0 ...) would be untouched. There are few problems though:

* it won't run on base Enterprise-128 in this way, as SymbOS needs 128K RAM minimum. Remedy: if SymbOS loader can allocate more segments than 128K in sum, let's use only those, otherwise let's use the whole RAM. Still, if video RAM is needed and not enough segments can be allocated, that's a problem (possible solution with enough RAM expansion: let's SymbOS to copy already used segments like system segment into a normal one, and copy back on request but it would be a problem with warm reset)
* since SymbOS uses direct hardware access, the state of eg WD chip can be undefined and not what EXDOS would expect
* normal enterprise programs could be launched though, but it would need to have Enterprise-128 specific part in SymbOS userspace or at least some "loader" ... Also then SymbOS would need to re-free some segments for the app?
* it wouldn't be so much possible easily to return to SymbOS from Enterprise app, maybe the warm reset sequence but basically it means "restart" thus other running apps are lost inside SymbOS
* of coure multitasking is disabled during executing Enterprise-128 app, basically it would mean to pass the full machine back to EXOS from SymbOS

I think it's even more easy (but that is also hard!) to write a new EXOS which allows some kind of "multitasking" even if it only means to "switch" between running apps, and not running them in parallel as with true multitasking OSes

:help maybe could run ...

but :dir will interfere with the hardware device handling of SymbOS ... so ... probably such thing is not easy ...

Still I can't see the advantages especially compared the difficulties it would mean to implement this. Even running a simple help command would require to partly switch back normal EXOS memory (system segment, etc) and shutting down SymbOS IRQ, RST vectors etc so basically stop its working while command is running. Otherwise it would be problematic that SymbOS uses the RST vectors EXOS would also use, and other problems like this. It someone only wants to use SymbOS as a "file browser" to run non-SymbOS (like Enterprise-128) applications, it's a bid odd to do It would be still possible to develop an OS like entity sitting on the top of EXOS with even multitasking (from EXOS side it's a single app) but it wouldn't be SymbOS, and really "hard" multitasking nature would be problematic because of the EXOS mono-tasking nature (thus a disk I/O would hang multitasking - but anyway, pseudo OSes - like Win95 was, basically it's something runs on the DOS halfly not a stand-alone OS - as far as I know it still used BIOS to acces floppy drives thus making serious hangs when dealing with floppies ...).

Yes, probably it is the closest to the truth ...

One intersting though VERY MAD project: implement a new, EXOS which runs as a SymbOS application Especially having IS-BASIC as SymbOS app would be funny Normal EXOS programs using strictly EXOS functions may work somehow (though I no idea how to cure problems like conflicting the usage of RST vectors), but even just trying bother B0...B3 ports to do memory mapping would cause a crash I guess Or such.

Regardless of SymbOS, I had the odd idea to really write a new EXOS (not just "binary patching" existing, original EXOS) which is as much compatible with the original as possible but introducing new features like having muliple programs as same time and allow to switch between them (well, with enough RAM it's not so impossible, some just may need to backup/restore system segment and page0, etc, I am not sure if it's really possible). But this is again a project which would not to worth to really do, as the this is hard to do ...