MicroHacker Forum

Hey @Ursadon, you're needed here, where are gone? )

Well, the D2 series of the Epson displaycontroller chip is Automotive and may never been or not anymore publicity available. But there is a D1S13A05 we can get datasheets and even sample code for: https://www.vdc.epson.com/display-contr ... s/s1d13a05

When i look into the register table https://www.vdc.epson.com/display-contr ... ewdocument i see the LUT register takes an 8bit index and 3x 8bit data for RGB value, but where only the upper 6bits are used. Now, the LUT muss somehow be loaded by a ROM routine from DATA into the controller. I expect this table to be an indexed array of 3 bytes in a row. So to have 256 colors by 3 bytes each, make up 768 bytes in total. Because the inks uses only the upper 6 bits, the values should have bit 0 and 1 set to zero, so all values != 0 will be greater or equal 4 up to 255.

The display itself, the "TPO LTL582T-9161-1" seem to have a resolution of 480x234 pixels. In some Alichinabuyme-shops it is sold as 800x480, but i don't believe this, it be that highres Also this would be a ratio of 4:3 which is not true either. So i believe 480x234 is real.

I've made an visual approach to find the LUT. Therefore i wrote a small prog which takes 4 bytes (=word) from a bin file, assigns 2nd byte to "R", 3rd byte to "G" and 4th byte to "B" to a pixel color and draw it (4x4) on an image canvas. I made the resulting image 16 fields (16x4 pixels because of the upscale to not have a 1 pixel width) on horizontal width. So i get a "graphical" view of the data values inside the dump.

As i go through the images if found this pattern in the ROM file which looks very familiar and put the photo of the test-image on the Convers on the right. I guess i've found some, not only one, LUT table here. What do you think?

(data on the right, photo placed multiple times on the left) Looks good, eh? So the pattern a was looking for is in there. Each indexed color is made up of 4 bytes, having the first byte set to 0x00 and the following bytes are 8bit R,G,B values.

Now, i have to find which LUT is good for which image. Maybe there are color schemes or maybe the LUT can be set on different regions. I must play with it...

Really enjoyed your work, I haven’t been this deep into the convers as yet, apart re programming the 24c16A to change Km to Mph, or the tach from 6k to 8k,
From your conclusion could we load ou4 own images into the convers,
Sorry if it is a silly question ,,

Before this to work, there is a lot work to be done. But, we made the first step
Currently i am working on a way to visualzie the images. I'd like to program a tool which takes both dumpfiles and displays all the images inside, with a choosen colortable applied (like the one Alexey alias Motral did for his own). From this the tool should be able to take an arbitrary picture and convert it to the imageformat of the Convers+, replacing the original one.

For this to work there are several things to check:
1.) Does the Firmware load if the checksum at the end does not fit the mangled imagedata? I guess not, so we need to find out how to generate that checksum
2.) Can we use arbitrary color tables and do they apply on the whole screen or on a per image basis?

The images seems to be fixed size and as long as we stay there the memory layout would not change. Also most of the images are more like icons, they appear only as white shillouette.

I don’t suppose Alexey would share his programs lol..
I sort of understand what’s needed but I don’t know enough to be of much help YET,, I am reading
As much material I can find,,
So if I understand there is a LUT which holds all the colours used,
Then the image sits in a certain mem location , that data then uses the LUT
To create image, it my very basic thinking have I got that right, if I am way off please tell
So that I can correct my thinking

You are on the right track Stevebe As most of you know, images are organized by pixels in rows and columns. If you append all rows on another, beginning from the first in the upper side, you get a looong stream of pixels. These days, where memory and transmitting costs are low, image formats mostly used to define each pixels color as a set of RGB values. Each color component (red, green, blue) is defined as an 8 bit value, making up to 16 mio possible colors. So each pixel can have a color as he like.

In the old days (stevebe, you will know them, like me developers did more effort on saving storage, even for images. Also, the computers did not have such graphics capabilities like today. As i started with PCs, it was common to have an CGA card, having 16 colors at 160x200 pixels, or 4 simultaneously colors at 320x 200, which was called "high res"

Now, think of an image with limited colors, where each pixel can have one of a fixed palette inks. So each pixel only describes what ink it uses and not defines the ink itself. This leads to a needed storage of 2 bits per pixel at min. (black/white) up to 8 (or more) bits per pixel for color images. How many bits are used depends on the number of simultaneously colors you need to provide.

To get it down to bits and bytes, here is a very basic example:
You know "painting by numbers"? Imagine you have a color palette, numbered 1 to 4 and you can mix any color in each number as you like. Then you have a canvas like an excel sheet grid. To create an image you wrote a palette number into each cell. Next you fill this cell with the color of your palette. E.g. color #1 is deep red, #2 is yellow, #3 black, #4 grass green. Put deep red into each cell labeled with #1, and so forth. Got it?

To count from 0-3 (4 values) you need 2 bits. 00 = 0, 11 = 3. So your color resolution is 2 bit. The palette has a size of 4. Each palettes ink can be defined as RGB values, using 3 bytes. Now each pixel needs 2 bit to describe the ink used. If you have 10 pixels per row and 5 rows, you got 50 pixels in sum, needing 50 * 2 bits = 100 bit of storage. 100 bits fit into 84 bytes.

This is where the Convers+ comes into play, because it's graphics capabilities are limited by the LCD controller to 5 bit per color component, which makes 65536 possible colors in the color table. But i can only display 256 inks in parallel.

Go4IT wrote: ↑14 Mar 2019, 10:41 Hey @Ursadon, you're needed here, where are gone? )

The main work eats up a lot of time
But you did a great job!

When I have free time, I look at the IDA in search of the rendering function, but so far without success. I think we should try to pick up the JTAG-debugger.

Still having issues getting the right color map.
Assuming the maps starts with "00 FF 00 FF" (where the ink really is "FF 00 FF", RGB, first byte only for padding into 32 bit), i identified maps at these positions in the ROM file:
0x0006DE50
0x0006E250
0x0006E650
0x0006EA50
0x0006EE50
0x000B5DD0
But they all look different thant the original one. I attached some pictures using the map at address 0x0006DE50 in ROM. I wrote a small tool in PHP (sigh) to extract the image, the color map and build GIF images with it. Not very elegant, but it works and i will publish it as soon as it is stable.
If i look at the map, there are missing relevant colors, like yellow: Also i am missing some images (e.g. ice warner, and many other pictograms and navigation graphics). Using the LUT in the ROM file, it seems i get only a third of the images than scanning for the magic header(709 with header scanning against 209 with LUT only). The LUT i am using starts in ROM file at 0x6A9E4. Strange... but maybe the LUT only points to the start of a series of images, one which reside in some kind of array itself, where only the start address is known.

Go4IT wrote: ↑22 Mar 2019, 07:36 But they all look different thant the original one. I attached some pictures using the map at address 0x0006DE50 in ROM. I wrote a small tool in PHP (sigh) to extract the image, the color map and build GIF images with it. Not very elegant, but it works and i will publish it as soon as it is stable.
If i look at the map, there are missing relevant colors, like yellow

Try to swap R and B color channel
What version of flash are you using?

OH, caching was cheating on me. In fact i did try all combinations, but for some reason always got the same result.
NOW, it's working. Thanks for pointing this out, man!