How the EPSON S2D13A05 is connected and controlled by MAC7116 in preFL Convers+

[Go4IT]

Ursadon wrote a while ago:

There is a video buffer in this memory area: 0x20200000 - 0x20217700
0x17700 = 96000 = 400px*240px
The data is already RLE-unpacked, it remains only to compare with the LUT table, to make a RGB8 picture.

What a pitty Ursadon seems no longer interested in our audience here, so i can't ask him how he achieved that information

I'm investigating i n the hardware part to find out how the MAC micro is connected to the EPSON controller. What i could find out was that the S2D13A05 is a automotive version of the S1D13A05 chip, where a datasheet is available.
Unfortunately this one seems to only be availabe in a BGA case, whereas the one used inside the Convers+ is a SOP one, so i can't use the pinout described there.

epson_s2d13a05f00a1.jpg

The controller has it's own on-chip buffer memory (datasheet says: "The S1D13A05 display buffer is 256K bytes of embedded SRAM") and i bet both are DMA connected, so the firmware accesses the controllers framebuffer by simple IO commands.

[DGAlexandru]

Let's hope that Convers's S2D13A05 is not only the automotive part of S1D13A05 but it also has some different hardware capabilities, as the later one may only know a 320x240 max resolution:

S1D13A05 display modes.jpg

.. but still, there are some usefull information like how LUT (RGB table) is used (now I wander again why in the FW we have BGR table instead of RGB) and also that you can stream directly the color of pixel without using a RGB table and this way you can achieve that 64k color range instead of only 256 colors:

S1D13A05 color mode.jpg

Another interesting aspect is this:

S1D13A05 HW config mode.jpg

from which, if it is preserved to S2D13A05 we might have a clue how MAC7116 is configured to talk with S2D13A05.
.. and which might explain why we have a bad picture when we use FaceLift FW in PreFaceLift Convers - maybe S2D13A05 is configured in another way in order to be compatible with the FL LCD and then MAC7116 also is sending the data to S2D13A05 in that way.

[Stevebe]

The PIP function looks interesting if it could be set in the REG has anyone tried to access the Epsom chip vua the CPU
Or does it have its own,port, I see the none automotive version as a USB port that can be configured, will have to sit down
With convers and try plot out the connections ,,

[DGAlexandru]

I did a JTAG dump of that memory range then save it as a file that I opened in Convers IMG Hacker (after adding a small function to load a file and pass it directly to the function that displays it):

DMA_0x20200000-0x20217700.jpg

it seems that it is a little bit bigger than 240px .. I'll do some tests to see how big it is..
I think the numbers show it is a 400x240picture in RGB8 (96000 = 400px*240px), but if we take into consideration that we're not using the entire 8 bits, and only 6, we could have a bigger one.

LE: Never mind, my bad The place where I was showing the image was designed (by me) to be 400x200 - the max size of the images we play with... so those extra 40px couldn't fit in

DMA_0x20200000-0x20217700_size.jpg

[Stevebe]

Is this a dump of the screen buffer ?
Using JTAG via MCU To read the Epsom did you use flash or commander . Can we also read ThenRegisters ,

[DGAlexandru]

And a JTAG dump after Convers has been fully initialized:

DMA_0x20200000-0x20217700_run.jpg

I'll try to halt the CPU when we have another image (warning from ACC radar for example) placed over the "car" to see if it recreates the entire image in this DMA buffer or it uses one of the EPSON features to only send what needs to be added to the output of display.
If the image is recreated by MAC and then send to EPSON, then the MAC FW is a little bit easier to understand, because the communication with EPSON is also easier - using only one function to create and send the image, and it also means that there is sufficient processing power and bandwidth.
If the images isn't recreated by MAC and it only sends what needs to be added to the output of display (either using PIP or the other available functions), then the processing power of MAC and bandwidth between it and EPSON needs fine tuning.

DMA_0x20200000-0x20217700_run_eng.jpg

[DGAlexandru]

Dump of the memory address 0x20200000 - 0x20217700
This is DMA of MAC7116. It starts from0x20 00 00 00.

JTAG - let the CPU run, send some CAN commands to wake Convers, halt the MAC, then dump&save the contents of memory range.

[Stevebe]

Are ok cool is it Big Endian as it’s reading the DMA,

[Go4IT]

Yes, everything BE. We should identify the wireing between those both and could then gather the full use address range to find registers. Also look at FW addresses in this range (IDA is or friend) to find the FW functions handling the graphics.

With this chip, there are plenties of new possibilities, not only screenshots but small videos without using a cam.

PIP and high res (suiteable for startup picts) are a nice benefit.

[DGAlexandru]

not only screenshots but small videos without using a cam.

For this you would need to be able to dump in real time the DMA contents from that range, by using JTAG, without having to HALT the CPU... which I don't think is possible... the same with RAM. You can do real-time dump of only one byte.

.. or am I missing something?

I've uploaded the new version of CH that has this RAW image process implemented.