Quote:

there is a new website for SymbOS online now, which is open for everyone: www.symbos.de It's still under construction, but most parts are already finished. The most interesting part may be the screen shot section, where you can see the current SymbOS version (BETA I) in life.

What could I say. The screenshot look just awesome. Your work is really amazing.

About the emulators, you are almost answered. BlueMSX and openMSX are the most accurate MSX emulators nowadays. Try both of them and stick to the one who fits better for you. If you don't use Windows the answer is clearly openMSX.

Humm I've seen new screenshots, and well, you must see this running!

SymbOS is really great... and fast!

Yours,

Hi again,

the first fully functional version of the SymbOS multitasking operating
system can be downloaded now:
www.symbos.de/download.htm

It includes the new applications SymAmp (music player), SymSee (picture
viewer) and SymShell (text based command line shell), improvements for
the existing applications like SymCommander (now with full keyboard
support), a completed control panel, a lot of bug fixes and new
feature, some music and graphic collections and more.

As the CPC scene appears very dead at the moment (in any case the MSX scene is 1000x more active ;-) I will be happy to port SymbOS next year to the MSX 2 :-)

CU,
Prodatron

Great work

Quote:

SymbOS is really great... and fast!

Thanx! :-)
What do you think, will SymbOS have the same speed on MSX or could it be even faster because of the capabilities of the video chip??

Bye,
Prodatron

It looks interesting indeed!

About the speed, that's hard to say. From the looks of it, MSX2 screens use almost twice the memory for screens that you would use (256x212 16col or 512x212 4col). So it would probably be slower. If you have some speed numbers for the CPC, we could make a better estimate.

Quote:

It looks interesting indeed! About the speed, that's hard to say. From the looks of it, MSX2 screens use almost twice the memory for screens that you would use (256x212 16col or 512x212 4col). So it would probably be slower. If you have some speed numbers for the CPC, we could make a better estimate.

Speed will be a major challenge on the MSX. The CPC has memory mapped video, the MSX has I/O based acces to videoram.
Many attempts to produce a GUI on the MSX have been made, most were not succesfull due to the nature of the MSX video limiting the bandwith of transfers between main memory ram and videoram.

On the other hand: a GFX9000 version could be quite fast

Quote:

Quote: It looks interesting indeed! About the speed, that's hard to say. From the looks of it, MSX2 screens use almost twice the memory for screens that you would use (256x212 16col or 512x212 4col). So it would probably be slower. If you have some speed numbers for the CPC, we could make a better estimate. Speed will be a major challenge on the MSX. The CPC has memory mapped video, the MSX has I/O based acces to videoram. Many attempts to produce a GUI on the MSX have been made, most were not succesfull due to the nature of the MSX video limiting the bandwith of transfers between main memory ram and videoram.

Not sure, look at EASE. The GUI runs at a decent speed. On a CPC a lot of CPU time would be used to refresh the screen, copy windows around and the like. Some of these operations can be handled by the MSX VDP with hardware commands, leaving the Z80 available to take care of other tasks. Also you can use all the VRAM to store icons and GFX stuffs... Again this leaves the main ram free for the OS and applications to run without having to maintain GFX buffers...

Quote:

Not sure, look at EASE. The GUI runs at a decent speed. On a CPC a lot of CPU time would be used to refresh the screen, copy windows around and the like. Some of these operations can be handled by the MSX VDP with hardware commands, leaving the Z80 available to take care of other tasks. Also you can use all the VRAM to store icons and GFX stuffs... Again this leaves the main ram free for the OS and applications to run without having to maintain GFX buffers...

True. What I meant with the challenge was that it will not be a simple port, because of the bandwidth problem, but a redesign and rewrite of the graphical part.

Speed shouldn't be a problem at all. It will of course not be lightning fast, but it's very possible to make routines that are fast enough to allow you to work comfortably with the GUI. I suspect the speed of the MSX version should be comparable to that of the CPC version, maybe even a little faster. While it's nice to have direct access to video ram, the MSX method also has some advantages, like maggoo mentioned. I forsee no trouble at all, if we're realistic about what to expect. Anyhoo, I hope we shall soon find out...

Quote:

As the CPC scene appears very dead at the moment (in any case the MSX scene is 1000x more active ;-) I will be happy to port SymbOS next year to the MSX 2 :-)

We will be looking forward for it. It's so nice to hear that you will be happy porting it to MSX 2, we will really thank it

About speed problems, I think that all the graphics part of the OS will need to be totally rewritten. Making a speedy GUI for MSX 2 is quite challenging, but it's perfectly possible.

As Maggoo said, you can take a look to Philips EASE from Opera Soft. It's by far the best GUI for MSX 2, it looks so nice and it is really fast. Here you can view a screenshot:

Sony shiped their HIBIT MSX2 computers with "HYBRID", another great desktop manager. (altho kinda slo)

EASE remembers me at the Amiga Workbench, at least the same colours :-)
Is Ease or Hybrid available as disc image for an Emulator??

> About speed problems, I think that all the graphics part of
> the OS will need to be totally rewritten. Making a speedy
> GUI for MSX 2 is quite challenging, but it's perfectly possible.

Yes, all low level graphic routines of SymbOS have to be rewritten. These are "line/rectangle filling", "text plotting", "bitmap drawing", "scrolling" and "copy from cpu ram to video ram/video ram to cpu ram". After all these discussions I am sure that most routines will become quite fast!

CU,
Prodatron

Hi,

I saw this core loop in the thread about the VDP thread started by norakomi:

.waittrans: ld a,2
call ReadReg ; reads S#2
bit 0,a
jp z,.endvdp ; the command is over
bit 7,a
jp z,.waittrans ; still not ready to transfer next byte
outi ; dump data (faster!)
jp .waittrans ; loop

This seems to be more or less slow, but I wonder, if the VDP is clocked differently on different MSX machines? If not, why waiting for something and not doing some NOPs until sending the next byte (OUTI:NOP:NOP:NOPUTI:NOP:NOP:NOP:... as an example), if you know the exact VDP execution time?

CU,
Prodatron