It seems there are some MSX users here As far as I know, the graphics controllers in MSX computers (TMS9918, V9938, V9958, or maybe even V9900) has own dedicated video RAM and not shared with the CPU. So you need instruct the video chip to do something with the video RAM (afaik there are some "hardware accelerated" operations as well can be instructed?). But if it's true, how can someone play video on MSX when it's always slower to modify the video RAM by video chip ops and not direct video RAM writes by the CPU itself? My question also remains for the rest of a SymbOS like software: without direct video RAM access how this can be implemented at a sane speed? Sorry if I asked something stupid, I don't know too much about MSX machines, really ...

Well I'm sure prodatron can illuminate more on MSX video, but as the person who coded the video file creator called symstudio I can say that the video files have fairly small frames... each screen is around 6k and frame per second is on a standard 4Mhz MSX2 about 7-8 and a little slower if something else is processing. Believe it or not the speed of a standard MSX playing 16 colour video is faster than that of a 4 colour CPC, which shows you the power of a VDP chip.
In general use Symbos stores the graphics such as fonts and backgrounds within the video ram, so just issuing a block command to the VDP is really really quick compared to our normal direct writing to video ram method.

Pushing the limits with colors ...

In an 50Hz CRT monitor (especially with old, slow fluorescent materials) when we use 25FPS, but we render 2 different frames (with related information of course) then the monitor itself will mix the two frames of every 25 FPS screen ... it will be flashy, "vibrating" screen, but the colors will be approximately (a+b)/2.

So with this technique, on CRT monitors, users with limited color systems can have more colors.

But for this, SymbOS would have to draw 2 screens, every graphic resource could be converted for this mode, probably changing the application creating tools, pipelines and such ...


But with a special use of this technique the applications could be the same as they are now, and on EP the technique probably will have a more enermous effect than on other platforms.

The special use would be using every first screen drawing SymbOS without background picture, and drawing every second screen using the background picture AND a one color mask of the SymbOS's screen what is drawn on the first screen previously.

With this technique, SymbOS would be drawn almost the same way and with the same applications as now.

The background picture would be mixed with the background color of the SymbOS frame, and the SymbOS screen elements (windows) would be mixed with the one color mask on the background picture screen.

In this way the background picture frame can have a totally different palette than the SymbOS frame.
It would be cool, but on EP the benefits would be much larger,
because on the enterprise with an LPT changing the palette in every scanline,
you can display every 256 colors in one picture if you want that.

With this way we can convert pictures to the EP like these:

http://www.ep128.hu/Ep_Demo/Leiras/Enterprise_Slideshow_2.htm
http://www.ep128.hu/Ep_Demo/Leiras/Enterprise_Slideshow_3.htm

We would have to save one color from the palette of every scanline, that would be the mask color, what is required only for reaching that the background picture will not be visible mixed into the windows of SymbOS.

In this way, similar pictures like these could be the background of the EP SymbOS, and SymbOS could be drawn with its own 4/16 colour.


And this "multi color background" technique could be combined with the vertical scrolling virtual desktop or the amiga like draggable multiscreen techique, at once ...


Of course, I did not verify the memory requirements of these ...


I hope I explained well these ... my english is barely enough for such things ...

Yes, but of course, the background pictures cannot be interlace pictures,
because that use the 25FPS technique in itself ...

I do not know what is better ... using interlace for the SymbOS case or not (probably not),
but one of the pictures is the background and the second is the SymbOS (and both in normal Y resolution).

But very-very similar pictures like these ...

the main issue is that as a windowed OS, not a fixed full screen palette switching would have bad effects in that say two images/forms could not share the same screen without 1 looking awful.

With the trick I tried to explain, SymbOS's screen would be drawn by its own 4 or 16 color palette on the whole of its screen.

It would be like this:


- NICK draws the background screen. The background screen is an LPT changing the palette (without Z80 involved) by scanlines. The graphic data in memory is a multi-color image shown before + a one color mask where the SymbOS windows are. The mask overwrites the picture data with the mask color, of course.

- Next frame NICK draws the SymbOS frame, which is a normal SymbOS LPT with 4 or 16 color, and the background image is not drawn, only a background color. (Or we can call it mask color in this case, too.)

This sequence (two 50 Hz frames) is repeated by the NICK, without Z80 involved. We only see the SymbOS's screen on every second video(monitor) frame.

In this way, if a SymbOS application does a 50 Hz animation, then we will see it 25 Hz because we will se only every second frame from the SymbOS buffer ...
This is not good, but SymbOS probably rarely does 50 Hz animations, but on the EP we will have multi color backgrounds ...

The mixing of the two frames is done by the CRT fluorescent material. (Or the human eyes and brain of the observer, too ... I do not know ... )

Do you still say this is problematic somewhere ? I do not see the problem ...

Yes, maybe the whole concept is EP specific too much ...

But how I see ...

The difference to the normal SymbOS working would be

- A different LPT which contains two frames instead of the current one frame ...
- One of the previously specified LPT frame data and its associated graphics data could come from an EP specific format. It could be a binary, not interpreted on other platforms.
This would be the multi color background image. This image have to be represented in a color mode what SymbOS knows (4 or 16 color mode). But the palette could be change raster by raster except of the mask color what have to be constant in index and in color.
- SymbOS would have to draw mask rectangles on the background frame in parallel to the original windows on its own frame. It has not to know the palette at all, it has to know the mask color index only with what it draws the mask.

The rest would be the same, I think.

The problem (I found now) is that the screen mode of the background image have to be 4 color mode, when SymbOS draws its screen in 4 colour mode, because the mask rectangle have to be drawn pixel perfect on the background frame, too.

And I do not know exactly 4 color mode is enough for those nice pictures, or not.

I'm sure if its easy or even possible Prodatron will attempt it (He is a genius after all). First however I'm sure he just wants to get the 1st flavour working, and then probably the borderless version.

I must admit as a CPC user, I'm pretty jealous of the machine the MSX'ers have. The CPC is stuck in 4 colours, as the chunky 16 colour mode looked a bit rubbish. 160x200x16 was childish looking (and prodatron removed it) - Strangely though 256x212x16 which isnt that much greater is lovely on the MSX. I even prefer the 1:1 square pixel 256x212x16 MSX mode to the 2:1 pixel 512x212x16 mode.

Somebody needs to get designing a Symbiface 3 hardware for the MSX/CPC/EP which has Mouse,Ram,SD,HxC,Networking,Real Time Clock, and serious graphics chip... Then we'd see something truely wonderful

In attribute mode the most easy use black as mask color.
At the masked area just set the attibutes to black. It is need half of memory size than the normal graphics.
Only problem, when the SymbOS objects not aligned to 8 pixel at horizontaly, the 1-7 pixel additional black shadow added.

The CPC is stuck in 4 colours,

Except of the taskbar, EP is stuck at 4 colours, too ...

It is why I tried to integrate the multi color EP images to the EP look and feel of the SymbOS ...

But without a pixel perfect mask AND the vibration of the screen ... I do not think it would worth the effort ...