Well, I think gfx9000 is not important. It's the less important thing about Symbos now.

Yours,

What's important and what's not wasn't really the debate tho, 9958 vs gfx9k was.. and I don't think v9958 is very practical for all this compared to the gfx9k., (not to mention that the gfx9k is way faster also!)

I assume apps wouldn't 've need to be rewritten for g9k support (g9k with 4 color-modes that is), so, supporting g9k would not be that daunting a task..

Go to the important stuff first.

actually,
also having 16 colours without breaking CPC compatibility can be an issue,
so, go to disk I/O, general msx2 support and to msx code optimisation
before moving to more exotic HW

Well UVY modes in v9958 atleast is a bit complicated for GUI because the chrome value is shared between two pixels pairs and odd. So that will limited all the GUI about how to place the windows or the size of windows in values / 2 and how the controls fits inside.

Yes the most important thing is to keep cross platform compatibility IMHO

I think supporting more than 256 colours is probably hoping too much, and don't forget that 256 and 16 colour will have to be a fixed palette as the all applications have to share the palette

Plus the conversion from 256 or 16 colours into 4 although a few bit shifts would look ugly, and probably means seperate set of graphics for each mode. And this causes lots of other issues with regards to memory usage

Lets Just let Prodatron get it working properly before asking how it can work better.

You're right Trebmint

I hope it's not a big problem to support the GFX9000 and the VDP9958. The only part of the low level screen routines, which needs to be adapted, should be the graphic output. I will need to introduce 16 and 256 colour graphic controls, but I am not sure about more colours. Currently I am also not sure about the palette, if it should be a fixed one or a definable one. If it's not a fixed one, the application, which has the focus window, needs to redefine the palette all the time.
I surfed around on the Sunrise website and tried to find some documentation. There I found "WiOS". Seems to be a complete new multitasking operating system, too. What's about this one?
Btw, will someone here take part at the RetroEuskal ( www.retroeuskal.org ) in Bilbao at the end of july? I will be there from saturday to monday.

well, IIRC, WiOS is only for v9990 VDPs.

I am still worried about how symbios handle the memory and its expandability because that will define if a O.S. is sucessfull or not.

Well, there is some like "I am thinking" because all the parts that you needs realy I already have done on MNBIOS!.

hmmmm

Hello Prodatron: two questions:

1) Is vdp time shared between processes? (So for example if a window of process ID#1 is repainting it's button and a task switch occour in the middle, is another window of another process able to repaint? How is this resource coordinated? In cpc there is no problem, because the CPU is handling grpx operations and CPU can be interrupted almost any time...)

2) Is I/O IDE access shared in multiple tasks? How is DISK I/O access blocking? In MSX BIOS is blocking at ALL!

Quote:

Btw, will someone here take part at the RetroEuskal ( www.retroeuskal.org ) in Bilbao at the end of july? I will be there from saturday to monday.

Well, Bilbao is near 2 hours by car from my home, but I will not be able to go to Euskal Encounter or Retroeuskal. Retroeuskal crew are very good people, so enjoy it

Also, talking about parties, there is a party here in Pamplona called Navaparty where I go only with my MSX, as most of the people here knows , so having there Symbos will be really great. And also at the scene-party where I knew SymbOS last year: bcnparty.

Yours,

Salva

Hi PingPong,

in SymbOS every hardware resource is always managed by only one task:
- the graphic output is only done by the so called "Desktop Manager" task
- the disc/harddisc access is only done by the "File Manager", which is a sub module of the "System Manager" task
All tasks are communicating with messages between each other. So maybe task#1 sends a "please redraw my window" message to the desktop manager. Task#2 may send "please open a new window for me" message to the desktop manager, before the desktop manager got CPU time and could do the job for task#1. In this case there are two messages for the desktop manager in the queue, and it will just proceed one after each other. The same is for the "file manager".
This means, that you have never problems, when different tasks want to access the same resource. The responsible task just gets the different orders one after each other from the message queue. Using messages instead of sub-calls sounds easy and works perfect

Regarding disc I/O: I think I will need to disable the interrupts while loading one sector. It's the same like on the CPC. I also have to disable the interrupts while loading a sector from the sunrise IDE, because it uses memory mapping, but I hope, it won't affect the system, as loading a sector is done very fast.

I hope I will be able to upload a video later this evening. I just want to fix two bugs before.

@SPL: Well, I hope, I will meet some other MSX guys there. Are there usually some?

just like MS windows!

Prodatron, sure that you will find MSX guys there

prodatron> did you try this on a real msx already? I think the emulators may exaggerate the speed of small VDP copies a bit.

@Edwin: Sonic_aka_T told me, that it has never be a problem to send bytes to the VDP without checking the status, if the VDP is ready for new ones. So I hope, that rule counts for every MSX2 or higher.
@Flyguille: I don't know anything about Windows (I never programmed for Windows). I think this methode should be a good one: simple and logical.