... why did noone mention MSX-View? It has some nice apps, and is kind of an ok gui too. Still slower than SymbOS.
Easy was made in KUN-basic (with some mc-routines i.e. to print chars on the screen), and was just a GUI. It was in screen 6 too. I ported it to GFX9000 PowerBasic with 16 colors. Was nice and fast. Then my harddrive crashed and I lost everything. Anyway, it was just a gui from Basic.
Now SymbOS is a different league to all the old gui's!

Quote:

Wolf_ , Ease is great (looks like GEM and is fast and it has great native apps, but it doesn't support subdirectories, hard disk or multitasking, for example and it doesn't have a open api) but I am totally impressed with Symbos and except from the Office Suite, everything is SymbOS is greater than EASE or MSX-DOS. Also SymbOS is a totally complete Operating System, so it doesn't depend from MSX-DOS or MSX-BASIC. I' ve never thought to see such a fast operating system. Now I've tried in under BlueMSX and wow, for example SymCommander is far better than any file commander I've used under MSX and as someone has told here, is faster than using command! Now we are watching the born of a new and modern OS for our system ^^ Remember: it's not MSX-DOS...

Definitly not MSX-DOS
I see now. We were confined to the MSX-DOS1 or 2, BASIC environment. Applications (especially, duh!, games) are built around them as if they are irreplaceable OS. People just grew up using what they have in hand.
I'm happy that there's fresh blood has pured to the MSX community with a different thinking and perspective, people who can help in broadening our horizons, and who also showed an appreciation to the 'old slow' VDP and squeezed it hard enough to yield what it has to yield .

Maybe it is early to post it here but I would like to share with you the summary of a story I once read in Reader's Digest:
There was a rock that protruded from the surface of earth in somebody's yard. Many people thought that it ran deep into the ground. They said that it's like an iceberg; only the tip of it is what you can see. The myth has gone that way for a long period of time. Nobody ever thought of really trying to dig that rock up until a day arrived. A person said let me see if this rock is really rooted deep into the ground. Prepared by what is necessary (which is a freedom from being falling a prey of old convictions), he began to dig around the rock. To his surprise the rock was just half a meter under the soil. And of course eventually people realized that they should try things and figure it out by themselves, not just being stereotyped to believe others tales.

I hope that my message is clear.
Good luck

Good analogy!

@scratch_disk: Thank you for the nice compliment!

I found a bug in the memory detection (it always detected 64K more), and today I also want to shorten the "busy" time after booting, when no IDE is connected, so another update should be available in the evening.

Some things/questions:
- could someone help me with the stripes in the border? What I am doing wrong here? I can't see it in the emulator, so I just can guess here. Sonic_aka_T mentioned something with colour 3, but I didn't understand correctly. Which register/colour/etc. do I set in the wrong way? I think it should be VDP register 7, but bit4 is already 0.
- so if I only support the biggest memory mapper available, I don't need to do anything, as DOS1 and DOS2 always uses it as the default? So if you have a MSX2 with 128K ram + an external memory mapper with 512K, DOS will use the 512K?
- regarding the screen corruptions in R800 mode: I am already waiting for the "ready for next command" state. Do I also have to wait, when I just write bytes directly into the VRAM? What I don't do is to wait for a "ready for next byte" state for CPU->VRAM commands.

Starting from this week I will go on with the FDD routines. I hope to receive my second MSX2 soon, this time with a working disc drive
Can someone tell me, what type of FDC is included in the Philips VG8235?

Quote:

Can someone tell me, what type of FDC is included in the Philips VG8235?

WD2793

Quote:

Which register/colour/etc. do I set in the wrong way?

IIRC, you should repeat bit 0&1 in bit 2&3 to get a solid colour in screen 6.

Quote:

- so if I only support the biggest memory mapper available, I don't need to do anything, as DOS1 and DOS2 always uses it as the default? So if you have a MSX2 with 128K ram + an external memory mapper with 512K, DOS will use the 512K?

Mostly correct. There are some weird things that can happen on a turboR, but forget about those for now.

Quote:

- regarding the screen corruptions in R800 mode: I am already waiting for the "ready for next command" state. Do I also have to wait, when I just write bytes directly into the VRAM? What I don't do is to wait for a "ready for next byte" state for CPU->VRAM commands.

