[OFFTOPIC]Am I the only one that's never seen a laptop with a working hibernation mode?[/OFFTOPIC]

[OFFTOPIC]As in, you've seen it entering hibernation mode, but defrosting the thing seemed to be impossible? [/OFFTOPIC]

The half-speed emulation option is now implemented for the 1.07 version. The support for it has a marginal impact on the performance, though, but hopefully the benefit of having this is a bigger plus than the (possibly) innoticable performance hit

This is cool, thanx!

jr - Did you also have time to look at the interlaced-rendering?

Not yet, but thinking about it I just realized that it would double the amount of screen refreshes even if only half of the screen really contains new pixels so it must be slower in overall performance. Anyway the current method I'm using is to refresh the screen every frameskip+1 vsync and the display contents is updated on the vsync prior to that.

I somehow got on a sidetrack to implement support for PAL again as well, so now I have three different modes supported: 64Hz (~NTSC), 48Hz (~PAL) and 32Hz (half-speed NTSC). PAL switches between 64Hz and 32Hz mode on every refresh so the overall refresh rate becomes 48Hz Meanwhile I haven't done anything for the other stuff discussed here earlier, but I might put v1.07 out soon anyway with the new speed options and the PSG bug fix.

The PAL mode sounds kind of sweet! I'm wondering how it works out in games!

Yea, that solution sounds great!
/me tries to figure out the effects/result of that method!

Well, at least after a quick test it seems pretty usable. But it's not a real PAL mode, the emulated MSX is still running in NTSC mode but the emulation is slower...

Hey, this sounds even more cool!

I think, that there could be this kind of VDP menu:

VDP refresh rate:
64/48Hz *
64Hz
48Hz
32Hz

* This could be default so, that you can change the refresh with VDP register 9 bit 1, but others could be selected as well to play (expetially ROM files) with custom speed.

About camera support... We have been working on reverse engineering HBI-V1 and results can be found here: www.msx.org/forumtopic4126p21.html

This is not yet enough information, but I hope we get some more when BiFi has time to test his working digitizer.

Personal question to jr: Mihin osoitteeseen sulle voi lähettää sähköpostia? Mun osotteen saa klikkaamalla nimeä vasemmalta.

Does the HBI-V1 have a "viewfinder" mode i.e. does it show a preview of the video while waiting for an image capture command?

Obfuscated message: eipä oikeastaan mihinkään osoitteeseen mitä missään viitsii julkisesti esitellä tai jota päivittäin tarkistelisin mutta pistän sulle viestiä tohon sun osoitteeseen niin voit vastata siihen...

Preview is done by looping the digitize routine until key press.

Hmm... I mean, I suppose it would be relatively(?) easy to hook the digitize ROM routine so that when it is called the emulator would step in and fill the MSX VRAM with an image from the camera and the ROM routine would simply be "skipped". But if I/O level emulation is desired more info is needed on timing for example -- do you need to read the whole image before the next image is digitized? What if you never read the whole image from the I/O? Is the returned image really only 256*256? Why is there an odd/even image bit? And so on, and so on

Quote:

Hmm... I mean, I suppose it would be relatively(?) easy to hook the digitize ROM routine so that when it is called the emulator would step in and fill the MSX VRAM with an image from the camera and the ROM routine would simply be "skipped".

Copying to MSX VRAM is not good idea, as then for example _MD and _DCOPY commands in BASIC could not work. This method anyway might be used to digitize image to external memory. I just personally hate this kind of hacks.

Quote:

But if I/O level emulation is desired more info is needed on timing for example -- do you need to read the whole image before the next image is digitized? What if you never read the whole image from the I/O?

My guess is, that the memory pointer is reseted when address #7FFC is written. In "viewfinder" mode 212 first lines are copyed to VRAM and rest are copyed over ROM. In digitize routine the rest of the picture is not read at all.

Quote:

Is the returned image really only 256*256? Why is there an odd/even image bit? And so on, and so on

Yes it is as SCREEN 8, 10&11 and 12 are all just 256*212 resolution screens. (Other screen modes are not supported)

In TV the screen refresh rate is 50 or 60Hz, but there is only 25 or 30 pictures send to TV. To get all the pixels, you need to digitize both odd and even scanlines. With this interface this can be done only to still pictures, as you don't have enough time to get both pictures from same frame pair.

As typically the camera quality is not enough to get 424 scan lines, it should be enough, that you just swich this bit in every screen refresh (32/48/64 times/sec).

There is also similar bit in VDP status registers to detect wich frame it is drawing, but it is not very useful if you don't use interlace mode (SCREEN,,,,,3 in BASIC). I for example used it to get 6*16 resolution fonts to screen 0