MEGA65: implement VIC-IV debug pixel value readback

[lgblgblgb]

Implement MEGA65's VIC-IV debug pixel value readback: MEGA65/mega65-core#390

Copy&paste from that issue of mega65-core

We used to have a mechanism whereby it was possible to read the RGB values of any pixel position on screen, but it stopped working.

We should re-enable this facility, so that we can make automated tests for the VIC-IV and game compatibility etc.

$D07D = X LSB
$D07E = Y LSB
$D07F = X,Y MSNybls
(Red cross-hairs will be displayed to indicate the debug position)
$D07C bits 6-7 = select what appears when reading $D07D:
00 = hyperram access count (existing thing at $D07D)
01 = Red channel of pixel
10 = Green channel of pixel
11 = Blue channel of pixel

Test program

src/tests/test_390.c in mega65-tools verifies that this is functioning correctly: https://github.com/MEGA65/mega65-tools/blob/master/src/tests/test_390.c

Here it is a zipped PRG file compiled from the source above: test_390.zip

Suggested test method (after downloading and unzipping the PRG file): xmega65 -prg test_390.prg

TODO

How coordinates are specified exactly? In regards of the SDL texture. As it turned out with issue #363 , it should be adjusted again, now it's totally experimental to "fine tune coordinates till the test programs work". So it should be figured out somehow at last!

[gardners]

That's the $100 issue, right? ;)

[lgblgblgb]

First try, committed in merger (see the commit above): 259608c Xemu binaries available at the download page. Currently it uses texture coordinates, which is - I bet - not the correct behaviour (note: using "reduced border" option otherwise makes no difference since the whole texture is rendered always, at max, only a viewport is shown with reduced border, so it's not a problem).

[lgblgblgb]

Ok, $D7FA was not emulated ... Thus the tester stuck, waiting for new fame which has never come ...

[lgblgblgb]

Now the tester can run at least since the $D7FA frame counter is emulated. The result is interesting though:

that and the following image can be seen periodically, not a static one

[gardners]

There is some memory corruption bug on real hardware in this test as well, but it just looks less extreme (some chars go black). I haven't had the chance to investigate it.

[lgblgblgb]

For reference, here is a (dirty) screen photo (literally ...) running on MEGA65 with the latest bitstream from Paul:

[lgblgblgb]

The coordinates shown by the cross-hair at least not so much way-off. However it's interesting that background has other colour than with Xemu. I have no idea about the "defects" (garbage chars / sprites?) seems to be at different places, also with Xemu it's kinda "blinking" also having different dimensions.

[lgblgblgb]

Now just focusing on the pixel-readback, not other issues here (like the background is different, those garbage stuff are not the same etc), I see the following main problems:

• Not the same position for the cross-hair so for the pixels read back, which is clearly a problem ...
• The very accurate RGB data is maybe not the same (the reason that this code in Xemu reads back SDL texture and decodes back RGB values ... just to have an RGB buffer for this would be overkill and a major performance problem). But it can be because of reading the wrong pixel and/or rendered the wrong one (ie, like with different background than it should be).

Let's (ie: note to myself) be precise with "targeting" the pixel very same as on MEGA65 and try again.

[lgblgblgb]

There is some memory corruption bug on real hardware in this test as well, but it just looks less extreme (some chars go black). I haven't had the chance to investigate it.

@gardners It's very interesting, that the corruption is also emulated to some extent, however not exactly the same way :-O

[lgblgblgb]

Palette specific problem has been moved to new issue: #259

New findings: palette handling in Xemu is somewhat wrong, by writing legacy VIC-III palreg with value $F (for example) results in $FF for Xemu for the real VIC-IV palreg (my idea was to allow to use the whole brightness spectrum via VIC-III as well). However it seems, on MEGA65 it's only done with writing the most significant nybble to set.

[lgblgblgb]

Xemu result so far, for #259 please compare the result of the MEGA65 reference above. Clearly, the background colour is bad (compared to the hardware), but that's not the fault of read-back feature here, but the background itself is bad in Xemu.

[lgblgblgb]

To myself: I need to write a test program using a big white rectangle or so with "auto-searching" the top left pixel of that rectangle with this feature, thus then it's easy to compare the result with MEGA65 about the exact coordinates should be used.