Welcome, Guest. Please login or register.


Author Topic: SymbOS (Read 617336 times)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #75 on: 2014.November.02. 17:11:11 »
So ... enterprise owners have to manage (in hardware) the segment mappings not to collide each other ...

And when they did that, every ram/rom segments maps (decodes) to a unique position of the 0-255 range, then OSes have to recognise and handle that ...
« Last Edit: 2014.November.02. 17:25:11 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #76 on: 2014.November.02. 17:22:39 »
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 ...
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #77 on: 2014.November.02. 17:38:28 »
Quote
Most easy way: the loader program ask the EXOS at the boot.

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

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



Of course, that it would be VERY COOL, when SymbOS can be a "Current Application Program" (CAP) to the EXOS ...

A CAP can use EVERYTHING of the hardware (I think) after it disabled the interrupts of the EXOS, and respects and preserves the allocated segments of the EXOS.

You can find information of the CAP at here:

http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/kernel/Ch2.html
http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/kernel/
http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/index.html

In this case, when SymbOS would be a CAP, the memory segment layout can (should) be read from EXOS, of course.

And it would be VERY VERY COOL, of course.

But when SymbOS does not want to be a CAP ... it has to detect memories by itself ... hasn't it ?
« Last Edit: 2014.November.02. 17:49:46 by Z80System »
Z80 System

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #78 on: 2014.November.02. 17:54:48 »
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!

Quote
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.

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #79 on: 2014.November.02. 18:00:53 »
Yes, it would be the megaultimatetopfirsclasssuperb solution ... :)
Z80 System

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #80 on: 2014.November.02. 19:48:44 »
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)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #81 on: 2014.November.02. 19:58:57 »
and the interrupt handling (no work at all)
Lgb wrote: only every 6. IRQ used from the 300Hz CPC interrupts, then only 50Hz IRQ needed. It is already done by the Nick.
Just need to handle the IRQ flags in the Dave.
If not needed any special just add these to the IRQ routine, before EI:
LD A,30H
OUT (0B4H),A

This is reset and re-enable the Video IRQ in the Dave.
Do same before enable the interrupts at first time for your program.

Anyway if you need the original 300Hz CPC interrupts, no problem, with more complex LPT you can generate more Video interrupts is one frame.

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: SymbOS
« Reply #82 on: 2014.November.03. 15:52:37 »
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?

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: SymbOS
« Reply #83 on: 2014.November.03. 16:07:08 »
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

Offline geco

  • EP addict
  • *
  • Posts: 7219
  • Country: hu
    • Támogató Támogató
Re: SymbOS
« Reply #84 on: 2014.November.03. 16:13:09 »
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.

Offline geco

  • EP addict
  • *
  • Posts: 7219
  • Country: hu
    • Támogató Támogató
Re: SymbOS
« Reply #85 on: 2014.November.03. 16:18:21 »
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

Are there any free register pair which can be used for this?
Ex BC is used on CPC for specifying registers, on EP it does not neded:

ld c,a
ld b,high(lookup_table)
ld a,(bc)

?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #86 on: 2014.November.03. 16:21:30 »
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 :oops:

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")

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: SymbOS
« Reply #87 on: 2014.November.03. 16:21:56 »
I simply do not understand why this paging stuff so important ...

Are these bank switching (paging) sequences executed very- very often ? So often, you have to consider not to be maximum flexible ?
Z80 System

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #88 on: 2014.November.03. 16:47:34 »
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!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: SymbOS
« Reply #89 on: 2014.November.03. 16:48:15 »
I simply do not understand why this paging stuff so important ...
The kernel and the applications are running in different memory banks.