I uploaded all versions since 1.00 to my website just now, you can download any of them using the links in the change history. Meanwhile, I'm sorry I haven't yet had a possibility to investigate the problems you reported, I'll try to think of something before releasing 1.07.

I'll give #1.04 and #1.05 a try anyway, jr

Thanks man!

I tested FM-PAC with the current work-in-progress 1.07 version and it was working correctly in "KPI Ball" at least.

Since I couldn't find anything wrong with the FM-PAC emulation I decided to release v1.07 as it has been waiting to be released for quite some time already.

To make things more complicated I introduced a new variant, v1.07x, which has the preliminary HBI-V1 support in it. The "normal" a and b versions don't have support for HBI-V1 since it slows down the emulation a bit (plus the x version consumes more power because it keeps the camera powered on all the time). The x version should be compatible with phones that can otherwise run the b version, but I have only tested it on my 6630. It will not work on phones that need the a version of the emulator. HBI-V1 support also requires the phone's camera to be able to deliver 640x480 images.

Unless you want to play with the HBI-V1 emulation I suggest using a or b version instead of the x version for now.

GREAT job! Can't wait to give that 48Hz mode a go!

jr, any chance that HBI-V1 code might be useful for other emulators?

Maybe - are you interested? It's still very much unfinished: the block size and start parameters are not supported and since I don't know what the difference between manual and automatic mode is, they work in the same way. I noticed that the HBI-V1's internal digitizing software uses command 2 in automatic mode and command 1 & command 0 in manual mode.

jr, if you agree a (dual? I don't know what your current license is) license under the GPL or another compatible license, we might be interested to incorporate it into openMSX.

hello jr, great work with your fmsx port. im the maintainer of the GP32 version and i'd like to know what you modified in the ay8910.c file to fix the envelopes. i was thinking about using a modified ay8912 sound core from FUSE (ZX emu), which is quite good indeed, but i think its better to know what you did first :-) take care

I'm having troubles with the HBI-V1 support. Something is just not right...

With MSX2 the emulator just hangs (black screen), when I try to start the _DG software.

With MSX2+ I get the digitizer screen, but I can't select anything from the digitizer menu as MSX just hangs. I think, this has something to do with speed or screen refresh routine. If I keep screen update disabled while software is starting and I disable it every time, I select something, the software seems to work... It is anyway quite a hard to use with screen disabled.

manuel, I think sharing the actual source code directly might not be that feasible because my source code is very much Symbian OS specific, especially in the modules that interface with the OS like the HBI-V1 emulation since it uses the camera API. If you take that out, what's left is not much, I can actually explain the current logic here:

Setup:
- I'm calling MMIO 0x7FFC-0x7FFF registers C-F.
- Initially all registers are zero except D, which is 0x10 (==no video signal).
- When camera is initialized, register D bit 4 is cleared (==video signal detected).

MMIO writes:
- Write to registers F and E just save the value as is.
- Write to register D only affects bits 0-3.
- Write to register C only affects bits 0-1, and if register D bit 4 is zero, bit 7 of register C is set and concurrent command processing is started

MMIO reads:
- Reads from 7E00-7EFF always return the "next" byte in the 64k image buffer - the pointer inside the buffer is reset always when a new command has been processed
- Read from register D simply returns its current value.
- Read from register C does the following before returning its value: if register D bit 4 is clear, register C bit 5 is flipped and if also concurrent command processing has finished, register C bit 7 is flipped

Command processing (runs concurrently with the emulation):
- Command 0 finishes immediately doing nothing
- Command 1 and 2 fill the internal image buffer with data from the camera, reset the buffer pointer and finally finish processing

So, not that complicated at all. Filling the image buffer with data from the camera of course then is a bit different depending on the register E bits 6 and 7 (i.e. the screen mode). Do you think this is sufficient for you to implement it in openMSX as well or if you still think seeing the actual source code would help I can do that too. I just thought this would be more informative than my source code =)

NYYRIKKI, I didn't get the internal software to work with MSX2 either. I think it only works with MSX2+ for some reason. The internal software won't let you choose anything if the video signal detection bit is not ok and if bit 5 in 7FFC is not flipping. I suspect that there is something wrong with the camera connection. If you only wait in the menu long enough (this can be quite a while) you should get the grey "no video signal" screen. I will try to see if it works on a 6600... I was also thinking of changing the code so that it would accept any resolution from the camera as long as it's higher than 256x256. This could help things out. I'll keep you posted, I will make separate releases for the x version as soon as I have something new implemented.

rlyeh, I'm assuming you mean the envelope frequency fix I did in the recent update and not the envelope volume fix I adapted from fMSX 2.8. First of all, I don't use any of the fMSX source code, I don't have the file you are referring to =)

But the corresponding place in the fMSX source would be in the file you mentioned I guess, in the function where a write to the AY8910 registers 11 and 12 is handled. In the original code, the calculated envelope period could become zero, which would later in the AY8910 update function be checked and regarded as no envelope running. This then leads to other parameters not being updated. To fix the problem, I simply added a check for the zero length envelope period right after it has been calculated and if it's zero, I make it one to force the update loop to be run at least once.

Does this help?

Quote:

I don't know what the difference between manual and automatic mode is, they work in the same way. I noticed that the HBI-V1's internal digitizing software uses command 2 in automatic mode and command 1 & command 0 in manual mode.

Yet another lucky guess... In automatic mode one frame is digitized and that's it. In manual mode the digitizer is initialized to put all video input to digitizer RAM (command 1) and when user hits a key this process is terminated (command 0) and data is copyed to screen. This way you can define accurate frame, you want to get. In short kind of: Automatic = get next frame, Manual = get last frame. In BASIC MD is used to digitize to digitizer RAM and AD is used to copy the data also to VDP, but this is an other thing...

Quote:

I suspect that there is something wrong with the camera connection. If you only wait in the menu long enough (this can be quite a while) you should get the grey "no video signal" screen.

I thought something like this as well, but when I didn't get any reaction after 30 minutes, I gave up. BTW If digitize routine is in loop it updates still one frame after I enable the screen before it hangs.

When screen is disabled I get very good looking pictures with the software.
Your YJK conversion looks very nice!

Just idea... In future versions, you could also check, that if there is picture > 512*424 available, you could enable interlaced digitize. (Digitize only every other picture) BTW I still don't know, are the last 44 lines digitized by real thing or not...

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...

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? Have you tried disabling sound output, using the raw unzoomed rendering mode and increasing frame skipping in the emulator if that would help? Just guessing if your problems would be speed related some or all of these actions separately or together might have some effect.