BASIC sprite max X position doesn't support VIC-IV SPRH640 mode

[GeorgRottensteiner]

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: xemu
• ROM Release: 920377
• Core Commit: Sorry, what's the Mega-Key on xemu? (7 digit hex number, press MEGA-TAB)

Describe the bug
When enabling double X resolution for sprites, the X position seems to be capped at 512 (511 max). Any higher values are truncated.

To Reproduce
Steps to reproduce the behavior:

1. Enter following BASIC program:

10 MOUSE ON,1,0
20 SPRITE 1,1,1
30 MOVSPR 1,100,100
40 SETBIT $d054,4

2. Try to move the mouse to the right edge of the screen.

The same issue happens, when you do not use MOUSE, and manually try to MOVSPR 1,1400,100 for example.

Expected behavior
The sprite should reach the right edge in MOUSE grab mode, and also when manually positioned at coordinates with X >= 512.

Screenshots
Not applicable.

Additional context
Found by MC64 in Forum64 thread (https://www.forum64.de/index.php?thread/139199-das-seltsame-verhalten-der-spritebefehle/)

[dansanderson]

I'm going to leave this in the queue as an "enhancement" for now, but the solution would probably be a part of a major overhaul of BASIC 65 to support MEGA65 VIC-IV features. BASIC 65 is designed for the VIC-III and only knows about VIC-III features. SPRH640 is a VIC-IV feature, and it would have to be one of many VIC-IV features that BASIC 65 needs to know about to work properly. We might be able to fix this specific issue with a small change, but I'm not sure it makes sense to fix this one and not hundreds of other similar accommodations for VIC-IV features.

Nice find, though. :)

[dansanderson]

Implemented.

We will soon be adding a mode that matches the sprite resolution to the screen resolution, using a BASIC command. The intent is to also support adjusting the sprenv400 and sprh640 registers directly with POKEs, i.e. any BASIC subsystem that depends on this state will read it from the registers.

Hires support for the MOUSE driver will be implemented separately, tracked here: #126