What is the final actual speed difference between the cpc and msx2 versions for screen stuff? My understanding was the msx2 was a good bit faster, so perhaps screen7 would be useable.

Also if symbos did move up to 16 colour would it retain the same basic 4 colour look? or could it look even nicer? Certainly 16 colour icons and buttons would look very cool

Can somebody kindly remind me of the download link of the MSX beta version of SymbOS?

Even if it is so slow, I think that it's worth to try to use screen 7. Hi-res colorful graphics for SymbOS If it's way too slow, we can always use screen 5 as well.

Quote:

Quote: Hey, cool! When I have finished all most important things for the MSX port, I will start with Screen 7/16 colour support. If it's very slow, I will also implement Screen 5 support. Prodatron, screen7 may be too slow (olny logical operations are equally faster on all modes), think about screen5.

Why do people keep saying this? It almost seems like it's the main excuse not do anything at all on MSX. I've been saying it from day one, and I'll repeat it again: Screen5/6/7/8/11/12 and every other screenmode you can come up with is more than fast enough to make a proper GUI in. All it takes is a little planning, and some 'creativity'. Well, perhaps the odd deviation from MSX standards helps a little, but even when adhering to the standards it's possible to make a 'fast' (sure, it's a relative term) GUI in screen 7. You can blit a 'whopping' 200kB (plus or minus, depending) per second on our good old MSX, which means an entire screen-rewrite can be done in well-under a second. That may not be fast enough for full-screen videos, but it sure as hell is for a GUI. So unless you plan on rewriting the entire screen every time something changes, a workable GUI is more than doable, something the current version of SymbOS already proves...

arf....

Quote:

Even if it is so slow, I think that it's worth to try to use screen 7. Hi-res colorful graphics for SymbOS If it's way too slow, we can always use screen 5 as well.

It won't be too slow. It'll probably be 50-75% slower than the current version of SymbOS, which more than fine for a windows-like environment. There's twice the amount of data to blit, sure, but the fact that there are just 2 pixels in a byte also means that many more of the commands can be done using a single HighSpeed command instead of a combination of LowSpeed and HighSpeed commands. In the end it'll work out, trust me...

Quote:

Quote: @Arnold: That's it! This wasn't mentioned in the portar document, and BlueMSX seems to have a wrong behaviour here (@dvik: could this be?). Thank you! @Prodatron: I just checked and it is indeed a bug in the emulator. I'll fix this asap. Let me know if you need a new beta.

Any idea if it is also in openMSX? If so, please mail to our devel mailinglist so that we won't forget.

@NYYRIKKI: Thanx for the info!
@Manuel: openMSX doesn't have this bug and works fine with the second sprite colour!
@Alex: Here is the link: http://www.symbos.de/files/symbosmsx.zip

Regarding speed in Screen7: Only the 4 colour graphics should slow down everything a lot. Not only, that the driver has to send the double amount of data via CPU->VRAM commands. It also has to convert it first from 4->16 colours, so I can't use simple OTIRs. But I hope the speed is still not too bad. In any case there is nearly no work to do for rewriting the screen 7 driver to screen 5.

Quote:

Also if symbos did move up to 16 colour would it retain the same basic 4 colour look? or could it look even nicer? Certainly 16 colour icons and buttons would look very cool

Some things won't be easy to realize, but I hope, that beside the graphical controls we can also have more colours for some other controls. The important thing is, that everything still looks ok in 4-colour screen modes.

Currently I am working at the fullscreen mode of SymShell.
Short question regarding screen 0 (80 column mode): Is there a way to scroll the screen without rewriting the whole screen with the CPU?

Quote:

Quote: [quote]Hey, cool! When I have finished all most important things for the MSX port, I will start with Screen 7/16 colour support. If it's very slow, I will also implement Screen 5 support. Prodatron, screen7 may be too slow (olny logical operations are equally faster on all modes), think about screen5.

Quote:

Why do people keep saying this? It almost seems like it's the main excuse not do anything at all on MSX.

Ok, i agree, most (never seen) programs/games are never developed on this machine because of it's apparent 'slowness'.


To be honest, the real problem is this:

MSX2 had '16bit class' gfx capabilities with power to manage it as 8bit machines. (vdp == snail)

If you compare msx2 with other 8 bit computers of the '80 era, you see that no other home had capabilities to show simultaneus 256 colors on screen without limitations, even a screen 7/4 bits per pixel resolution was unmached in 8 bit machines. Some features are also not common in 16 bit machines. (Even amiga could not show 256 colors on screen simultaneusly without limitations). This of course 'cost' in vram size.

So msx2 machines had huge amount of vram with a small processing unit (vdp/z80 @3.5mhz). Now, take this in mind:

-z80 can address 64kbytes -> vram is twice the size of addressable ram 128Kbytes.
-A modern p4 cpu can address 4Gb.

How many take a z80 to fill entire vram? somthing like 1 sec. But filling vram with a z80 is like having to fill a vram size of 8gb on a PC with a P4.

If you take some calculations you will find that in the order of magnitude the time required to manage 8Gb with a pentium is not so different to the time required by the z80 to manage the msx2 vram size. Actually however no pc gfx card have screen with GBs of vram size! per screen. (fortunately)





What i'm saying is that the reasonable amount of vram is for a 8 bit machine, roungly about 16Kb (like CPC). While large amount are suitable for static images, they are almost un-workable for other uses in a decent time. So games especially, but also SymbOs will be suited better in sc5!.

Quote:

I've been saying it from day one, and I'll repeat it again: Screen5/6/7/8/11/12 and every other screenmode you can come up with is more than fast enough to make a proper GUI in.

Depends of you mean with 'fast enough'. I do not like to sleep between a re-display of a window caused by some operation (like iconizing or so )

Quote:

All it takes is a little planning, and some 'creativity'.

creativity is a good thing, but there is no creativity that can compensate the slowness of (snail) vdp in graphics operations...

Quote:

You can blit a 'whopping' 200kB (plus or minus, depending) per second on our good old MSX, which means an entire screen-rewrite can be done in well-under a second.

Wow!!!!!!!!!!!!!!!!!!!!!!!!!! LIKE A D.M.A. does!

Quote:

So unless you plan on rewriting the entire screen every time something changes, a workable GUI is more than doable, something the current version of SymbOS already proves...

remember that is working in sc6 where when you write a byte you are affecting 4 pixels !

Quote:

Currently I am working at the fullscreen mode of SymShell. Short question regarding screen 0 (80 column mode): Is there a way to scroll the screen without rewriting the whole screen with the CPU?

@Prodatron: Why do you need to go in this mode? Is not SymbOs a graphical environment?.
Anyway To scroll screen 0 the fastest thing is to do only with z80. This is because grpx vdp commands are only avaiable in sc5-sc8


There is some people that had successfully used vdp commands 'outside' the sc5-8, for example in sc2/sc4. I think could also be done in sc0-

Some tricks involve to
-switch to sc8 grpx mode the vdp
-do the command and wait it to finish
-then restore screen 0. But this works only during vblank otherwise you see the screen mode switch. Because sc0 is however a ' particular mode ' i do not know if could be done also in this mode.

I think that, seen the small amount of data (less than 2kb) this is perfectly workable with z80 by storing a buffer in ram.

@PingPong: Cool trick to switch to another screen mode for a short time to do some scrolling! But as you said, for such a small amount of data using the CPU is fine, I will try this first.

The reason, why I need this mode is the following:
SymbOS contains the system application "SymShell". This is nothing else than a DOS box and similiar to MSX-DOS. You can open it as a window ( http://www.symbos.de/gfx/shots/system/symbos-system-symshell1.gif ) or as a fullscreen shell in text mode ( http://www.symbos.de/gfx/shots/system/symbos-system-symshell3.gif ). Applications can use SymShell as an input/output terminal.

Actually, I wouldn't recommend doing a mode-split to 'scroll' in screen 0. You're talking about less than 2kb of data which should OUT just fine, even when scrolling a lot. To use a mode-split means waiting for VBLANK before being able to issue the command, and then still having to send the last line like you would normally. It really isn't worth the hassle, since screen 0 is more than fast enough using normal VDP access. Just keep the data in RAM, and OUT the whole thing when the need to scroll arises. Using a couple of block OUTIs you're talking less than half an interrupt here, meaning you should be able to update the screen faster than the monitor can display it...

Plus that commands wouldn't really help here since a block would have to be moved 80 bytes and there is no linear copy option in v9938.

Prodatron, will we be able to run MSX-DOS(2) programs in SymShell?