SymbOS 3.1 released

[Prodatron]

The network daemon itself can't ruin the responsiveness of SymbOS as it is running as a service process with the same priority like applications.
TBH I never measured the "upload speed" but sending bytes is the same like receiving bytes. Anyway it mostly depends on the hardware and its ability to buffer incoming stuff. Todays internet participants are used to send data at speeds of mb/s and are sometimes confused, if a client is not able to handle such a speed. Then they have to re-send data again, which is sometimes causing delays even on Z80 side.

[zhulien]

I am wondering still whether we can implement a networked display like siamese system in amigaos... or x windows.  How many primitives do you need to send to draw a screen or a window or move a window and how fast can they be sent over the network.  If it works slowly over internet, it will work faster on a local network.  And given the lack of cpc gfx cards and the huge likelyhood people will have PCs or Macs... it would make a free video card for everyone.

Happy to code the server-side to render the primitives and mouse pointer on a canvas.

[Prodatron]

There are these primitives:
1.) plot rectangle
2.) plot xored dotted line
3.) plot text with fixed system font
4.) plot text with alternative font
5.) plot 4 or 16 colour bitmap
6.) scroll screen area
7.) save/restore screen area
8.) show mouse pointer

1, 2, 3, 6, 8 don't generate any significant traffic.
7 could be done on client side.
4 would require uploading the font everytime, it should be possible to cache it.
5 requires uploading the bitmap data.


So the only "heavy" thing would be 5 (plotting bitmaps).
Technically it's just a new screen driver, but I guess it has to wait a little bit, there is still enough to do for the next release...

Happy to code the server-side to render the primitives and mouse pointer on a canvas.

You mean client-side, right? (on a PC which displays the screen coming from a remote-"server"-CPC).

[zhulien]

The client server terminology i am referring to the webserver rather than the protocol server but you are also correct. If I develop most of the code that resides In the webserver happy to see how well it works with symbos?  

[zhulien]

There are these primitives:
1.) plot rectangle
2.) plot xored dotted line
3.) plot text with fixed system font
4.) plot text with alternative font
5.) plot 4 or 16 colour bitmap
6.) scroll screen area
7.) save/restore screen area
8.) show mouse pointer

1, 2, 3, 6, 8 don't generate any significant traffic.
7 could be done on client side.
4 would require uploading the font everytime, it should be possible to cache it.
5 requires uploading the bitmap data.


So the only "heavy" thing would be 5 (plotting bitmaps).
Technically it's just a new screen driver, but I guess it has to wait a little bit, there is still enough to do for the next release...

Happy to code the server-side to render the primitives and mouse pointer on a canvas.

You mean client-side, right? (on a PC which displays the screen coming from a remote-"server"-CPC).

Can you give me a list of operations that a typical screen would have from the clear screen to a fully rendered one and I can use that as a test to see how fast I can make it before you make any changes at the SymbOS end.  

Eg.
Set resolution 1920 x 1080
Clear screen 
Rect 100, 1820, 100, 980
SetMouseCursorPos 200, 200

Of course beyond the initial screen resolution and clearing 99% of changes would be a stream of alterations. Except the mouse cursor... thst would update as often as you send that preserving rhe background  and yes, window moves and caching definitely possible on the webserver. And an infinite number of displays too if you want per cpc, a guid based ID.

[XeNoMoRPH]

[XeNoMoRPH]

[zhulien]

is that a patch or a rewrite or a port?

[XeNoMoRPH]

is that a patch or a rewrite or a port?

a quick demo of what we can do with the sprite/canvas system in Quigs.

[Prodatron]

We are trying to have a 4 colour version finished until next weekend.
In general it is independant from the colour depth like all GUI apps, but modifying the canvas after it has been displayed for the first time requires updated tiles as well.

[retro space]

Would this run on my P2000T with 2080kB RAM and HiRes graphics card (256x256x16 colours)?

[Prodatron]

Would this run on my P2000T with 2080kB RAM and HiRes graphics card (256x256x16 colours)?

Hi Retro Space, I wonder how the memory can be banked on the P2000T. I have a dutch friend (from the MSX scene), who owns a Philips P2000T as well. Some years ago he presented it to me, when I was visiting him. Maybe I can ask him regarding the memory mapping. The 256x256x16 graphic is a real bitmap one? (not pattern/tile based?). When reading the dutch Wikipedia article it seems, that only a small part of the RAM can be switched. But as it is already different between normal and CP/M mode maybe it's possible to have more possibilities with such a modern 2MB expansion.

[GUNHED]

Yes a Philips P2000T version of SymbOS would be awesome! 

[retro space]

Would this run on my P2000T with 2080kB RAM and HiRes graphics card (256x256x16 colours)?

Hi Retro Space, I wonder how the memory can be banked on the P2000T. I have a dutch friend (from the MSX scene), who owns a Philips P2000T as well. Some years ago he presented it to me, when I was visiting him. Maybe I can ask him regarding the memory mapping. The 256x256x16 graphic is a real bitmap one? (not pattern/tile based?). When reading the dutch Wikipedia article it seems, that only a small part of the RAM can be switched. But as it is already different between normal and CP/M mode maybe it's possible to have more possibilities with such a modern 2MB expansion.

The graphics card has a second Z80 with 64kB VRAM and has true 16-colour graphics (with each palette swatch out of 4096 colours). I think it would be recommended to load special Z80 machine code routines on the video card, as it is by default activated with rather slow basic commands.

Bank switching is done with the upper 8kB. So you have 32kB on addresses &6000-&DFFF, and the 8kB from &E000-&FFFF is selected by writing a byte to a certain OUT port. This makes it possible to use 32kB+256*8kB=2080kB.

[GUNHED]

What is between 0 and &5FFF?

[zhulien]

What is between 0 and &5FFF?

1 to &5FFE

[retro space]

What is between 0 and &5FFF?

4kB monitor ROM
16kB Cartridge ROM
4kB video RAM

[Prodatron]

The graphics card has a second Z80 with 64kB VRAM and has true 16-colour graphics (with each palette swatch out of 4096 colours). I think it would be recommended to load special Z80 machine code routines on the video card, as it is by default activated with rather slow basic commands.

Bank switching is done with the upper 8kB. So you have 32kB on addresses &6000-&DFFF, and the 8kB from &E000-&FFFF is selected by writing a byte to a certain OUT port. This makes it possible to use 32kB+256*8kB=2080kB.

The graphic card sounds really cool, a Co-Z80 CPU working as a GPU, never heard about this before.
Unfortunately this memory mapping won't work for SymbOS. Both swapping a complete 64K area is required as well as some 16K mappings in some areas (#4000 and #c000, like the CPC can do).
I talked to my MSX/P2000 friend Frits, and he pointed me to this:
https://github.com/ifilot/p2000t-ram-expansion-board
He also told me that in general the P2000 could do the same memory mapping like the MSX, but the existing memory expansions don't allow this. But maybe I didnt understand it correctly.