Garbage on left edge of screen in Tominv5

[DirtyHairy]

@thrust26 has a testcase on http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/?p=3644886 that displays garbage on the left edge of the screen (its even worse in the old core).

[DirtyHairy]

@thrust26, would it be possible to take a look at the source of this testcase and play with it?

[thrust26]

Sure TomInv5.zip

BTW: How about a thread where we list all games which are fixed by the new core and describe the differences? During my tests I found a number of fixes (sometimes very subtle) of games not mentioned here. IMO those provide valuable input for regression tests.

[DirtyHairy]

Thanks alot! My assembly seems have timing issues in the RAM kernel, but the source is a great help in pinning down the problem.

As for your suggestion: that's a very good idea. I also have a list of cartridges in my head which are sensitive to various subtleties in the emulation and might serve as a canary for regressions. What do you think about just creating closed issues tagged with 'regression test' for those? This way, we could keep them organized, attach screenshots where we like and "reopen" them if they break.

[thrust26]

Perfect idea!

But then: I can't neither tag nor close.

[thrust26]

Here is a better test ROM for the 11 invaders. You can disable individual columns with the cursor at the bottom and fire or randomly with left diff = A.

But here the glitches do not show. It works perfect with the new core. Hm...

SI-11_007.zip

[thrust26]

Made another test with TomInv5 on my hardware. The top row glitch shows there too, but only after the bunkers have been removed. I wonder if there is a programming flaw...

[DirtyHairy]

I am not sure, but from my analysis so far, I have been thinking along the same lines. Basically, I am suspecting that the glitch is connected to the initial value of A when jumping into the RAM kernel. That would explain why only the first line is glitched; on the second and all subsequent iterations of the RAM kernel, a has been reloaded.

Another test I made is hacking the core such that players always display solid 8 pixels if GRPx is nonzero (I like to do that to be sure where sprites are positioned). If I do that, then I see a similar glitch on the line where the bunkers start, too.

[DirtyHairy]

Concerning tagging and closing: I have just added you as a collaborator to the repo :smirk:

[thrust26]

Already started working.

Should we add ROMs which had issues (like Pole Position and Frostbite) to the regression test list too?

[DirtyHairy]

Thanks alot :) As for old issues: yes, let's tag those, too. However, Pole Position was a red herring; it was working fine all along (I blindly carried over the issue from 6502.ts, but it is actually caused by timing inaccuracies in the 6502.ts CPU implementation).

[thrust26]

PP had a glitch at the top left, besides the speed bar.

[DirtyHairy]

Forgot about that one --- you're right. Concerning Tominv5: I now know a bit more:

• The glitches that are visible in the original ROM from the AtariAge thread are the second and third copies of player 0
• NUSIZ0 is being written while those are being latched or drawn (33, 36, 37, 63 and 73 color clocks into the player sprite counter)

I'll have to leave now, but I'll continue looking into this. Even if a flaw in the code is involved, it'll be interesting to see the difference.

[thrust26]

After checking my code a bit more, I am pretty sure that the bug is in my code. For now I would suggest to close this issue.

[DirtyHairy]

:christmas_tree: