Emulating Moto v710 | developer.brewmp.com Emulating Moto v710 | developer.brewmp.com

Developer

Emulating Moto v710

Forums:

Am I correct in my assumption that it is currently impossible to emulate the v710 with the current emu/simulators?

The phone has an 18-bit display and none of the emulators seems to be able to create anything remote to that. Neither 18-bit, 24-bit nor 32-bit modes seem to be supported as far as I can see.

Am I missing something? If not, when will we see an update in the emulator to properly support this display mode?

The 3.0 simulator supports both 18- and 24-bit modes. Though with any skin greater than 16-bit, apps start out in 16-bit mode by default. You can specify a different mode in your app's MIF, or you can change the mode dynamically with IDISPLAY_SetPrefs().

The 3.0 simulator supports both 18- and 24-bit modes. Though with any skin greater than 16-bit, apps start out in 16-bit mode by default. You can specify a different mode in your app's MIF, or you can change the mode dynamically with IDISPLAY_SetPrefs().

Yeah, I figured the conversion to 16-bit but that's not what I was looking for. I was looking for a way to actually debug an 18-bit or 24-bit color format.
Well, I did it on the phone directly instead, which of course is a bit more tedious, but within 10 minutes I had my blitters and stuff back up and running again on that phone.

Yeah, I figured the conversion to 16-bit but that's not what I was looking for. I was looking for a way to actually debug an 18-bit or 24-bit color format.
Well, I did it on the phone directly instead, which of course is a bit more tedious, but within 10 minutes I had my blitters and stuff back up and running again on that phone.

In V710 conversion from 16 bit to 18bit causes performance issue in some cases. We have done direct rendering in 18 bit (lower 18 bits BGR) and that provides satisfactory result.

In V710 conversion from 16 bit to 18bit causes performance issue in some cases. We have done direct rendering in 18 bit (lower 18 bits BGR) and that provides satisfactory result.

Yeah, that's what I'm doing. The internal display memory layout of the handset is actually full 32-bit. What a waste, doubling the memory bandwidth for two lousy bits. At least they should have made it full 24-bit instead of 18.
Ah, whatever, like I said, it took me a mere 10 minutes to make my blitters work with 32-bit pixels instead of 16-bit.

Yeah, that's what I'm doing. The internal display memory layout of the handset is actually full 32-bit. What a waste, doubling the memory bandwidth for two lousy bits. At least they should have made it full 24-bit instead of 18.
Ah, whatever, like I said, it took me a mere 10 minutes to make my blitters work with 32-bit pixels instead of 16-bit.

Dragon wrote:Yeah, I figured the conversion to 16-bit but that's not what I was looking for. I was looking for a way to actually debug an 18-bit or 24-bit color format.
I don't follow. You can emulate 18-bit color in 32-bit pixels. You just need to set the skin file for 18-bit, and edit your MIF to cause your app to be started in 18-bit mode.

Dragon wrote:Yeah, I figured the conversion to 16-bit but that's not what I was looking for. I was looking for a way to actually debug an 18-bit or 24-bit color format.
I don't follow. You can emulate 18-bit color in 32-bit pixels. You just need to set the skin file for 18-bit, and edit your MIF to cause your app to be started in 18-bit mode.

I have no idea what you're talking about. Since when does the MIF file contain any device specific information or switches?

I have no idea what you're talking about. Since when does the MIF file contain any device specific information or switches?

Dragon wrote:Yeah, that's what I'm doing. The internal display memory layout of the handset is actually full 32-bit. What a waste, doubling the memory bandwidth for two lousy bits. At least they should have made it full 24-bit instead of 18.
According to Motorola, the LCD internally supports 18 bit/pixel, so Motorola wanted to provide best possible display quality.
When I compare V710 (with 18 bit display) with LG 7000 (with 16 bit display), I don't see any noticable difference, hope Motorola had good reason for that.

Dragon wrote:Yeah, that's what I'm doing. The internal display memory layout of the handset is actually full 32-bit. What a waste, doubling the memory bandwidth for two lousy bits. At least they should have made it full 24-bit instead of 18.
According to Motorola, the LCD internally supports 18 bit/pixel, so Motorola wanted to provide best possible display quality.
When I compare V710 (with 18 bit display) with LG 7000 (with 16 bit display), I don't see any noticable difference, hope Motorola had good reason for that.

Dragon,
On the "Notifications/Flags/Settings" dialog, you'll notice in the upper right you can set the color depth for each of the available displays.
At least in the 3.0 MIF editor you can.

Dragon,
On the "Notifications/Flags/Settings" dialog, you'll notice in the upper right you can set the color depth for each of the available displays.
At least in the 3.0 MIF editor you can.

Dragon wrote:I have no idea what you're talking about. Since when does the MIF file contain any device specific information or switches?
Since 3.0, you can specify display settings. If you click the "Notifications, Flags, Settings..." button, you will get a dialog that allows you to specify display dimensions. For instance, you can specify that display 1 should use the maximum color depth, and then you'll get 18-bit color depth when your run your app on an 18-bit skin.
I don't know of any devices on the market that support multiple display modes, but the simulator does.

