OpenHandhelds.org

I've been having a look at the how the Jz4740 works and there is for sure a nice 8-bit video mode.
However, the Dingux kernel doesn't currently support this so perhaps the easiest thing would be to do ourselves?

From what I understand the JX4740 uses frame descriptors to instruct DMA to copy the contents of the framebuffer and/or palette to the LCD controller. Currently, this is setup to be a single 16-bit framebuffer.

Would it be possible to:

[*] save the current 16-bit FB descriptor
[*] set-up a new palette descriptor
[*] set the LCDCTRL to the right 8-bit format
[*] change the LCDDA0 register to point to the new descriptor

Any suggestions? Stop/Pause LCD DMA first?

I think this isn't a viable approach. The LCD controller (ILI9331 or similar) doesn't actually support paletted framebuffers natively. There are 8-bit and 9-bit transfer modes, but they operate by requiring you to send 16-bit or 18-bit RGB data over two data transfers. In other words, it's just a more narrow bus. For some reason, the Jz4740's on-chip LCD controller isn't being used - probably because it's being used with 240x320 LCDs. This seems to be the root of a number of Dingoo's current problems.

I don't have the Jz4740 databook anymore and can't find it, but just from browsing the peripheral list in the datasheet it doesn't look like there's a display controller capable of converting 8bpp paletted data to 16bpp RGB output for the external LCD controller. The closest is the IPU which is listed as providing YUV colorspace conversion.

Having said that, you may not find 8bpp mode to be worth that much, although it depends on the application. If you can draw to the paletted colorspace directly then you'll have a relatively slight performance improvement by not having to do the palette lookup in software, but if you have to convert anyway (like for instance in an NES emulator, going from tiles/sprite indexes to the 56 color NES palette) then you'll be saving very little. Even though the framebuffer would be half the write width, so long as you're not starving the writebuffer (I assume there's a writebuffer on the CPU) and you write non-cached then the results should be about the same, unless the renderer is very memory bandwidth limited.

Yes, there is a lot of confusion since a lot of people forget about ILI9331/9325. Jz4740 indeed does support 256 colors on the LCDC interface, ILI controllers do not have this mode and they are connected over SLCD interface so we can't have it on LCD. However the TV-out is connected to builtin controller so 256 mode (and hopefully full PAL/NTSC resolution) should be doable with TV-out.

http://www.mediafire.com/download.php?djnnnmnojzd

Thanks. I found it after posting though ;D

Too bad it's not like the Wiz, which has a display controller capable of color space conversion amongst other things. Actually, it seems like the Wiz has a lot more chipset functionality in general.

How utterly annoying. Why are they not using the built in LCD controller?
I'd assume that the 240x320 are cheaper because they are just mobile phone screens?
Anyway, it may be no great loss then as Exophase points out. Thanks everyone for the information.

They are using it for tv-out.

Well actually LCDC and SLCD interfaces are shared (at least the data pins) so maybe even ILI controllers can be used in LCDC mode but it is suboptimal and it is not how it is done now.

yes, and while doing the pallete lookup and pixel translation in software, one can include screen rotation so we can hopefully get rid of diagonal tearing (when linux kernel supports native 240x320 resolution)