Open lgblgblgb opened 3 years ago
That's the $100 issue, right? ;)
First try, committed in merger
(see the commit above): 259608ca1eded513bff892793b0c5db0cd282d1f 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).
Ok, $D7FA was not emulated ... Thus the tester stuck, waiting for new fame which has never come ...
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
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.
For reference, here is a (dirty) screen photo (literally ...) running on MEGA65 with the latest bitstream from Paul:
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.
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:
Let's (ie: note to myself) be precise with "targeting" the pixel very same as on MEGA65 and try again.
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
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.
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.
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.
Some more info, and why it's till open: it seems, the coordinates for pixel read-back is a bit cryptic topic. There is a seemingly unknown method how those coordinates are translated into actual pixel, and whatever I do, sometimes works, sometimes not, with various tests for MEGA65 (ie one test requires seemingly different corrections on texture coordinates than the other, etc). It's possible that those are not actual constants but should be dependent on video mode and/or maybe other factors?
In file targets/mega65/vic4.c
, currently:
// Debug pixel-read back feature of MEGA65
static XEMU_INLINE void pixel_readback ( void )
{
// FIXME: this is surely wrong, and we should not use texture coords directly. We must fix this somehow (offsets?)
const int pix_readback_x = (vic_registers[0x7D] | ((vic_registers[0x7F] & 0x0F) << 8)) - 8 + 2;
const int pix_readback_y = vic_registers[0x7E] | ((vic_registers[0x7F] & 0xF0) << 4);
The current situation uses -6
(well, -8 + 2
, which is -6
... it was part of my fine tuning, that's the reason of this oddity).
Implement MEGA65's VIC-IV debug pixel value readback: https://github.com/MEGA65/mega65-core/issues/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
inmega65-tools
verifies that this is functioning correctly: https://github.com/MEGA65/mega65-tools/blob/master/src/tests/test_390.cHere 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!