You should just make sure that any commands have ended before writing bytes to vram. Waiting for next byte is not necessary.

I've been playing around a bit and noticed a few lock ups. They always happen on disk access and are more frequent in R800 mode.

@Edwin, Mars2000you and others: Thanx for the hints!

I uploaded a new version to the same link:
http://www.symbos.de/files/symbosmsx.zip

It should contain the following improvements:
- the border shouldn't have stripes anymore (I hope so)
- I wait for "VDP is ready for command" before VRAM reading/writing, too. Hope you won't have any more screen garbage with the R800.
- I don't switch to Slot3 anymore. External mappers should work now.
- the memory detection shouldn't detect too much Ram anymore.
- fixed a bug in the IDE routines, which causes the delay at the beginning, if no IDE is present, and which could cause a complete crash later when accessing the IDE

Please test it and report any problems (or improvements...)

- the border shouldn't have stripes anymore (I hope so)
- I don't switch to Slot3 anymore. External mappers should work now.
- fixed a bug in the IDE routines, which causes the delay at the beginning, if no IDE is present, and which could cause a complete crash later when accessing the IDE

Although I trying SymbOS from floppy disk, yes, I can say that this is totally true. Now it works with my 512 KB external mapper.

I just tested it right now, so let's checklist:

• The border do not have stripes anymore.
• No more screen corruption in R800 mode.
• Memory detected is 512KB RAM (that's is correct as the turboR GT has a internal mapper of 512KB). But, as it were to expect from the turboR, if I use my 1 MB external memory mapper (total RAM 1536KB), the internal one is used and the extra 1 MB is not detected.
• Still, most apps won't work yet, just minesweeper, appinfo and task manager, no matter Z80 or R800 mode.
• Trying to load SymSee will cause the OS to freeze, no matter R800 or Z80 mode.
• I tested the system using a mouse connected to joyport 1. It works like a charm and really enhances the experience with the enviroment.

This is how this version looks on my MSX (R800 mode):



Yaw!! Nice progress

Hey, I've tried now my mouse and it works greately!

Prodatron, a request please. I noticed that you had introduced the vdp ce bit check before outputting each byte. This is really not necessary. I do not really understand the system lock so i will make you a request: can you post the fragment of your vdp routine?.

Also this slow down significantly in z80 mode, Can you make two different routines for this issue? Reading the status bit can slow down more than of 2 factor on z80 mode because for each byte sent ( out) you have to check the status (in a,(99))

SymbOS still tends to hang on R800 mode when I drag windows, but border color is now ok. This hang does not happen very often, but when it appears, it is complete. The computer does not respond to anything.

Here is another bug: When I drag windows with mouse, the window draging does not stop when I release the mouse button but the window continues to follow the cursor untill mouse movement stops.

I have had no problems with graphics, so I don't know if your change to VDP routines affected anything or not. If those graphic glitches are now corrected it may be also because of RAM size fix. As I have same setup as Karloch has and I'm able to run all applications etc. maybe the problem is a bit more deeper... I'm starting to think, that this might be loading problem... Karloch: Do you use CF or Harddisk to boot from? If HD, what PIO mode it supports? (look boot screen)

BTW, I think that some sort of hourglass could be nice... Now you don't know if you already started the program and it is doing something or you didn't double click correctly.

karloch: what happens if you try to run those apps?

Prodatron, can you please share your IDE code so we can find the problem on openMSX?

@Manuel: You can download the IDE routines here:

http://www.symbos.de/files/symbos-file-msx.asm

Erm, yes, I have a strange way to name labels and currently most comments are in german, but maybe it still helps you.
The other thing is, that of course I would like to see OpenMSX running with SymbOS, too! Tomorrow I will test the Catapult tool again and for sure I will ask you some questions. Is your email mentioned somewhere?

Wensen je het bestmogelijk

I just tried the new version, and it still has the same bugs as the last on both the A1ST and A1GT.
A1GT : When I click run and then browse it hangs. If I try to start control panel or symcommander from the start menu it eighter hangs or complains about missing file.
A1ST : Here I can browse, but if I try to start something it hangs or complains about missing file, or just don't start anything.
I use a CF card. I have all the files on both partition 0 AND 4 just to be sure. The A1GT is 1mb, the A1ST is 512kb