@Algorythms: I think, that this problem could be caused by incorrect reading from IDE. Could you try another HD?

I use CF and I have no other card. BTW the CF is formatted with MSX partition table.. So my A: in dos is my C: in Symbos, and none of the other 5 partitions are displayed. I could maybe try with an old old old hd, but I think I will get the same bug.

Hm, if it would be the floppy access, you could try the following to skip accessing drive A in the "browse" dialogue:
- Open the run dialogue and FIRST type "c:\" in the input field.
- Only THEN press the "browse..." button. You will see drive C at once now.

Would be strange, if this really helps, as with the "f0" option the FDC routines should be completely deactivated.
But who knows...?

Prodatron: Tried that now. Just hangs after closing the Run window.

Hi Prodatron,

Quote:

I updated the ZIP with several (example) SYMBOS.INI files: http://www.symbos.de/files/symbosmsx.zip

I have installed it and now it works fine on both my MSX turbo R and on the ESE-MSX :-)


Kind regards,
Alex Wulms

wow, I finally got the time to test this new version and I'm amazed by it. Prodatron, you rule big time! I know the Netherlands aren't exactly nextdoor for you, but I think it would be great if you visited -for instance - the MSX fair in Bussum (or something similar) to demonstrate the lot. MRC can help you with, e.g. arranging equipment to make things happen. (getting an Amstrad CPC there for comparisons would be diff though )

@Alex: I am glad, that it works on the ESE-MSX, too! Right now I start to implement your Toshiba FDC routines

@Algorythms: Does it also hang, when you start an application by double-clicking the icons? Let's see, what will happen, when you are able to start apps from disc... I wonder, what timing issues could cause your problems.

@Snout: The Netherlands ARE nextdoor for me I was already planning to visit one of the meetings/fairs in the Netherlands, as I am living quite close to the dutch border (30mins to Venlo). In september I would like to come to Bussum or to Groningen. What would be the better choice?

Bussum. Without a doubt (and I say that as a member of MSX Club Groningen).

This maybe interesting for spanish people:

http://es.wikipedia.org/wiki/SymbOS

On the RetroEuskal/EuskalEncounter 14 the operator of http://www.museo8bits.es (Miguel Duran) decided to write an article about SymbOS in Wikipedia and it seems to be finished now (unfortunately I don't speak spanish).

Quote:

Bussum. Without a doubt (and I say that as a member of MSX Club Groningen).

Damn!... Right now I see, that exactly at this weekend I am visiting the XzentriX party in south germany Bad luck, but it's the most important meeting here every year. Ok, so we will see us in Groningen

Quote:

The SymbOS GUI is totally object oriented, with some Window-ish touches like the Start menu. The whole operating system has been written using optimized assembler; as a result, the GUI speed is insignificantly lesser than actual systems and is greater than, for example, the speed of the initial Amiga Workbench version.

That's not far from true!

Prod: I tried now opening minesweeper, and I can play it, but if I try to close it, everything hangs. I also tried several times to open first minesweeper, then taskmanager then control panel. It hangs while drawing icons. It manages 2-3 before hanging. If I start symamp it hangs when I click add song/browse or whatever. But the speed when it works in R800 mode is great! Hope you can solve this. BTW in 40MHz mode I just get a black screen when symbos tries to start. So it seems timing is the issue, yes. Not the ram.

Edit: It also hangs while trying to move a window. (At least minesweeper) So then I guess it has nothing to do with the harddisk timing.

Prodatron - could you contact me on sander@msxcg.nl about the meeting in Groningen? If we know when you'll come and what setup you need, we'll do some extra promotion and help you out in not having to carry too much stuff with you to the meeting.

@Algo: Maybe it's just a VDP routine. Maybe on your machine data sometime has been sent too fast to the VDP. Bytes are skipped, and the VDP isn't getting enough input during a CPU->VRAM command. So it's still waiting for data, when I want to execute the next VDP command.
I will modify the "wait until VDP is ready for a new command" routine, and then you can test it again

Correct me if I'm wrong, but doesn't a turboR modded to 40MHz always suffer from VDP timing trouble?