By the way, especially on shooters I'm having quite some difficulties with the speed of the emulation. As the phone controls aren't as easy as an MSX joypad or keyboard and the screen is quite small it's hard to play as good as on the real thing. Is it possible to slow down the emulator just a few % to increase playability, or would this affect performance and accuracy?

Naaa, I agree with you snout I've finished Aleste2 quite a few times, so I really know how to play shooters, but playing them games on my S60-phone.....It sucks.....

The biggest problem is that the joystick supports only four directions

Will the 6630 have an 8-directional joystick?

Another problem IMHO is the speed. The VSync is set at 64Hz, due to the symbians inaccurate timer...

JR, could you try to implement a small routine to synchronize the emulator at 50/60Hz?
The idea is using an extra (fixed point) counter, increasing it by an pre-calculated value at every 64Hz-timer-event, and triggering the VSync when a overflow in that counter occurs...

Aaaargh, how should I explain it more exactly?
Here's a pseudo (c++) code, hope it'll make my idea a bit more clearly:

// variables
word counter = 0;
byte increasement = 256 / 64 * IFreq; // IFreq == 50 or 60
[...]

// here's the timer-event callback synch'ed at 64Hz
// update counter
counter += increasement;
// time to trigger VSync?
if (counter >= 0x0100)
  {
   // yes!
   // re-adjust counter
   counter &= 0x00ff;
   // trigger VSync
   [VSYNC CODE]
  };
[...]

I'm very aware, that it the VSyncs are triggered irregularly, and the emulator's only synchronized at approximately 50/60Hz... Would you give it a try?

[edit]BTW, using a bigger counter and adjusting the increasor would give more precision in the timer, but I guess I don't have to tell you that [/edit]

Could this potentially even increase performance? (less screens to actually draw -> less frameskip needed to play the music without distortion?)

Well the emulation is slowed down a bit, so more CPU time will be free for other tasks/threads
So yes, I think the (overall) performance will increase, because the timer-routine isn't that CPU consuming, and converting it to Assembler is also possible (and even an easier job)!
But how much CPU power will it save? Guess we'll have to wait for jr

Quote:

Will the 6630 have an 8-directional joystick?

Not sure, Nokia doesn't tell anything bout the joystick in that phone... IMO they used that crappy (4+1) 5-directional joystick again

BTW, I've read that phone also supports Nokia's BT-keyboard! Curious to see whether it's possible to use it in fMSX!
(Well would be one more reason for me to get that phone then )

Doing this would cause some overhead - currently I've made *almost* everything run on a single thread to squeeze every last bit of processing power from the CPU (i.e. not wasting cycles on running the task scheduler). Making the (video) sync irregular would require a separate thread for the audio processing because it needs to be running at a constant rate. I know I'll have to go back to this approach (I had the audio implemented like that in the beginning) if there is ever going to be a more precise timer available in the OS to get the correct 50/60Hz sync possibility but I hope by then we'll also have more CPU power to compensate. With no audio support it would of course be rather easy to try out your suggestion. The impact on performance, however, might not be as big as you hope because my current implementation is already only rendering every second frame resulting in 32 fps if frameskip is set to zero. I decided to do this since on a real TV you would anyway only have 25 or 30 fps due to interlacing (plus it gives a big performance boost to the emulator, of course . One funny thing to experiment with would be to change the rendering to use interlacing, thus updating half of the screen on every screen refresh - this would balance the CPU load because now on every second screen refresh there is a lot more to do. I might just give that a try some of these days...

About the BT keyboard -- I don't know how it integrates with the OS, but if it is transparent for the applications, there is no reason why it shouldn't work as the emulator is accepting all keyboard input. In fact, in my development enviroment when I run the fMSX/S60 inside a Symbian OS emulator on a PC, I can use the PC keyboard normally and fMSX/S60 accepts the input. Another thing is then the latency of the BT keyboard - while it may work, it could be that it's not really good for games if the keyboard events are not being generated fast enough.

Understood. I think interlaced rendering might be worth a shot indeed and am, as usual, looking forward to the next version of fMSX/S60!

Just a thought... As many S60 phones has also camera, video digitizer support could be quite original and cool! The picture quality of the cameras are typically very bad, but just enough for MSX usage.

I know, that Sony/Phillips type digitize support is hard to make, but HBI-V1 cartridge support should be easy to implement. Practically it works so, that you tell to hardware, do you want screen 8, 10 or 12 picture. Then you ask it to digitize a frame. After that software is used to copy picture from memory mapped buffer to VDP.

One nice extra feature could also be personal controller/macro setup for each ROM/DSK. It could be for example a text file, that has same name as the image, but with different extension. If that is not found, then default values will be used.

