Investigate collisions during HBLANK

[DirtyHairy]

Verify my assertions in ticket #289

[thrust26]

Here is a first test program, and it already shows a bug. 😄
TestCX.ZIP

All elements are 8 pixel wide. The code positions P0, M0 and BL at pixel 156, additionally the rightmost pixel of PF2 is enabled. P1 and M1 are at pixel 0. So they would overlap by 4 pixel. At pixel 156, P0, M0, BL and the PF2 pixel are enabled. Then, during HBlank, P1 and M1 are enabled and afterwards, before the visible screen starts P0, M0, BL and PF2 are disabled.

This tests if collisions are triggered during HBlank. Afterwards there are 8 test results displayed: P1P0, M1M0, P1M0, M1P0, P1BL, M1BL, P1PF and M1PF. Grey means no collision detected, colored indicates a collision.

• On real hardware, the first 6 tests are positive, the last 2 tests (with PF) show no collision.
• With Stella 4.7.2, 5.0.1, 5.02, 5.1 and Stellerator all 8 tests are negative

So it seems that collisions between objects are indeed triggered during HBlank. But this is currently not covered by Stella. PF may need a bit more research.
@DirtyHairy IIRC you said that the first 6 tests should be positive in Stella too, didn't you?

[sa666666]

So that means the old core was wrong too? Not that surprising I suppose, but technically not a regression, since it never worked anyway. I will test other emulators soon, just to see what they do.

EDIT: Both z26 and Javatari have the same behaviour (no collisions at all). I'll check MESS when I get home.

[DirtyHairy]

@thrust26 You seem to love to break my core 😃 Yes, you're right, there should be collisions for all six cases in Stella and 6502.ts . I'll look at your code later to see what is going wrong.

[thrust26]

I could try to fix it myself, but you know #186... 😉

[DirtyHairy]

Hey, I always try to keep my code readable and self-explanatory 😛 I think I know what is going on, you uncovered another interesting effect. I'll write more later to keep the suspense (and to go back to the hotel).

[sa666666]

MESS also behaves as above (no collisions). So none of the other emulators are working either.

Tested on my light-sixer, to make sure it's not a PAL vs. NTSC issue; working as it should on the real console (no collisions for the last two only).

[DirtyHairy]

OK, now for the long version. The test I had in mind is slightly different as it does not involve enabling and disabling the sprites, but instead shifting them via HMOVE (this is how it happens in Thrust). Enabling / disabling currently has an effect only if a pixel is rendered; this is why you don't get any collisions (nothing is rendered). However, the schematics show a latch that is controlled by ENAx that controls the sprite signal and that does not care at all whether anything is actually shown on screen --- I think this is what your test shows and what causes the discrepancy.

I'll make the necessary changes and try again.

[DirtyHairy]

Fixed; the result now looks like expected:

There is yet another twist involved: rendering of objects positioned at x = 0 starts at the beginning of hblank. It is possible that the full first tick after hblank should be moved to the beginning, but I doubt that, and it is not currently implemented this way. Changing this should produce visible discrepancy in games that do a HMOVE too far into HBLANK.

[thrust26]

Attached is another test program. With the latest patch, Stella registers collisions for all 9 rows. But on real hardware the last 3 collisions are not registered.

Here M0, M1 and BL are positioned at pixel 0. The leftmost PF0 pixel is enabled before HBlank starts but disabled before pixel 0.

TestCX V1.3.zip

[thrust26]

Next test as described by you.
TestCX V1.4.zip

Very interesting results. The bottom line pixels are just to visualize where the missile pixels are.

Stella:

Console:

[DirtyHairy]

This is very interesting indeed. The VCS does exactly what I would assume, and 6502.ts does the same --- seems you have found a regression.

[DirtyHairy]

The discrepancy has been there since at least Stella 5.0! Nice find 😈

[DirtyHairy]

Fixed.

This was an oversight in the effective starfield description --- I haven't ported this back to 6502.ts yet.

[thrust26]

Anything else you want me to test?

[DirtyHairy]

I have made some changes to your original test to reduce the overlap to the hblank interval (my previous numbers were a bit off, M1 still overlapped with M0 on pixel 1) : test_modified.zip

The result is unchanged (you can toggle the missiles in Stella and see that there is no visual overlap anymore) 😏 Other than that, I am currently out of test scenarios --- I'll close the issue for the time being.