Symbian emulator?

Página 55/73
48 | 49 | 50 | 51 | 52 | 53 | 54 | | 56 | 57 | 58 | 59 | 60

Por jr

Champion (379)

Imagen del jr

10-01-2005, 10:39

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

Por jr

Champion (379)

Imagen del jr

10-01-2005, 16:40

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.

Por snout

Ascended (15187)

Imagen del snout

10-01-2005, 18:30

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

Por Manuel

Ascended (19224)

Imagen del Manuel

10-01-2005, 19:47

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

Por jr

Champion (379)

Imagen del jr

11-01-2005, 10:06

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.

Por Manuel

Ascended (19224)

Imagen del Manuel

11-01-2005, 19:40

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.

Por rlyeh

Supporter (1)

Imagen del rlyeh

11-01-2005, 23:09

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

Por NYYRIKKI

Enlighted (6011)

Imagen del NYYRIKKI

12-01-2005, 13:11

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

Por jr

Champion (379)

Imagen del jr

12-01-2005, 13:34

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 =)

Por jr

Champion (379)

Imagen del jr

12-01-2005, 13:41

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.

Página 55/73
48 | 49 | 50 | 51 | 52 | 53 | 54 | | 56 | 57 | 58 | 59 | 60