Welcome, Guest. Please login or register.


Author Topic: SymbOS (Read 617343 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #45 on: 2014.October.12. 22:22:10 »
When my Music Box Player play music whil you write your program in IS-BASIC, then the EXOS are mono or multi tasking? :-)

The EXOS function calls use very few bytes in the page 0. EXOS interrupt system just needed for the built in devices.
If you attach new "virtual" user devices for replace KEYBOARD and etc then these can be drived from your interrupt system and EXOS interrupt system can be override.

Anyway typing DIR in EXOS window not to important function :-)
The most important are the warm reset, and possible to start "legacy" Enterprise programs. For do this just needed to preserve the EXOS allocated memory. With lot of memory don't problem.

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: SymbOS
« Reply #46 on: 2014.October.12. 22:37:25 »
Like Rutger Hauer in Blade Runner, I've seen....... inside the SymbOS apps a CPC emulator. That's how the alien OS interacts with the machine, use the EP only as a shell and runs an emulated copy at the upper layer. It's like a scifi movie....it's horrible but brilliant....

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: SymbOS
« Reply #47 on: 2014.October.12. 22:39:57 »
When my Music Box Player play music whil you write your program in IS-BASIC, then the EXOS are mono or multi tasking? :-)

Hehe, it depends how you count that :) if it can read/write files while you read/write files in IS-BASIC, it's quite that :) Otherwise it's an easier solution like to put something into the interrupt handler, and not so much a true multitasking between two (or more) equivalent applications with the same possibilities to do in parallel.

Quote
Anyway typing DIR in EXOS window not to important function :-)
The most important are the warm reset, and possible to start "legacy" Enterprise programs. For do this just needed to preserve the EXOS allocated memory. With lot of memory don't problem.

If it's only that to start "legacy" apps and shut down SymbOS meanwhile (as it can't run in "EP mode"), it wouldn't be a big problem I guess. It's about the same problem like running Windows 3.1 on an 286 class computer: it has some kind of multitasking between its own apps, but if you need to run a DOS (not native to win3.1) apps, it would require to pause original win3.1 functionality at least. Note, I didn't used windows "too much" :) but something like this I remember about.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: SymbOS
« Reply #48 on: 2014.October.12. 22:47:22 »
It would be some kind of OS virtualization, isn't it ?

SymbOS host EXOS guest ... :)

It would be called as "para-virtualization" as it's not full. It's the limit of the CPU (Z80) as of course it's not designed for this purpose :) What would be needed to "intercept" I/O instructions and pass the control to the hypervisor to allow to "emulate" the I/O instead of really doing that which is only allowed for the hypervisor (which controls the guest virtual machines). It's basically the scheme of modern virtualization environments. However, if Z80 gets opcode IN/OUT etc, it has not got a capability to doing something different. With modern CPUs some opcodes are defined as "privileged" ones and executing them in certain modes would cause to generate an "exception" the OS should handle. By contrast, para-virtualization is also interesting, it's like implementing an OS with some modifications to run on top of another component. A real full virtualization at the other hand is capable of running OSes designed to run on the "real hardware" without even knowing about the virtualization (in modern virtualization softwares, there are some crosses, like hypervisor specific guest OS drivers but it's only for performance reasons ...).

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: SymbOS
« Reply #49 on: 2014.October.12. 22:59:04 »
I think running MS/DOS commands in the  CMD.EXE window is virtual on win98 and up.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: SymbOS
« Reply #50 on: 2014.October.12. 23:08:50 »
I think running MS/DOS commands in the  CMD.EXE window is virtual on win98 and up.

It is. But not the same with Win3.1 :) The key difference that 80386 CPU knows about the "vm86" mode which allows to emulate real mode. In 286 there was (16 bit) protected mode and real mode, but a protected mode OS couldn't run a real mode task too much because of the totally different interpretation of segment registers (they holds selectors in protected mode). 386 knows about 32 bit protected mode as well, and plus, the virtual real mode, or whatever it's called. Win3.1 was basically a 16 bit "OS" (well not even fully OS and it requires DOS) so it could not use the virtual mode capability of 386+ CPUs. Windows systems starting with '95 are partly (but not fully) 32 bit ones. My DOS emulator (dosrun) ran on Linux with the help of vm86() syscall of the Linux kernel and it emulated privileged instructions by software.