About the headset audio -- I tested it with my 6600 and it is automatically switching the audio off in the main speaker and routing the emulator sounds to the headset when a headset is connected to the phone. And vice versa when you disconnect the headset. On a 7650, it seems it doesn't work: the emulator sounds can be heard from both the main speakers and a connected headset simultaneously. Since the emulator code contains no audio routing control, I suppose this must be either the OS or the HW that makes the decision. I couldn't find any way to affect the routing on a 7650 - of course that doesn't mean it wouldn't be possible.

About the video digitizer support -- using the camera in Series 60 is not a big trick, I suppose it would be rather easy. To be able to deliver that to the emulated MSX I would need to know exactly how the MSX expects to get the data from the digitizer. I assume this is not really an important feature for an emulator that is mainly focusing on enabling gaming, but if it seems easy enough to implement I could do it.

About the separate control settings per game -- something like this has already been cooking in my mind. Unfortunately I've been rather busy lately so I haven't had too much time to spend with the emulator activites. This would probably need some sort of UI to manage the settings files as well, just like the game specific save states: it's quite annoying that once you've made a save state you cannot delete it (well, not from the emulator UI anyway). I intend to fix this when I have time to implement it.

Quote:

the emulator is accepting all keyboard input.

Yeah, it is good, that I can even use Camera button in fMSX! The only 6260 key, that does not work with fMSX is the pencil key (used to select multible things) below menu button.

About the emulation speed... I understand, that 64 interrups/sec is pain, but could you implement even half speed? Games, that are designed to run in 50Hz are practically impossible to play in 64Hz more. 32Hz would be then too slow, but it gives you some compensation, that you propably need because of typically very non userfriendly keyboard. :-)

About the video digitizer support... I could not find the ROM of HBI-V1 anywhere, but I think, I can loan one broken digitizer to dump it and check out, how the software works. I think, it has 32K ROM. First 16K is used for the BASIC extension & memory mapped I/O. Rest is used for the internal digitize software made in BASIC (can be started with CALL DG) It might have been, that the BASIC program is also in the 16K block. Anyway... this is not very helpfull information.

I remember, that there was some ASM program in Hnostar magazine, that could be used to digitize pictures on GFX9000. Does someone have this program? It could be pretty usefull to check how this thing works... or even better, does anyone have programming documentation about HBI-V1?

I thought, that I could try some day to make KSS loader optimized for this emulator, but I have few questions:
- if Z80 is most of the time in HALT mode, does this save phone battery?
- If I disable screen by using VDP register 1, does this disable also screen update?

The pencil key you refer to is in fact a SHIFT key. I don't remember if I'm only allowing keys that produce a real key event instead of just scan codes or modifier flags but I can double check that. If I remember correctly the problem with the SHIFT key was that some event was not produced (e.g. if only a "press" event is generated but no "release" but I'm not quite sure if it was like this or something else

Yep, 50% speed option should not be a big problem to implement in the current code base. I need to make some adjustments for it but I'll see what I can do about it for the next version.

The emulator is using 100% of the phone CPU always while the emulation is running regardless of the state of the emulated Z80. Note that the emulator is also forcing the phone display backlight to stay on even if you don't touch any keys. If you think it would be useful I could implement an option in the emulator to let the display backlight go off if you don't press any keys for a while (just like the phone behaves normally when it's idle except for the screen saver of course). That would save at least some battery power if you want to run the emulation with no interaction for a longer period of time. I don't know if this has any effect on the 6260 though if you "close the lid" because I would expect that the display is switched off in that state anyway (I don't know since I don't have one).

I'm not planning to change the sync algorithm until there is enough power in the phones and a proper timer available in the OS to provide correct timing, i.e. the system is fast enough to run the emulation at proper speed and timer accuracy makes it possible to synchronize the emulation properly. If emulation is paused, all threads are blocked and CPU utilization drops to 0%.

When VDP output is disabled, the phone screen is still updated but the drawing is of course faster because this is detected and separate code is used to draw only black regardless of the rest of the VDP state and VRAM contents. The only way to totally suppress screen updates is to define a special key for it in the emulator's control configuration and use it while the emulation is running.

Thanx for the info!

Quote:

I don't know if this has any effect on the 6260 though if you "close the lid" because I would expect that the display is switched off in that state anyway (I don't know since I don't have one).

Unfortunately the screen is not switched off.... Closing the lid has practically same effect as when you push "end call" button. This BTW sucks a big time!

Quote:

I don't know if this has any effect on the 6260 though if you "close the lid" because I would expect that the display is switched off in that state anyway (I don't know since I don't have one).

I'm trying to get one of these NYYRIKKI: closing the lid being the same as pushing the 'end call' button is usual. All phones I've seen up till now do so. It would have been better if they kind of implemented the laptop-standby or -hibernation mode