Each image you make on the device do generate two files, a .pix file that store the final image, and a .dat file which is the history of the image, you can use it to create animation and also the device use it to have a redo function.

Here is an example of one image preloaded on the device, and the animation going with it.
Yes the history do show things that was deleted in the final image, it is quite interesting.

And last for now, here is the link to the GitHub that have all the info I've published up so far: https://github.com/Godzil/MB701-Reverse

Near completion: PIXB and PTCR file format and sample tool to deal with them
To be done: The BLE protocole, Update file format, Hardware reference.

And if you fancy helping, especially on the update format, you are more than welcome! I'll probably setup a shared ghidra repository for that.

And guess what? Just found a bug 😃

The history format do store a full stroke of pixel, and I way the command is made it can only store up to 255 pixel in one stroke. And found two problem, It seems they are not storing the number of pixel on 8bit, but less (some history file have a too low number of pixel and there are less than 255) making the history to not work properly, and if a stroke is really too long, the firmware just crash, most likely a buffer overflow 😄

I suspect them to have a fixed size array to store the draw pixel position and do not check if the stroke get too long by splitting it, and the array get overflowed.

I'm sadly not far enough on the reverse of the firmware update format to know how to extract the app binary and check that, but that's the best explanation up so far on what is happening.

How to not crash it? Avoid long stroke 🙂