Anyway, win 95/98 etc stuffs are still runs on the top of DOS and requires DOS, even if it's not advertised too much. With some simple hack it was possible to exit to DOS instead of switching off the computer :) At least this is what I remember visiting some friends, personally I haven't used Windows OSes so I can be even wrong, though I am still interested in OS internals even if I didn't use them :D Maybe with windows2000 they are totally different OSes and their kernel are partly from the "NT" family of Microsoft operating systems, they can be much more named as "operating systems" as before when another OS (DOS) would be needed to run. I've driven my friends mad to name win'95 in its time as "protected mode DOS function extender with GUI" and not an "OS" :)

SymbOS is more an OS than even win'95 was as it does not need another OS under it :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #51 on: 2014.October.12. 23:16:25 »
Yes, Win 9x and ME just a DOS GUI :-)
2000 are the new name of NT 5.0, XP are NT 5.1 and 5.2, Vista are the 6.0, 7 the 6.1, 8 the 6.1, and the 8.1 are the NT 6.3...

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: SymbOS
« Reply #52 on: 2014.October.12. 23:20:44 »
You are right, SymbOS is really an OS, on the other side EGI is like WIN31, a front-end(win31 worse, as
EGI doesn't make pretensions of be an OS) .

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: SymbOS
« Reply #53 on: 2014.October.12. 23:29:23 »
You are right, SymbOS is really an OS, on the other side EGI is like WIN31, a front-end(win31 worse, as
EGI doesn't make pretensions of be an OS) .

Yes, and it's not a problem, EGI is a nice idea to have "GUI for EXOS", nothing wrong about that! I am just interested what EXOS 3 would be ... :)

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: SymbOS
« Reply #54 on: 2014.November.02. 11:33:17 »
After lgb was showing me his impressive "hack"-port of SymbOS for the Enterprise, he finally convinced me to begin the Enterprise port right now! So during the last two days I started to explore the fantastic world of this very cool Z80 machine with lgb's great help! TBH I am really impressed again!
Now I did the first step and ported the low-level-screen routines to the EP, which was of course very simple, as I only copied the CPC routines and optimized the line jumps.
Thanks to Zozosofts post here I was also able to set up the LPT for 320x200x4 or 640x200x2 screens very quickly, and this is the first result:



The next step is to port the kernel, with which I will start now.
@lgb: Thanks a lot again for your brilliant help!! I will reply soon!

CU,
Prodatron

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #55 on: 2014.November.02. 11:54:04 »
Hello Prodatron!

In the Hungarian SymbOS topic we make a long brainstorming about how possible run the SymbOS on the Enterprise.
But without inside informations these are only just a guess.
I think more practical discuss with the original author :-) You know the SymbOS details we know the Enterprise details :-)

One most important question the memory paging:
If I understood right the documentation: because the limited features of CPC the memory paging done by 64KB blocks. Only exception the first (bank 0) which are can mixed 16K segments of other banks. This bank is used by the SymbOS kernel.
The memory paging can be controlled with one I/O port.
It is right?

But how working SymbOS paging on 4x16K paging machines? If I know right the MSX and PCW also use this paging method.
The paging routine have a table for each 64K banks for which 4 value needed to send to the 4 paging ports?

Because the Enterprise can be expanded very flexible, many different expansion exist, this means many different address locations. We think the best way at the boot the SymbOS loader ask the RAM list from the EXOS and fill up a memory banks table with the segment numbers. Only problem if it is problem: this is need a 16x4=64 bytes table. Is a enought space for this in SymbOS kernel? Or already exist because the MSX/PCW?

One more question: can be support more than 16 banks = more than 1024k memory? Todays very easy to put megabytes to Enterprise :-)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #56 on: 2014.November.02. 11:56:57 »
and this is the first result:
Wow! :smt038

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: SymbOS
« Reply #57 on: 2014.November.02. 13:42:11 »
After lgb was showing me his impressive "hack"-port of SymbOS for the Enterprise, he finally convinced me to begin the Enterprise

Ah, wonderful! :) Sorry about "badgering" you too much, but it seems it helped :-)

Quote
port right now! So during the last two days I started to explore the fantastic world of this very cool Z80 machine with lgb's great help! TBH I am really impressed again!

