MEGA65: Characters not drawn when started at negative GOTOX values

[smnjameson]

When the VIC4 attempts to render a sequence of characters that sstarts offscreen to the left (eg gotox = $03f0), it fails to do so. It seems like if after a single char the x position is out of range it terminates rendering until another GOTOX or end of line

Xemu version : 20220831211537

Please see attached videos and test.prg
test.zip

Devkit Expected:
https://user-images.githubusercontent.com/4640763/188480532-f3f35e1c-5c59-4411-a6b5-1fc02a78c42b.mp4

Xemu Actual:

xemu.mp4

[lgblgblgb]

Errr, this is some to be a long-stalled issue here, trying to catch-up a "bit" ... Reading the issue again, at first glance it seems to me that Xemu handles position as an unsigned entity, $3f0 for Xemu is at right not at left. In any way, I think the problem indeed, that the value does not "overflow" to zero when going above $3ff. Or something like that. I'll have a look.

EDIT:

Maybe there will be a fundamental issue here which makes this really hard to emulate (at least within the current structure of the emulator), since xcounter in Xemu used for many structures and never can be negative ... And somehow it should be handled as negative still. But in that case almost all rendering codepath must be "decorated" by checks, significantly slowing down performance. The same problem with any render-overflow/render-underflow topic, like sprite at extreme right (and X-expanded) seen on the left: this is also impossible to do in Xemu currently at least not in a sane way ...

Also, Xemu's approach of "direct rendering" into SDL texture makes it hard, as negative values would mean literally to overwrite the previous also rendered scanline. Unless, if "expensive" checks is made every single places into the rendering pipeline.

[lgblgblgb]

I've tried to solve this issue several times (I always think, a "fresh start" / "fresh ideas" can help, from time to time) already but always failed. I can make the test program working as expected, but it has serious ill effects on every other things, even on the default READY. screen on BASIC65. This is very hard to handle, since in Xemu, there is no conception on negative values in this context, so the "negative" is seen as a large positive value instead and needs several hacks. Where one/some may fail to do what I thought. Probably this requires a bit deeper dive and modify how the position info is handled, everywhere in VIC-IV emulation ...