Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
As it turned out in #256 , I have some palette precision problems when using "legacy" (VIC-III) palette registers, in terms of actual values represented in VIC-IV palette. Maybe other problems as well. Since it's kind of different topic than just reading back pixels in issue #256 , let's open a new issue on this specific topic.
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.
Now actual RGB values seems to be kinda identical with MEGA65 with the commit above. This also changed the palette slightly, which is not a problem, since it means it should be closer to MEGA65 now anyway ;)
As it turned out in #256 , I have some palette precision problems when using "legacy" (VIC-III) palette registers, in terms of actual values represented in VIC-IV palette. Maybe other problems as well. Since it's kind of different topic than just reading back pixels in issue #256 , let's open a new issue on this specific topic.
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.