@Spl: Every app can have up to 63K memory in one piece. Of course it can reserve more, but then it can't address the additional ram directly.
@Flyguille: What is a "TIMMER"? The controls are described in the "desktop data records" document. You are right, on the CPC I always need only one OUT for remapping the memory, on the MSX I need 2-4 OUTs. I just hope, that it will not slow down the whole thing too much, but it doesn't seem so. The MSX version works with the same banking configurations like the CPC version with the exception of the file manager.
@NYYRIKKI: Yes, FAT12 is also implemented. That's what you see on the last screen shot, the directory of a FAT12 hd partition. I am very happy, that FAT is the native format of the MSX! Amstrad has this more primitive CP/M format, so it was good luck, that I already implemented all the FAT stuff, otherwise the port would be much harder.
Most applications will run directly on the MSX. I didn't modify MineSweeper and won't need to modify most of the other ones. There will be some issues, if they manipulate the graphics and of course if they access the hardware directly.
Currently the standard controls can only have 4 colours. That makes the applications portable for every screen mode very easy. But I will introduce 16 and 256 colour graphic controls, so that you can also have more colours in the future.
@PingPong: Well, the CPC Z80 has 4MHz "official", but only 3,2-3,5MHz in practice because it is stopped sometimes, when the video hardware needs to access the RAM. The I/O access to the MSX vram usually is as fast as CPU memory access, if you work with larger blocks (OUTI/OTIR is as fast as LDI/LDIR). In general ALL MSX low level screen routines in SymbOS are faster than the CPC ones! So it seemed to be just a rumour, that the MSX has a disadvantage here, for me the VDP is a GREAT advantage!

Very nice to see such quick progress! Three days to implement the graphics routines is quick considering it was your first use of the MSX2 VDP.

When you finished the port, it should be well worth it to make a second set of gfx routines for the Graphics9000 expansion cartridge. It has more choice in resolution and colour depth and it's a hell of a lot faster than the v9938. Usage is roughly the same, except that it's even less complicated. (no need for specialised high speed version).

Do you actually have plans to make use of the 16kb pages for memory management? It could reduce usage a lot for apps that don't need more than for instance 16kb.

Edwin: Without yours, Sonic_aka_T, PingPong and others help, that wouldn't be possible in 3 days, and I also could use some surrounding parts of my CPC routines and the experience with them.
The Graphics9000 sounds interesting! As soon as the first version is completely running I will check it out and also screen 5, 7 and 8.
Regarding 16K applications: Will be hard to optimize. There may run 64K apps together with the 16K ones, so I still may have to switch more than 16K. First I would like to measure the CPU load with the task manager to be able to say, how much CPU time the advanced ram banking of the MSX wastes.

Prodatron the best is to do all highlevel GUI in true-color
and then to reduce it to the low colour of the screenmode in use... ofcourse that will slowdown a bit but is better and EXPANDABLE.

TIMMER is a object that is set on Forms (windows) that can execute code by itself when its countdown reach ZERO. That means that the GUI must support EVENT based on TIME-triggering and not just KB and mouse or other I/O event.

A true color based GUI would be too slow and too memory consuming for a 4MHz 8Bit system IMHO. Will you do this for MNBIOS?
Some kind of timers are already implemented, but yes, the range of different supported events can still be extended.

But the question that's on everyone's mind is: "when will we have DirectMSX support?"

DirectMSX... lol!

in certain way DirectMSX is already implemented in the MSXBIOS
jjajaja

it is just a basic standard graphic library saving the no 3d support.

Quote:

A true color based GUI would be too slow and too memory consuming for a 4MHz 8Bit system IMHO. Will you do this for MNBIOS? Some kind of timers are already implemented, but yes, the range of different supported events can still be extended.

well MSX has 16Kcolours VUY!

but the convertions WILL slowdown A LOT.

a convertion from real-color to 256c is just some AND & OR operations.

It will wast MEMORY ONLY with PICTURES or graphics....

drawing just LINES, and chrs it not wast anything.

Sorry for bothering you again with a screen shot so late at night:



But this will be the last one for the next time I think
Most of the operating system and the applications seem to run now - in a more or less ROUGH way. So I have to do a lot of tuning work now and I shouldn't forget about the FDC stuff.

Thanx again to all people here for the help, motivation and support! It's great to work with you on the MSX!

CU,
Prodatron / SymbiosiS

Looking extremely cool

Hey, what do you need to get SymChat working? Any support you need in the emulator?

OMG Prodatron, you sure know how to keep the tension here high
Btw, do you already have a beta-testing phase in sight?

Quote:

Looking extremely cool Hey, what do you need to get SymChat working? Any support you need in the emulator?

What about ObsoNET support?

Very impressive!
Will it be possible to have CPC/MSX interoperability
for applications running in SymbOS?

I mean the same application working on both systems?

Quote:

Most applications will run directly on the MSX. I didn't modify MineSweeper and won't need to modify most of the other ones.

Seems that Prodatron has developed a very competent API capable of abstract all the hardware.

As NYYRIKKI says, I feel that this time we've a mature OS in our hands...