Hi,

now I think it's a good idea to start an own thread for this project.
First for your information: SymbOS is currently an operating system for the Amstrad CPC computers:
http://www.symbos.de
SymbOS provides true multitasking and a complete Windows XX like GUI. It supports up to 576KB Ram for data and code execution (each application can address up to 63K in one piece) and includes a FAT12/16/32 implementation, which made it possible the first time for the CPC to access MS(X)-DOS discs native or hard discs with up to 128GB.

A week ago SymbOS CPC Release 1.0 has been published, and now I want to port it to the MSX2. This seems to be the other great plattform, which is able to run this operation system in quite a good way.
There already have been discussions in two other threads:
http://www.msx.org/forumtopic5436.html
http://www.msx.org/forumtopic6197.html

Yesterday I started to work on the MSX with the help of BlueMSX and I already managed to port the micro kernel. So it seems to be more easy and fast, as I first expected.

But now I definitely need your help. The following other parts of the operating systems include system dependant code, too:
1.) screen manager (=low level screen output routines)
2.) device manager (=keyboard, mouse, realtime clock, screen mode and colours)
3.) low level part of the file manager (=disc and hard disc sector read/write routines)

I will try to do the work for 2.) today by myself.

The difficult thing will be 1.):
@Sonic_aka_T, PingPong and others: Thanx for your offers to help me here! I hope this part will be manageable.

I wrote a description, which routines I need. You can download it here:
http://www.symbos.de/files/screenmanager.zip

So who would like to write some of the routines? If you need additional information and for any other questions you can write here or email me:
jmika at prodatron dot net.

Regarding 3.) I will write something later, too, but this part shouldn't so complicated like the screen routines.

I hope SymbOS MSX can become reality and want to thank everyone, who already helped me with information in the past.

CU,
Prodatron

One to get you started. It should still be optimised. For one it used the slow pixel accurate fill and not the byte accurate one if possible. But hey, it's a start.

PNTBOX:
	ld 	(LMMV.C),a
	ld	a,$80
	jr	nc,$+4
	or	3
	ld	(LMMV.CM),a
	push	hl
	ld	hl,(winxbg)
	ex	de,hl
	or	a
	sbc	hl,de	
	ld	de,(winxps)
	jr	c,.off_left
	add	hl,de
	push	bc
	jr	.set_left
.off_left:
	add	hl,bc
	push	hl
	ex	de,hl
.set_left:
	ld	(LMMV.DX),hl
	pop	de
	add	hl,de
	or	a
	ld	bc,(winxps)
	sbc	hl,bc
	ld	bc,(winxln)
	sbc	hl,bc
	jr	c,.set_right
	ex	de,hl
	sbc	hl,de
	ex	de,hl
.set_right:
	ld	(LMMV.NX),de
	
	pop	hl
	ld	de,(winybg)
	or	a
	sbc	hl,de	
	ld	de,(winyps)
	jr	c,.off_top
	add	hl,de
	jr	.set_top
.off_top:
	ex	de,hl
	add	ix,de
.set_top:
	push	ix
	ld	(LMMV.DY),hl
	pop	de
	add	hl,de
	or	a
	ld	bc,(winyps)
	sbc	hl,bc
	ld	bc,(winyln)
	sbc	hl,bc
	jr	c,.set_bottom
	ex	de,hl
	sbc	hl,de
	ex	de,hl
.set_bottom:
	ld	(LMMV.NY),de

	call	WaitForVDP
        ld      a,36	; start at DX
        out     (99h),a
        ld      a,91h
        out     (99h),a

	ld	bc,$0B9B
	ld	hl,LMMV
	otir
	ret

LMMV:
.DX:	dw	0
.DY:	dw	0
.NX:	dw	0
.NY:	dw	0
.C:	db	0
	db	0
.CM:	db	0

WaitForVDP:
        ld      a,2	; select S#2
        out     (99h),a
        ld      a,8Fh
        out     (99h),a
