Caanoo / WIZ Latest Firmware Of Wiz (info For Devs)

[WarmFluffyUK]

I have just received some info from GPH that they want me to pass on, so I cut and pasted it here:

In case of the latest firmware of Wiz, frame buffer of AMOLED is set in 240x320 mode. Existing contents of 320x240 mode are converted by SDL library or GLBasic graphic library etc into 240x320 when contents are played.

In case of graphic library that does not convert 320x240 into 240x320 mode or in case when the contents are sensitive to delay caused by converting, you will need to do following process.
(occasional bug of fleeting white diagonal line may follow)

(1) In case of application which use SDL: functions that support sdl

CODE

#define LCD_DIRECTION_ON_CMD 5
#define LCD_DIRECTION_OFF_CMD 6




(1.1) when converting into 320x 240 mode
CODE

SDL_SetLcdChange(LCD_DIRECTION_ON_CMD,0);




(1.2) when re-converting back into 240 x 320 mode
CODE

SDL_SetLcdChange(LCD_DIRECTION_OFF_CMD ,0);




(2) In case of applications that do not use SDL: call video driver to convert

CODE

#define FBIO_LCD_CHANGE_CONTROL _IOW(FBIO_MAGIC, 90, unsigned int[2])
#define LCD_DIRECTION_ON_CMD 5
#define LCD_DIRECTION_OFF_CMD 6
static int fb_fd;




(2.1) when converting into 320x 240 mode
CODE

{
unsigned int send;
send[0] = LCD_DIRECTION_ON_CMD;
send[1] = 0;
fb_fd = open ("/dev/fb0", O_RDWR);
ioctl(fb_fd, FBIO_LCD_CHANGE_CONTROL , &send);
close(fb_fd);
}




(2.2) when re-converting back into 240 x 320 mode
CODE

{
unsigned int send;
send[0] = LCD_DIRECTION_ON_CMD;
send[1] = 0;
fb_fd = open ("/dev/fb0", O_RDWR);
ioctl(fb_fd, LCD_DIRECTION_OFF_CMD ,&send);
close(fb_fd);
}

 

[Quiest]

When exactly is the right time to do this converting?
Also, wasn't this a problem on the BLU+ back in the GP32
days?

 

[notaz]

I think (and hope) this only means that LCD/display controller supports both landscape and portrait modes, not that they are going to switch to portrait framebuffer layout in hardware.

So the firmware starts in portrait 240x320 mode (why?), and you now need to switch to landscape 320x240 mode in your code on startup.

 

[Squidge]

It certainly is a bit odd. Why would you ever want to use 240x320 mode, and why does the firmware default to this? I would have thought the ioctl call would be one of the first things done by the firmware. Doing it in your app means if your app crashes you end up with a corrupted display when the menu reloads and you need to reset to get back to normal.

 

[Orkie]

Because under very specific conditions (a very quick change from total black to total white or vice versa) you sometimes get a slight diagonal line for a brief moment. I think it was decided that it was a bug in the display controller or something, but I am still not totally convinced. But anyway, 240x320 mode does not ever have the line, where 320x240 does. Maybe somebody will be able to find out what causes it when more hardware is out there; I have tried tweaking the display timings to no avail but it could be something totally different causing it.

The display controller itself supports 240x320 in both directions as well as 320x240 in both directions.

 

[slaanesh]

The 240x320 modes may be useful for portrait games (like those found in Final Burn or MAME).

 

[DaveC]

I think (and hope) this only means that LCD/display controller supports both landscape and portrait modes, not that they are going to switch to portrait framebuffer layout in hardware.

So the firmware starts in portrait 240x320 mode (why?), and you now need to switch to landscape 320x240 mode in your code on startup.

I remember the GP32 was like that, the hardware scanned vertical (across the 240 resolution). It caused hell for people trying to code raster support in emulators as it would have to check the pallet switch per pixel instead of per line. Rasters interrupt effects in emus were impractical, but in that case the CPU was only 133 MHz.

Why is it like that? Because it was GP and now GPH, expect the unexpected

 

[Franxis]

Why is it like that? Because it was GP and now GPH, expect the unexpected

Orkie says that the controller supports 240x320 and 320x240 in all directions <_< .

I know more or less what to expect from GPH, because there are some positive opinions from people using the prototypes. The Wiz seems good B) .

But i really don't know what to expect from the Pandora, because there are nor prototypes not opinions yet h34r: .

 

[Squidge]

Orkie says that the controller supports 240x320 and 320x240 in all directions <_< .

He also says there's a bug in the display controller which only rears its head when in 320x240 mode...

 

[Exophase]

It's not that huge of a deal from a performance standpoint. You just end up rendering from top to bottom instead of up or down if it doesn't make sense to rotate the source (like for emulating raster effects). The only downside of this is that it's less friendly on stms or a coalescing write buffer, but it's difficult to render something complex with stms and Wiz's CPU probably doesn't have a coalescing write buffer. This is assuming that the framebuffer is only written to - if you need a buffer you can read from then you have bigger problems since this layout is cache unfriendly too.

 

[sam fisher]

Orkie says that the controller supports 240x320 and 320x240 in all directions <_< .

He also says there's a bug in the display controller which only rears its head when in 320x240 mode...

But that is hardly GPH's fault, it is a hardware fault.

 

[Squidge]

But that is hardly GPH's fault, it is a hardware fault.

Yes, and one I would have thought GPH would have noticed a long time ago in prototype stage, enough time to find another display controller without such faults.

 

[DaveC]

But i really don't know what to expect from the Pandora, because there are nor prototypes not opinions yet h34r: .

There are Pandora prototypes and there are opinions too, some coders have them. Basically all hardware is done, it just needs a case now which is close to finished as well.