Quote:

keystrikes are saved on a internal buffer that is executed maybe one second later... Because of that, most of shot'em up are unplayable... Is there anything that you can do Jr? Or is it a hardware problem as I suspect?

I would say the problem is that I'm running the emulation in its own thread which uses 100% CPU time and the keyboard input is fed by the OS via another thread (the OS event handler).

Since I don't know of any way to "scan" the keyboard matrix on the phone I have to rely on the event driven approach which is of course slower. This added to the fact that all the CPU time is being used up by the emulation thread makes the response slowish.

I can try to find and use some tricks but cannot promise an improvement...

Quote:

However, correct me if I'm wrong but I think C-BIOS does not contain a BASIC interpreter nor does it work with disks unless you have the original Disk ROM...

Currently I cannot test it, but IIRC C-BIOS did not contain BASIC, but it also doesn't need a DISK ROM. Not 100% sure about this one though. The lack of BASIC wasn't a real problem as at the time I tested it it could already run quite some games from its own disk interface.

You could of course also write your own MSX-BASIC/C/Pascal/ASM routines to read the contents of a disk, display them and give the options to boot them. If you run it as a ROM file, or as a disk in drive A (with the actual disk in drive B) it should work as well. Maybe someone else wants to code this for you. IIRC some Xelasoft productions already came with such a menu.

Quote:

Currently I cannot test it, but IIRC C-BIOS did not contain BASIC, but it also doesn't need a DISK ROM. Not 100% sure about this one though. The lack of BASIC wasn't a real problem as at the time I tested it it could already run quite some games from its own disk interface.

Perhaps you're right. The disk emulation in fMSX is not I/O based but rather it is based on patching certain Disk ROM function calls so if there is no Disk ROM there is no way to use disks

The reason why I wanted BASIC to be present is that many games have BASIC loaders and I wouldn't want to write an MSX BASIC interpreter just for that

Quote:

I can try to find and use some tricks but cannot promise an improvement...

I think I made a small improvement in the keyboard responsiveness by raising the OS event handler thread priority. I'll try to post a new version this week with some of the other fixes and additions I've implemented.

Quote:

>>I can try to find and use some tricks but cannot promise an improvement... << I think I made a small improvement in the keyboard responsiveness by raising the OS event handler thread priority. I'll try to post a new version this week with some of the other fixes and additions I've implemented.

That's great Thank you so much for all your efforts with the emulator.

What about sound? Will that be included in the upcoming release?

Quote:

What about sound? Will that be included in the upcoming release?

Everybody knows how important is the role of the sound and music in the MSX system, but, I think that Jr should fix all the other small aspects of the emulator and then go for the sound emulation, that seems to be the more thought thing... Anyway I won't question his workstyle

Oh, and do not misunderstand me, I just LOVE to have sound in the emu ^^

Just some suggestions for the to-do list

How 'bout putting a pause-function in fMSX, so that the user can stop the emulation and swap to another program, picking up a call/etc... and continue later?

(I'm not very sure about it... but) fMSX is able to save/restore the current state, right?
Did you consider building that feature in the emu?

Sound support will not be included in this weeks release, I'm sorry. I have managed to get sound working on PC (i.e. if you run the MSX emulator inside a Symbian emulator on PC) but on the target device the system seems to simply run out of processing power. I haven't completely given up on this yet though. It might be that I will add the sound support only for the new OS version (7.0s) because it has much better audio streaming support - of course I don't know if that would speed things up enough or not, but I'll just have to wait and see. Anyway, I wouldn't hold my breath waiting for the sound support... sorry.

Pause function will be in this weeks release, I have already done it as a part of the disk change feature (i.e. you can pause the emulator and get a small menu where you can change the disk in drive A). I'm surprised nobody complained about this =)

fMSX does contain state load/save functionality, but I haven't ported it to my version yet nor have I given it much thought. It doesn't sound too impossible though so maybe I'll do it soon, I'll put it on my to-do list so I won't forget about it =) The thing about this is that the MSX memory needs to be saved so originally when I was working on 7650 I didn't want to do this because the 7650 has so small memory and I didn't want to waste a byte... On a phone with an MMC card this isn't a problem so there is more sence in implementing it.

For the forthcoming updates I have also been thinking about adding a support for multiple config files for the emulator so that you could set up the keyboard and other settings for a specific game and then save the setup for later use - could be handy as some games require that you can press some keys on the keyboard in addition to joystick control.

I have also improved disk performance, especially on gzipped disk images, by using the phone's internal RAM drive as a cache. Unfortunately the size of the RAM drive is not that big so it cannot hold a 720kB disk for example - so with bigger disk images the cache is not used. A smaller, 360kB disk, fits in the cache on my phone at least. Of course, if you have an MMC card on the phone you can easily just use non-zipped disk images to improve performance.

I just uploaded version 0.93 to my web page. Hopefully you will find the update useful even if it does not contain your favorite feature yet

I did not include C-BIOS in the packet since the C-BIOS binary license requires that the C-BIOS copyright, license and disclaimer must be produced from the distribution which contains the binary =/ In other words it would not be enough for me to add this information on my web page but somehow it should be displayed from the emulator. Anyway, I added a link to the C-BIOS web page from my web page and made a template for the C-BIOS ROM in the example .pkg file in the tools zip.

personal.inet.fi/private/riihimaki/s60

I have already tested the new version. It is amazing! The screen rotation and the faster key response makes the emulator A LOT more enjoyable.

Thanks! BTW, I found a nice way to implement the "automatic" load/run command for starting up basic programs from disks or tapes. I simply hook the BIOS PINLIN routine which the BASIC interpreter uses for reading commands from console. In my hook routine I fill the keyboard buffer with the correct command and restore the original PINLIN routine in BIOS...

Good release! Unfortunately kpi ball my favourite game which is a 720kb disk image is still slow as hell to load, too bad the Nokia 7650 has a so small cache size... Just a thought, could you add in fMSX a snapshot feature like the one of Frodo (the C64 emulator) for Series 60 ?

Not sure if this is possible but Frodo has a nice feature to avoid loading times where you can create a snapshot file of your rom image and load that in the emulator to start the game from the point where you saved (also when you got the .snap file the actual rom image is not even required to play the game, it's all included in the .snap). That would be a *very* useful feature for games like kpi ball which have slow loading times and many intros which you could skip to go directly to the actual gameplay. I could just create a kpiball.snap image and start playing directly everytime skipping all the intros.

Yes, this snapshot feature is the same as what Sousuke suggested a few posts earlier as state saving. I am investigating this, it is supported in fMSX/Unix so the source code is available, I just need to port it to my version. And like I replied before, this will need some space on the device because it requires that the whole MSX memory is saved to the snapshot/state file.

If you have space in your phone you can try using your KPI Ball disk image uncompressed, don't gzip the .dsk file. This will make it run a lot faster.

About caching .DSK files - maybe it's interesting not to look at the size of the DSK but at the size of its contents? So, if DSK files aren't sector-based, but have like 300kB of files on them, you should still be able to cache those files somehow. Otherwise a read-ahead cache should give some improvement as well.