.wait:
	in	a,(99h)
	rra
	jr	c,.wait
        xor 	a	; select S#0
        out     (99h),a
        ld      a,8Fh
        out     (99h),a
	ret

PS I hope it's free of bugs

PSS Yes, yes, the comments were lost somewhere

That's it?? Wow!! And it looks logical! I will try it soon. The VDP appears to be great! I am getting more and more impressed by the MSX.

Btw, Sonic_aka_T already asked me for clipping support routines. So I will add the routines used for the CPC soon. The thing why I didn't include them yet is the fact, that in my routines Y coordinates are limited to 8 bit. In general SymbOS (=the system independant desktop manager module) can handle 16bit for X and Y, but as the CPC can't display more than 200 lines (usually) the internal routines always work with 8bit for Y.
Ok, for the MSX normally it's the same, so it makes sense to use the same routines.

So please wait for an update. Btw, I think, many of you are from the netherlands? Unfortunately in the past I did the mistake to comment most of my source codes in german. Would this be a problem? (usually I can read most of the dutch language, too ) In any case I will try to translate as much as I can to english, if needed.

CU,
Prodatron

You may be a bit less impressed after checking this.

The visible screen only exceeds one byte when using interlace. But I have hopes that someone will write the same stuff for v9990 so we can enjoy 640x400.

German comments should be no problem for most Dutchies. Don't know about the visitors from the rest of the world though.

Very good site! Currently I didn't find a summary of all VDP commands. Do you have a link for that?
Or is everything said on this site?

http://www.work.de/nocash/portar.htm#vdpregisters20h2ehmsx2videocommandregisters

Now that I'm awake again, a few comments about the piece of code. The VDP access part can't be interrupted. I didn't put DI/EI's there because I have no clue how you will deal with things like this in your system. Also, I keep the status register set to 2 while waiting for any VDP commands to finish. That would be messy if interrupted by a standard ISR.
Also, it is a bit of a waste to wait for the VDP on a multitasking environment. Maybe something smarter can be done for this.

Thanx again for the information. Now I have a much better understanding about the possibilities and the usage of the VDP.
Currently I am excited about it, as it looks like a nice 2D accelerator I just hope, that the VDP itself is not too slow. I will make some tests by myself now to get an impression about the possible speed. Maybe I need to rethink something.
As an example now I think it could be optimal to store the complete font 12 or 16times in the VRAM to have a version for any pen(0-3)/paper(0-3) combination. But when plotting proportional text, the VDP has to do a lot of very small pixel copy operations (one for every char). I hope that it will still be fast enough...

Quote:

As an example now I think it could be optimal to store the complete font 12 or 16times in the VRAM to have a version for any pen(0-3)/paper(0-3) combination. But when plotting proportional text, the VDP has to do a lot of very small pixel copy operations (one for every char). I hope that it will still be fast enough...

use TPSET copy, you store fonts once on "0" background and then copy them wherever you like

Do you mean setting bit3 of the command register 2E to 1? Is the VDP in transparent mode as fast as in normal mode? If yes, that's a good idea, as then I would only need to store it 6 times in memory (3 times with colours 1-3 and background=0; and 3 times with colour 0 and background 1-3).

Hm, but on the other hand I would need to fill the background first...

Quote:

Is the VDP in transparent mode as fast as in normal mode?

transparent mode is fast as any other logical copy i.e. like a (dead) snail

on the other side, fast copy is limited to bytes, so, in sc5, you cannot use it when x
coordinate is odd, or the x coordinate is even but the width is odd

even worst in sc6, where you need x be multiple of 4

Today I ported the device manager module to the MSX successfully with the exception of the RTC. Does anyone have a hint, what is the easiest way to detect a present RTC?
Currently I don't know, if there is any standard proportional mouse for the MSX available. Any hints here?

Sorry, again I asked too fast again. I will write/read the "scratch" byte in block 2.

Quote:

transparent mode is fast as any other logical copy i.e. like a (dead) snail

Hm, any idea how many micro seconds it (more or less exactly) takes to copy a 8x8 pixel block inside the VRAM with logical copy?