Here is list of different PSG frequencys used by different systems:

ZX Spectrum: 1773400
Pentagon 128: 1750000
Atari ST: 2000000
Amstrad CPC: 1000000
MSX: 1789773

so... practically no need to convert between ZX Spectrum and MSX, it is quite a hard to hear any difference.

Hey, the first CPC sound modules are running on the MSX-PSG with SymAmp now
You hear the difference between 1 and 3,58MHz, but less than I thought (on the MSX it's higher). So I must correct the periode now, but it's already very cool

NYYRIKKI, thanx for the list, it's coming at the right moment!
Btw, what's a Pentagon 128??

Pentagon 128 is a Russian ZX Spectrum clone with new features, like a new os called TR-DOS, two PSG chips, covox, 2HD disks... etc. It uses floppy disk.

Here you have more info:

http://www.interface1.net/zx/clones/pentagon128.html

Podratron, I'm reading Symbos documentation and learning how system works (I said before that I want to code my large time deside Microcabbin compositor program) in SymbOS environment. After see your Devices.txt file I am supposing that there is a process to control PSG access (in my case FM could be in same case), then various codes can write values to PSG without problems.

I think that this could be translated into one process to control concurrent access to this devices (acts as denied of service or multiplexing in some way).

I'm begining playing with symstudio only to enjoy me (it's great too!!!), and I will waiting your reply.

Hi k0ga,
currently the PSG is not supported by the device manager of SymbOS, so the applications need to access it directly (yes, without any control). I was not sure, if it makes sense to introduce some hardware independant sound standard. But now for the MSX port it could make big sense to introduce a support for the PSG. I am currently thinking about it... But then SymbOS will only support the PSG... hm...

Winamp supports following MSX music formats with MSXplug: *.KSS, *.MGS, *.BGM, *.BGR, *.MPK, *.OPX, *.MBM shouldn't SymAMP support the same formats?

No, really just let us test this great system first! To be honest, I don't care, if there is no FDD support at the moment or loading is a bit hard. I'm just dying to see this running on my MSX! (Sorry of being so impatient)

How ever I think that mouse support should be quite a hi at the TODO list.

Prodatron I all I can say on the sound is yes, "I want it as a relocatable library" like we discussed yesterday. Just like graphics it makes sense to have direct access to hardware through a common set of controls. If the coder is left to tweak at harware the cross platform idea will be no more.

kOga I hope to have a new version of symstudio with the symbasic module and msx output out in a few weeks.

I'm just worried a little how much this cross platform support will cost CPU power, development time and RAM. I think, that it is not that bad, if applications are not absolutely 100% compatible. It is easy to compile different versions for different platforms, if that is reasonable (compatible hardware exists also in different platform.) The binary compatibility is good thing when the cost is reasonable.

@Trebmint: A library is not needed, I will implement something in the device manager for writing PSG registers. I just need to think about, how to do it in a good way (good performance, take care of the different frequencys, give access to the psg to only one task at the same time). I am sure, that it will only be a small piece of code.
@NYYRIKKI: Ok, I will try to make a downloadable preview until this weekend Regarding platform support: This will "only" affect the graphic. For the current applications I didn't change anything in most cases, and in the few cases, the modifications were VERY small. In the future we could provide a graphic library system, which allows to have an application + 2 additional files, one for the MSX and one for the CPC. Depending on the machine, the application will load the file with the correct library. This could be done by an OS function, so the programmer doesn't need to do anything, just to use the standard calls of the library.

Sounds a lot like a standard API like e.g. POSIX for C programmers. YOu program the same, but the compiled program runs on different hardware and different OS. The advantage is indeed that it does not give any run-time penalties. This can be quite important for low spec systems like ours... Please do keep this in mind! One program, multiple binaries sounds like a very good idea to me.

@mars: at the bototm of the screen you can get an idea of the currently selected item. But I think there should be a cursor, so it's probably a bug.

The big problem with a sound api is that it can only accomodate the psg like chips that have roughly the same functions. But there's probably too little standardisation in sound to warrant a real OS API. I'd probably choose a device lock system where an application can lock the device for direct access.

Agreed in the case of PSG

Yes, I agree, too.
Btw, I wonder, if the PSG is not the standard sound device on the MSX? Or do most users prefer to use some of the other sound devices?

The PSG IS THE STANDARD sound device on msx ranging from msx1 to tr! the other are simply (more sofisticated) add ons