Modifying RAM_DL on the fly

[obones]

Hello,

I have read the documentation where it is said that the BT817 chip is not using a frame buffer, but rather computing each pixel value from items in RAM_DL every time it sends RGB values to the attached LCD.
This gave me the idea to create a display list with the coprocessor, wait for it to have done its job, and then change VERTEX2F values directly into RAM_DL to achieve some nice animation effects without having to resend the entire display list.

So now, in my application, I start with the "main" display list that looks like this:

Code Select Expand


CMD_DLSTART
CLEAR_COLOR_RGB(255,255,255)
CLEAR(1, 1, 1)
COLOR_RGB(0, 0, 0)
CMD_TEXT(100, 100, 29, 0, "Welcome")
DL_DISPLAY
CMD_SWAP



Then after the user has interacted properly with the device, I start a new display list:

Code Select Expand


CMD_DLSTART
CLEAR_COLOR_RGB(0,0,0)
CLEAR(1, 1, 1)
VERTEX_FORMAT(0)
COLOR_RGB(255, 255, 255)
CMD_TEXT(400, 200, 24, OPT_CENTER, "Star field")
POINT_SIZE(32)
BEGIN(POINTS)
VERTEX2F(150,200);
VERTEX2F(450,380);
VERTEX2F(500,20);
VERTEX2F(400,250);
VERTEX2F(50,300);
VERTEX2F(600,400);
END
DISPLAY
CMD_SWAP


With this, I get a nicely written text with a 6 points, all white on a black background, as expected.

After having waited for the co processor to do its, I now use host memory read to look for 0x1F000002 starting at RAM_DL as this would be the location of the BEGIN(POINTS) command. Then I add another 4 bytes to skip the actual command and this gives me an address not too far from 0x300000

Now that I have the address for the first of the six points, I replace the values at those RAM locations at regular intervals with new VERTEX2F commands so as to make the points move.

But to my great dismay, this does not have any effect on the image rendered on the LCD.
I went back to the programming guide which mentions the REG_DLSWAP register which is to be used to signal that a new frame should be taken into account.
So I tried waiting for it to become 0, then write 2 (or even 1) inside it like in this "pseudo" code:

Code Select Expand


                for (int stepIndex = 0; stepIndex < 100; stepIndex++)
                {
                    usleep(50 * 1000);
                    while (EVE_memRead32(REG_DLSWAP) != EVE_DLSWAP_DONE);
                    for (int starIndex = 0 ; starIndex < starsCount; starIndex++)
                    {
                        stars[starIndex].X += stars[starIndex].deltaX;
                        stars[starIndex].Y += stars[starIndex].deltaY;

                        EVE_memWrite32(starsRAMAddress + starIndex * sizeof(int32_t), VERTEX2F(stars[starIndex].X, stars[starIndex].Y));
                    }
                    EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);
                }


But this did not have the expected effect as it made the previous display list come back, then the star field one, then the white one and so on, each being activated in turn for the duration of the loop step. As I wait for 50milliseconds at each step, this causes quite a bit of flickering.

I must have missed something here, but what?
I really thought I would be able to perform fast animation by direct RAM_DL manipulation, but right now, I'm quite stuck.

Thanks for any suggestion

[darkjezter]

RAM_DL is essentially double buffered, so when you build up a list in RAM_DL, you're not updating the display at all until you call SWAP.

So basically, there are 2 independent sets of display list memory.  One which is accessible via RAM_DL, while the other is being used to scan out pixels.  When the swap is processed, those two lists trade places.

In theory, if you populate both copies with your template display list, and manipulate the vertex locations before calling swap then you should be able to achieve what you're going for.

However, this a detail in how the BT815 happens to be implemented, however it is not an explicit part of the specification.  What this suggests is that the BT817 may or may not work the same way, and further that even if it does, you cannot rely upon future iterations of the EVE series to behave this same way.  While you can probably get it to work in RAM_DL as you're trying (if you observe the two separate pages of RAM_DL) there is an option that is within spec, and therefore, is more likely to be 'future proof'

Instead of keeping your 'template' display list in RAM_DL, you can either generate it or copy it in RAM_G, and then use existing commands to have the coprocessor copy RAM_G to RAM_DL.  The benefit here, aside from it being fast and within spec, is you wind up with 1 master copy of your display list, instead of 2 copies, each a frame behind the latest displayed.

[BRT Community]

Hello,

RAM_DL is indeed double buffered and we agree that editing it is not the best way to do it. There are two techniques in the application note in following link you can try - https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_340_FT800_Optimising-screen-updates-with-Macro-and-Append.pdf.

The BT series have additional features which extend this to storing on flash and to storing commands rather than display list items.

Best regards

BRT Community

[obones]

Thanks, this confirms my impression of how it is built and you are right, relying on an implementation detail is not desirable.

I read the application note and both techniques are indeed interesting.
However, as I am using a BT817, I went another route with the use of CMD_NEWLIST to place the VERTEX2F items into RAM_G and then call them from my display list with CMD_CALLLIST.
I thought that this would allow direct modification of the RAM_G content but still, no luck. Apparently, the content of the list is read from RAM_G when the swap is done, not at every raster scan, contrary to what is done for bitamps for instance.

But I went further and used CMD_NEWLIST twice: the first contains the VERTEX2F commands, while the second contains the rest of the display items along with CMD_CALLLIST
Then, at every step of my "animation", I modify the VERTEX2F values in RAM_G and create this display list:

Code Select Expand

CMD_DLSTART
CMD_CALLLIST(BaseListAddr)
DL_DISPLAY
CMD_SWAP

This is not as simple as I would have liked, but at least it works.

[BRT Community]

Hi,

I'm glad to hear you got it working!

As you mentioned, the call list and append work differently compared to editing a live bitmap and are intended for constructing a display list. The macro feature would be ideal for your requirement however there are only two of these.

The device has other features such as animation but for the vertex method it sounds like you have found a good solution.

Best regards

BRT Community

[Spyy]

Thanks, this confirms my impression of how it is built and you are right, relying on an implementation detail is not desirable.

I read the application note and both techniques are indeed interesting.
However, as I am using a BT817, I went another route with the use of CMD_NEWLIST to place the VERTEX2F items into RAM_G and then call them from my display list with CMD_CALLLIST.
I thought that this would allow direct modification of the RAM_G content but still, no luck. Apparently, the content of the list is read from RAM_G when the swap is done, not at every raster scan, contrary to what is done for bitamps for instance.

But I went further and used CMD_NEWLIST twice: the first contains the VERTEX2F commands, while the second contains the rest of the display items along with CMD_CALLLIST
Then, at every step of my "animation", I modify the VERTEX2F values in RAM_G and create this display list:

Code Select Expand

CMD_DLSTART
CMD_CALLLIST(BaseListAddr)
DL_DISPLAY
CMD_SWAP

This is not as simple as I would have liked, but at least it works.

Hi,

I have questions concerning cmd_calllist or append a DL from RamG...
Is there a difference between calllist and append?
Will this do a copy of the content from RamG into the display list or is this just a reference?

Thank you

Torsten

[Kaetemi]

You can create your display list as your originally planned, then swap it, and create a second duplicate of it. Then you can just edit the vertices as you planned, but then swap between the two copies of your display list each time.