Yes, I used RAW mode and no sound, but I had not tested frame skipping. Seting frame skipping to 8 seems to solve the problem... Thanx!

Good... guessing further one reason could be that the camera driver is simply not getting any processing time if the emulation eats up all CPU power in the phone and that would then cause the HBI-V1 software to freeze because it will be polling the HBI-V1 I/O indefinetely. Using a higher frame skipping value does not really lower the CPU usage of the emulator but it does cause the emulation thread to execute more context switches and that way I think it gives more chances for the camera driver to get its share of the processing power. Dunno really, just guessing

Anyway, using the lowest possible camera resolution equal or above 256x256 might speed things up a bit as there would be less data to be delivered and processed for each frame.

Quote:

Actually, if you put automatic mode in loop, the software is sending command 2, reading the image data, sending command 2, reading the image data etc. but in manual mode, the software is constantly sending command 1, command 0, reading image data, sending command 1, command 0, reading image data etc. So it's terminating the digitizing process after each frame? Sounds kind of suboptimal...

Yeah, well... Hardware designer and software designer are not always thinking the same way. I think, that the real problem is the speed of MSX... If you wish to get the data out of digitizer, you have to stop it first, otherways you are going to get a picture containing part of at least 4 frames. :-) In practice the difference seems to be just, what key you need to press to stop digitize routine.

Now that I got this working stable, I just noticed, that in manual mode you can capture the frame so, that it draws first bottom of the screen and then upper half... Maybe command 0 should also reset the memory pointer?

Quote:

The current version takes a 640x480 image and uses a 512x480 part of it, i.e. ignoring 64 pixels on both sides of the image. From the 512x480 I then use only every second pixel horizontally and vertically, resulting in a 256x240 image that is returned through the emulated I/O. The last 16 rows contain garbage =) Since this is a sort of built-in zoom factor of 2, I was thinking if it would be better to just take a 256x256 "window" from the center of the camera image regardless of its resolution as long as its bigger than or equal to 256x256. Stay tuned =) Do you think supporting the interlaced capture would really have any benefits?

Don't know... maybe not, but at least in this point it should be quite easy to implement (just swap interlace status bit at every VDP interrupt and add it to y-coordinate)... I've seen one program that digitizes interlaced pictures with this device, but I think, I've lost that one too and maybe it is lost from the world already. It was made by Harri Meriruoko.

Maybe the emulator could automaticly select your suggested method, if support for 640*480 is not available.

Quote:

Anyway, using the lowest possible camera resolution equal or above 256x256 might speed things up a bit as there would be less data to be delivered and processed for each frame.

Hmm... ok, maybe you are right... These phones are not the fastest possible number breakers... BTW, how fast your phone is? My 6260 seems to run on 123MHz ARM 1040.

Quote:

Good... guessing further one reason could be that the camera driver is simply not getting any processing time if the emulation eats up all CPU power in the phone and that would then cause the HBI-V1 software to freeze because it will be polling the HBI-V1 I/O indefinetely.

In this case it should recover from the hang, when I disable screenupdate. Unfortunately it will not do that

Hi guys,

This is my first post here and I am so happy to find people who likes MSX

I downloaded the fsMsx emulator on my Nokia 6600 phone , but I still need the tool that converts the ROM file to SIS can any body please tell me where can I get it from ?

Thanks.

As mentioned in this newspost, I suggest you give Sousuke's ROMpackager a good try

Quote:

BTW, how fast your phone is? My 6260 seems to run on 123MHz ARM 1040.

How did you measure it?

Quote:

In this case it should recover from the hang, when I disable screenupdate. Unfortunately it will not do that

Yup, well let's see if we find a way to overcome that... other than using the frame skip that is. I already changed the code so that now screen mode 3 works (i.e. clear memory) properly. Since that is the command the digitizing software sends to the hw the first time the menu is drawn it could fix the hanging problem. In the released version that command also requested an image from the camera but after it was received it was simply ignored and the HBI-V1's image buffer was left untouched.

Snout, AFAIK that archive is broken! (At least I have not been able to open it)

You can anyway get a "tool" from jr homepage or you can install some file manager to your phone or use some sis maker out there or something like that...

Quote:

Quote: BTW, how fast your phone is? My 6260 seems to run on 123MHz ARM 1040. How did you measure it?

I have installed TaskSpy, that tells this information. Some other programs can also tell this...

After I asked you about this, I also find this page, that might be interesting:
http://www.newlc.com/article.php3?id_article=619

Yet another page, that proves, that my phone is crap!

Well, I guess I don't need to run that test program then since the page you linked already has the info on my phone (I'm using a 6630 atm).

Quote:

Your YJK conversion looks very nice!

Thanks... but have you checked that it is at least somewhat correct? I mean, in the emulator the image is of course displayed correctly because I'm the one generating the YJK data and also rendering the YJK image. I was just thinking that it might be a good idea to check if an image captured with the emulator looks approximately the same on a real MSX2+ =)

About YJK<=>RGB: wouldn't it be better to capture the video in RGB format, display it in (enhanced) RGB format (say 5:5:5 instead of the MSX 3:3:3 tones), and only convert it to YJK when necessary (i.e. when saving an image)?

I think quite a lot of (emulation)time won't be misused anymore then, as there's no effort anymore in converting input RGB to YJK, converting YJK back to RGB to display it, etc.

That is, I assume the camera inside smartphones render RGB images .

jr, thanks for your data. If you learn more, please let us know. We might try an implementation as well...