Strange issue with random-black-pixels on HW-X

[KryptonicDragon]

I'm new to working with ndless, so I don't know if I'm doing something wrong or if this is an Ndless issue. Either way, I need help.
Here is my code: https://drive.google.com/open?id=1ywBW9kx4kjGeYDPe4eNnsmD6ueHCmp0P
How the program works:
Use left/right/up/down to move the sprite one pixel at a time. (note that you can move it off-screen and break something, so don't try to do that)
Use Enter to exit the program.
Hit any other key to cause a re-draw.

Now, the issue.
If I use Firebird to emulate HW-W and run that program, everything works just as expected, no issues.
But, if I send it to my physical CX CAS (says P-0316X on the back), I get this issue where the bottom areas of the sprite have random black pixels sprinkled on them.

At first, I thought this was an issue with my code, but after many hours of attempting various things, I made an interesting discovery. The random black pixels appear a fraction-of-a-second after the back-buffer is swapped with the active-buffer. Take a look at this 1/8th speed 120fps video: https://drive.google.com/open?id=19c3eUYEXdXqHWwpNYZxBeGuI2cbj1rX8

In that video, I'm hitting a button every few moments to cause a re-draw.
Each time the sprite is drawn to the back-buffer, and then set as the active-buffer, everything is correctly shown for a fraction-of-a-second. Then random black pixels appear towards the bottom area of the sprite.

Then it gets more interesting. If I go to line 140 of main.c in the code I posted above, and replace "getPixel(x, y)" with a constant, like "0b0000000000000000", the issue completely disappears. Something to do with reading from my back-buffer is causing the image to later display with random-black-pixels after switching the roles of the back-buffer and active-buffer.

[Vogtinator]

I've got some suspicions:

• You're using a bufferable/cachable area of virtual memory as LCD framebuffer, which will not work as expected as the LCD controller uses DMA to read the pixel data. I'm not sure how this can cause the issue though, but you should try disabling the caches for that region or flushing them manually to confirm it.
• The write to 0xC0000010 only takes effect after the current frame is drawn by the controller. That means you can't directly write to the old buffer again as it's still in use. You need to wait for vsync first.
• It might be possible that there's a bug with internal bus synchronization, that reading from memory blocks the LCD controller from accessing it, producing a black pixel.

Neither of those three points are emulated by firebird, so that would explain the difference in behavior.

Anyway, you should use lcd_blit, it does double buffering into a non-bufferable area for you (no vsync yet though) and is necessary for future HW compatibility.

[KryptonicDragon]

Alright then, thanks for the help! I've started using lcd_blit, now that I've figured it out, and everything works fine.

Just one quick question:
Is there anything that can be done about the diagonal screen tearing I'm experiencing during screen updates when using lcd_blit?

[Vogtinator]

Is there anything that can be done about the diagonal screen tearing I'm experiencing during screen updates when using lcd_blit?

It would need to handle vsync either by waiting for an interrupt or polling the controller. I'm not sure whether anything would be negatively impacted by the up to 16ms delay, but that's something we'll have to find out.

This resources file includes #159:

ndless_resources.zip

[KryptonicDragon]

Here's a small program for seeing screen tearing (and causing seizures, be warned):
https://drive.google.com/open?id=125Za0Bs09w-WKS9OK0Sr3KytRXk36B-O

And here's two images of the tearing on a real calc:
https://imgur.com/a/rTEXkee