Aliens: Random sprite corruption

[djhardrich]

Aliens: Random sprite corruption

[jotego]

Technical notes:

• it does not occur on real hardware
• tested that all objects are parsed within the line time
• occurs regardless of -d NOSOUND
• occurs even if inzone is only checked at the last state
• changing the line at which DMA stats/finishes does not fix it
• blocking writes to OBJ RAM during DMA copying corrupts the sprite data even more
• shortening the VB-related signal sent to the CPU during DMA to the minimum necessary hangs up the game

The CPU writes to the OBJ LUT while DMA is still occuring, corrupting the data. Note how the CPU is waiting for vb_start_n to go down, but it does not check it again and seems to assume some time based on the CPU speed itself.

Using sim_inputs.hex.zip as the simulation inputs with the command jtsim -nosnd -inputs -video 2650 -w 2500 -dipsw ff5eff reproduces the problem at frame 2560.

• Reducing the CPU speed to a cen below 18MHz fixes the problem. Checked that at 19.5MHz the problem persists

This seems to be caused by JTKCPU working much faster than the original CPU, by some 25% at least.

Fixed in 42649c6

[djhardrich]

Just tested in the new build (1.2.24), First Boss seems stable! Unfortunately, it crops up with Evil Newt and Alien-Bat Ripley in the subsequent stage if you get hit…

Evil Newt (Bottom Right):

Alien-Bat Ripley:

[jotego]

Blast. No easy victory. That didn't happen before, did it?

[djhardrich]

Not to my knowledge (played that stage 3 times on previous build and didn’t see it); there’s also something a little off with scrolling on a crt; it’s as if there’s a 15% frameskip/slight judder happening, could possibly be related? I’ll open a separate issue with more info/relevant video captures; Aliens might be the only game I’ve spent more time playing in the arcade than Street Fighter II!

Edit: other than Evil Newt at level start, the sprite most affected seems to be the extra frame when Ripley gets hit; note she doesn’t actually hold a gun sprite when hit (even though it looks like she should).

[jotego]

• DMA buffer clear time adjusted to match the original 341.3us, that seems to fix this issue, even with the CPU set to 24MHz
• Trying to match the time of the DMA operation after the buffer clear breaks many sprites, so this may require to match correctly the CPU speed to make it work perfectly.

However, some sprites blink a bit. I think the blinking is better than getting random sprites so I have pushed the new version to JTBIN.

[jotego]

It looks like the status bit read by the CPU was inverted. Thus, the CPU was writting sprite data during blanking instead of during active video. Everything should work now well. I'm updating the files in a few minutes.