Dragon wrote:I have no idea what you're talking about. Since when does the MIF file contain any device specific information or switches?
Since 3.0, you can specify display settings. If you click the "Notifications, Flags, Settings..." button, you will get a dialog that allows you to specify display dimensions. For instance, you can specify that display 1 should use the maximum color depth, and then you'll get 18-bit color depth when your run your app on an 18-bit skin.
I don't know of any devices on the market that support multiple display modes, but the simulator does.

I see. I am not using the 3.0 SDK so I have not checked out the 3.0 MIF Editor in months either, hence the oversight.

I see. I am not using the 3.0 SDK so I have not checked out the 3.0 MIF Editor in months either, hence the oversight.

ruben wrote:According to Motorola, the LCD internally supports 18 bit/pixel, so Motorola wanted to provide best possible display quality.
When I compare V710 (with 18 bit display) with LG 7000 (with 16 bit display), I don't see any noticable difference, hope Motorola had good reason for that.
Going from RGB565 to RGB666 gives you one bit more resolution in the Blue and Green spectrum. Since the human eye is not nearly as sensitive to blue shifts than to green for example, it is entirely redundant to increase the resolution of blue without also increasing the resolution of the green channel. The human eye sees red a bit better than blue but still not nearly as well as green. So, in essence doing RGB666 will not give you any noticeable improvement and it's just an improvement in the tech specs, nothing else.
Again I think it's ridiculous to do this as it doubles the memory bandwith because each pixel is now represented as a 32-bit value as opposed to 16-bit - and that in an environment where devices are constantly strapped for both memory and processing power. This is a typical *engineering* decision that has nothing to do with real-life benefits, unfortunately.

ruben wrote:According to Motorola, the LCD internally supports 18 bit/pixel, so Motorola wanted to provide best possible display quality.
When I compare V710 (with 18 bit display) with LG 7000 (with 16 bit display), I don't see any noticable difference, hope Motorola had good reason for that.
Going from RGB565 to RGB666 gives you one bit more resolution in the Blue and Green spectrum. Since the human eye is not nearly as sensitive to blue shifts than to green for example, it is entirely redundant to increase the resolution of blue without also increasing the resolution of the green channel. The human eye sees red a bit better than blue but still not nearly as well as green. So, in essence doing RGB666 will not give you any noticeable improvement and it's just an improvement in the tech specs, nothing else.
Again I think it's ridiculous to do this as it doubles the memory bandwith because each pixel is now represented as a 32-bit value as opposed to 16-bit - and that in an environment where devices are constantly strapped for both memory and processing power. This is a typical *engineering* decision that has nothing to do with real-life benefits, unfortunately.

That is the reason for the display mode feature in 3.0. That idea is that it's more efficient overall to render into a 16-bit bitmap and copy it to an 18-bit LCD controller, than to render into a 18-bit (really 32-bit) bitmap and copy it to an 18-bit LCD controller.
So, by default, apps get the more efficient 16-bit mode, but they can use the 18-bit mode if they really want it.

That is the reason for the display mode feature in 3.0. That idea is that it's more efficient overall to render into a 16-bit bitmap and copy it to an 18-bit LCD controller, than to render into a 18-bit (really 32-bit) bitmap and copy it to an 18-bit LCD controller.
So, by default, apps get the more efficient 16-bit mode, but they can use the 18-bit mode if they really want it.

I see. Thanks a bunch for the info. That could actually turn into a pretty useful feature once handsets begin supporting those flags in practice.

I see. Thanks a bunch for the info. That could actually turn into a pretty useful feature once handsets begin supporting those flags in practice.

Hi,
I installed the emulator files for Moto v710 in BREW 2.1. When I change the device to Moto v710, it says "failed to innitialize the device. There may be syntax error in the phone config file...". What wrong with it?
Thank you.

Hi,
I installed the emulator files for Moto v710 in BREW 2.1. When I change the device to Moto v710, it says "failed to innitialize the device. There may be syntax error in the phone config file...". What wrong with it?
Thank you.

The screen depth on the skin was changed to be 18 bit (to match the actual phone), unfortunately this isn't supported prior to 3.0. You can either run this skin on the 3.0 Simulator, or change the bit depth to 16 using the device configurator. I've added a readme file to the skin package to prevent any further confusion.

The screen depth on the skin was changed to be 18 bit (to match the actual phone), unfortunately this isn't supported prior to 3.0. You can either run this skin on the 3.0 Simulator, or change the bit depth to 16 using the device configurator. I've added a readme file to the skin package to prevent any further confusion.

Hi,.
We have decoded a JPEG image in Motorola V710 and are facing the following issues :
1] When we decode data, each pixel in the IDIB structure is of 32 bit value. Are the 18 bit RGB data stored as
NULL-RED-GREEN-BLUE?
NULL-BLUE-GREEN-RED?
RED-BLUE-GREEN-NULL?
BLUE-GREEN-RED-NULL?
From which bytes can we access the RGB data in 565 or 666 format.
Thanks

