...which makes me wonder if there would be any point in creating a KSS codec for Series 60... but don't look this way =)

And emulating only the PSG? Would that work?

Quote:

And emulating only the PSG? Would that work?

Well, now it's PSG and SCC(+). I didn't even try using the MIDI codec in Series 60...

The main problem with current phones (based on Symbian OS 6.1) is that audio streaming is not too well supported - handling the stream takes a lot of overhead which results in bursts of audio output. This is no problem if you are streaming a WAV for example, that has all the data in place. But in an emulator you need to be running the machine emulation at the same time to produce the input to generate the audio data in the first place. Now because the stream handling eats up processing time the machine emulation is not running at a constant speed anymore which then results in variation in the audio generation speed as well - which in turn can be heard as changing tempo =/

I was just wondering if couldn't be possible to code the sound part of the emulator in ASM, so in that way would speed up. The problem is if somebody would like to do that...

Definitly, sound plays a basic role in MSX. ^^

Yes it would be possible to code everything in assembler =) That would of course speed things up but it would not remove the problem with the audio stream handling -- in Symbian OS 6.1 applications cannot get direct access to the DSP (or even to the sound driver) so you would anyway be talking to the same media server process from your assembler code and it is exactly this communication which is not suitable for the emulator use case...

JR, do you think the Nokia3650 or 7650 could be firmware upgraded with a new version of Symbian OS in the future?

Why would you think I would know anything about that?

Ok, seriously, I know that this will not be possible.

I'm going to delay 0.95 a bit -- I implemented a feature for toggling screen refresh on and off in the emulator to enable better sound quality (of course without screen updates then) and I found out that first of all yes that would give the system enough power to handle the sound but I also noticed that the timing system I've been using isn't really working so the system actually starts running too fast =)

So I'll try to find a solution to limiting the system speed to 100% first and if I manage to tackle this it looks a bit brighter for the sound support then -- at least then you can listen to the music if you freeze the screen...

Whatever you do, it's great, jr!! And take your time

Quote:

Whatever you do, it's great, jr!! And take your time

Put that words in my mouth as well ^^

Okay, it finally seems that there is no way to synchronize the emulation (and thus also the sound) correctly in current phones. This is because the highest accuracy in timing available for applications is 1/64s, at least in the currently available phones. That makes it a bit hard to sync to 50Hz for example since the exact time needed to emulate the machine for one vsync cannot be predicted and the Symbian OS system clock only gives you 1/64s accuracy. This means that in a delay loop you could then decide to wait one or zero clock ticks and there is a huge difference in which one you choose.

There is an undocumented function call in the kernel interface that would provide access to a high precision timer but unfortunately this does not seem to work in the current phones - it is only working in the Symbian OS emulator on PC. Too bad. With this function call I have everything running ever-so-smoothly in the Symbian OS emulator so if the function would work on the phone... well, you know.

So far I've been lucky to have the emulation running at approximately right speed but in reality it is not synchronized at all meaning that if the phone had more CPU power the emulation would be running too fast.

So if anyone knows any good algorithm to still achieve synchronization with the timer limitations that the system has, I would be happy to implement it. Or if someone knows of a way to access high precision timer on the phone, I would be more than happy to take advantage of it.

Scrap the 50Hz, nobody uses it anyway...
Just sync the emulator to 64Hz, no problem with that. Audio can just be delayed one frame and everybody is happy
Just my 2 cents...

Quote:

Scrap the 50Hz, nobody uses it anyway... Just sync the emulator to 64Hz, no problem with that. Audio can just be delayed one frame and everybody is happy Just my 2 cents...

I agree, just sync to 64Hz would be nice. Everybody prefer 60Hz than 50Hz, so 64Hz is almost ideal.

I guess that you guys know about the Goboy, a Gameboy Color emulator for the Series 60 as well... It was running pettry fine, just like the fMSX, only a few games slowdown... The developers (the guys from WildPalm) have released a new version, the version 1.3 of the emulator, that features sound in emulation. I haven't tested it because sound support is only for registred users, but the source code of the emulator is available from their page. Maybe that it could be interesting for you Jr.

This is the URL: www.wildpalm.co.uk/GoBoy7650.html

I had a look at Goboy and it seems they don't synchronize at all, at least in the provided source code all timing functions were empty. I think GB emulation does not need as much CPU power as MSX since their source code was not even using direct screen access but instead wasting a lot of time talking with the Symbian OS Window Server.

I also checked what the C64 emulator does for timing and also there in the source code you can find usleep() implementation which does nothing. Other than that it seems to use this 64Hz timer and treat it as a millisecond timer even if that's not what it provides. Oh well.

So no help there but I'll continue the work anyway...