Well yes, EP is interesting machine both in its hardware and software (EXOS/EXDOS/etc) too, in my opinion.

Quote
The next step is to port the kernel, with which I will start now.
@lgb: Thanks a lot again for your brilliant help!!

You're welcome, I am proud if I could help, and of course it applies for the future as well!

How hard is to port the kernel? As far as I imagine, since it's microkernel, it's not so much hardware dependent (as those machine dependent components resides in other "processes" like video manager, etc, not the kernel itself), but maybe mainly the memory layout/paging and interrupt handling which is the major work of porting just the kernel, I mean.

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #58 on: 2014.November.02. 14:10:36 »
Quote
and this is the first result:

Yes, we will have SymbOS, cool-cool-coooooool!



Otherwise I just made a PS/2 keyboard interface to the EP (It's a work in progress thing, I will fine tune it, but I can type or play already with a PS/2 keyboard),
and I would like to make a PS/2 mouse interface, too.

Enterprise already uses mouses for some things, like PAINTBOX or EGI through a common software interface, called "mouse.xr".
(Actually, it is the file name of a program became the de facto EP mouse API and mouse software driver implementation for the boxsoft mouse interface hardware, which is a NEOS mouse hardware interface to the EP.)

So my PS/2 hardware mouse interface will be compatible (in the end) with the mouse.xr, and PAINTBOX and EGI will be usable with my PS/2 mouse interface.

But I would like my PS/2 mouse interface hardware to be compatible with SymbOS, too.

Could you, please give me some information how I can make my mouse hw compatible with SymbOS ? Through what software interface can I do that ?
What kind of software driver have I to write for beeing compatible with SymbOS ?

Probably SymbOS will not want to use the mouse.xr interface managing its mouse, will it ?

Or are these questions too early in this phase of the porting progress ?
« Last Edit: 2014.November.02. 14:14:11 by Z80System »
Z80 System

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: SymbOS
« Reply #59 on: 2014.November.02. 14:25:24 »
In the Hungarian SymbOS topic we make a long brainstorming about how possible run the SymbOS on the Enterprise.
Ah cool, I have to read the 10 pages now with the Google translator! :)

One most important question the memory paging:
If I understood right the documentation: because the limited features of CPC the memory paging done by 64KB blocks. Only exception the first (bank 0) which are can mixed 16K segments of other banks. This bank is used by the SymbOS kernel.
The memory paging can be controlled with one I/O port.
It is right?
That's correct!
On the CPC we talk about "blocks" (16K) and "banks" (64K). Each bank contains 4 blocks.
Now you have the following possibilities:
- show first 64K only
- switch any 16K block to #4000-#7fff (the remaining visible ram is still from the first 64K)
- switch the last 16K of an other 64K bank to #C000-#fff (the remaining visible ram is still from the first 64K)
- switch a whole 64K bank to #0000-#ffff
And yes, these configs are controlled with only 6 bits (3 for the bank select, 3 for the "mode" select) on one I/O port.

But how working SymbOS paging on 4x16K paging machines? If I know right the MSX and PCW also use this paging method. The paging routine have a table for each 64K banks for which 4 value needed to send to the 4 paging ports?
It just "simulates" the CPC banking configurations. So the paging routine checks, which mode and which bank is required and OUTs the proper 16K block numbers to the 4 I/O ports. So even the MSX and the PCW memory is separated in 64K banks.

Because the Enterprise can be expanded very flexible, many different expansion exist, this means many different address locations. We think the best way at the boot the SymbOS loader ask the RAM list from the EXOS and fill up a memory banks table with the segment numbers. Only problem if it is problem: this is need a 16x4=64 bytes table. Is a enought space for this in SymbOS kernel? Or already exist because the MSX/PCW?
SymbOS already has a memory allocation table for up to 1MB with 256byte "pages". 1MB currently is the maximum, as SymbOS only supports 20bit addresses. So if ram expansions up to 1MB would always be located in the upper 1MB area (blocks #c0-#ff) that would work fine. I wonder if this is the case? (lgb already mentioned, that this is true).

One more question: can be support more than 16 banks = more than 1024k memory? Todays very easy to put megabytes to Enterprise :-)
Unfortunately not yet. It would require huge changes in parts of the kernel, and an alternative set of memory functions, as the current ones are limited to 20bit (16+4). 1024K should be enough for everyone :D :D