Hi,.
We have decoded a JPEG image in Motorola V710 and are facing the following issues :
1] When we decode data, each pixel in the IDIB structure is of 32 bit value. Are the 18 bit RGB data stored as
NULL-RED-GREEN-BLUE?
NULL-BLUE-GREEN-RED?
RED-BLUE-GREEN-NULL?
BLUE-GREEN-RED-NULL?
From which bytes can we access the RGB data in 565 or 666 format.
Thanks

565 r<<11 + g <<5 + b
666 r << 12 + g << 6 + b
or in other words
.................LSB-|
565 ..RRRRRGGGGGGBBBBB 16 bit
666 RRRRRRGGGGGGBBBBBB 32 bit

565 r<<11 + g <<5 + b
666 r << 12 + g << 6 + b
or in other words
.................LSB-|
565 ..RRRRRGGGGGGBBBBB 16 bit
666 RRRRRRGGGGGGBBBBBB 32 bit

Hi charlie ,.
Thanks for your help,.got the decoder working on V710 :)

Hi charlie ,.
Thanks for your help,.got the decoder working on V710 :)

Thanks for all the posts. They were helpful in me getting my v710 problems resolved.
One reason I could think that they chose a 32-bits/pixel for 18-bit is that it makes writing pixels faster than if you use 24-bit. If you use 32-bits, you can write a single uint32 value instead of 3 single ubyte values. So, if you store your color value in a uint32 using only 18-bits, you would have to separate each color channel and write them individually for 24-bits/pixel. Even if you use individual red,green,blue, or a 24-bit RGB in a uint32, you would have to write each channel individually.
With 32-bit addressing you can keep it in a nice uint32 and write in 1 operation. This of course assumes you already have 18 bits in your uint32.
If you are using 8-bit images, you have to convert each RGB color in the palette to an 18-bit value. But, if, when loading images, instead of when you draw, you generate an 18-bit pallette in a uint32 for each palette entry, then it should be very fast.
It works well for me and it is quite fast.
Cheers

Thanks for all the posts. They were helpful in me getting my v710 problems resolved.
One reason I could think that they chose a 32-bits/pixel for 18-bit is that it makes writing pixels faster than if you use 24-bit. If you use 32-bits, you can write a single uint32 value instead of 3 single ubyte values. So, if you store your color value in a uint32 using only 18-bits, you would have to separate each color channel and write them individually for 24-bits/pixel. Even if you use individual red,green,blue, or a 24-bit RGB in a uint32, you would have to write each channel individually.
With 32-bit addressing you can keep it in a nice uint32 and write in 1 operation. This of course assumes you already have 18 bits in your uint32.
If you are using 8-bit images, you have to convert each RGB color in the palette to an 18-bit value. But, if, when loading images, instead of when you draw, you generate an 18-bit pallette in a uint32 for each palette entry, then it should be very fast.
It works well for me and it is quite fast.
Cheers

depends on the bus size, if 16 or 32 bit writes are faster, the 32 bit could be split into two 16 bit writes , plus there is also how the lcd controller wants the data.

depends on the bus size, if 16 or 32 bit writes are faster, the 32 bit could be split into two 16 bit writes , plus there is also how the lcd controller wants the data.

Hi All,
We have developed an aplication,which needs to be submitted for TBT(V710),so continuation with this thread.When we submitt our app for TBT,will NSTL test the emulator version of the package(WIN) on BREW 2.1 SDK or BREW 3.1 SDK.
As,the development needs to be done on 18 bit display,so we have done all the development on BREW 3.1 SDK and testing of memory leaks on BREW 2.1.
So,on which SDK will NSTL Test.???
ibrew

Hi All,
We have developed an aplication,which needs to be submitted for TBT(V710),so continuation with this thread.When we submitt our app for TBT,will NSTL test the emulator version of the package(WIN) on BREW 2.1 SDK or BREW 3.1 SDK.
As,the development needs to be done on 18 bit display,so we have done all the development on BREW 3.1 SDK and testing of memory leaks on BREW 2.1.
So,on which SDK will NSTL Test.???
ibrew

you can request a version

you can request a version

Hi
how can a developer request,saying that a particular handset has to be tested onto a particular SDK.??
do we need to specify it in a document,which we submit to NSTL..?
thanks
ibrew

Hi
how can a developer request,saying that a particular handset has to be tested onto a particular SDK.??
do we need to specify it in a document,which we submit to NSTL..?
thanks
ibrew

markb wrote:I don't follow. You can emulate 18-bit color in 32-bit pixels. You just need to set the skin file for 18-bit, and edit your MIF to cause your app to be started in 18-bit mode.
How can i set the bit depth in the skin file? I managed to set it in the MIF... but i dont know how to set it in the QSC file...
Btw, is it normal that i dont have the MIF editor in the 3.1.4 SDK? I only have it in the 3.0.1 one...
Thanks

markb wrote:I don't follow. You can emulate 18-bit color in 32-bit pixels. You just need to set the skin file for 18-bit, and edit your MIF to cause your app to be started in 18-bit mode.
How can i set the bit depth in the skin file? I managed to set it in the MIF... but i dont know how to set it in the QSC file...
Btw, is it normal that i dont have the MIF editor in the 3.1.4 SDK? I only have it in the 3.0.1 one...
Thanks