make layer y position follow hardware vstop behavior better

[irmen]

The emulator doesn't correctly set the layer y position with relating to VSTOP changes done in line irqs halfway through the screen. Found when the following test program didn't work correctly on emulator but worked fine on hardware:

split.zip

The goal of this program is to "split open" the screen from the middle and scroll the upper part upwards and the lower part downwards. In the emulator, the layer y scroll of the lower part is not updated correctly and the effect is shown wrong (the text is not "pushed down").

note: morphinejh also found another difference in the relevant code in the emulator when compared to the Vera FPGA code where the check against VSTART seemed to be 1 off. (>= vs >) this has been changed as well.

Solution from this PR as discussed on discord: https://discord.com/channels/547559626024157184/1029612422807433269/1455760243442188373

note2: Box16 also exhibits incorrect behavior here, It is unclear to me how this solution must be ported to it because the rendering code seems to be different than in the official emulator...

[morphinejh]

The VERA code mentioned can be found in composer.v , r48.0.1.

Further, I went back found something else that was impacted and needs changed:
Issue - Original Solution

New solution:
Line ~1159: if ( y < vstart || y >= (vstop-1) ) {

[irmen]

New solution: Line ~1159: if ( y < vstart || y >= (vstop-1) ) {

@morphinejh hmmm, is this correct? This will make a difference of 2 scan lines compared to the old situation, that seems much?

[morphinejh]

New solution: Line ~1159: if ( y < vstart || y >= (vstop-1) ) {

@morphinejh hmmm, is this correct? This will make a difference of 2 scan lines compared to the old situation, that seems much?

If the changes are added to match the VERA, the 'fix' for the issue identified in the link comes back without that change as well. At least from my testing.

I think this is because the VERA doesn't inspect the lower bit of VSTOP. So VSTOP is always a multiple of 2.

[indigodarkwolf]

It looks like the wasm build failure is happening due to some change in the runners on GitHub, and I'm not sure how to immediately troubleshoot that. I see this change has been held up for a long time, I'm going to go ahead and approve it.