Unemulated problem in Alien Syndrome (J)

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1198
Joined: Thu May 19, 2005 11:30 am

Unemulated problem in Alien Syndrome (J)

Post by NewRisingSun » Thu Apr 23, 2020 2:24 pm

The script "THE BATTLE HAS JUST BEGUN" flickers on real hardware, including when using an Everdrive N8, but not in any emulators that I have tried. What is the game doing, and why does it flicker?

Edit: Apparently, the U.S. version from Tengen does not suffer from this problem.

User avatar
Controllerhead
Posts: 89
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Unemulated problem in Alien Syndrome (J)

Post by Controllerhead » Thu Apr 23, 2020 4:08 pm

Can confirm, no flicker here. shes an 07.
https://i.imgur.com/BFWrc6M.mp4

Image
Last edited by Controllerhead on Thu Apr 23, 2020 5:12 pm, edited 3 times in total.

Fiskbit
Posts: 120
Joined: Sat Nov 18, 2017 9:15 pm

Re: Unemulated problem in Alien Syndrome (J)

Post by Fiskbit » Thu Apr 23, 2020 4:52 pm

I easily reproduced this on my Everdrive N8 Pro on a rev H system. My initial guess was that this was related to the $2006 second-write glitch where, if I recall correctly, the coarse x component of v (bottom 5 bits) is set at the same time from the "inc hori(v)" and $2006 write's "t = v" operations, effectively ANDing these. Unfortunately, this doesn't seem to be the cause; Mesen emulates the $2006 second-write glitch correctly (according to current knowledge) but doesn't show this flickering, and the value being written is $25C0, so any AND should result in the same coarse x being written (0). I also tried using $25C0 as the write value in split_scroll_test_v2.nes and didn't see any issues around the pixels in question, though admittedly the screen position before the writes isn't the same, which could perhaps be masking some unknown issue.

Because this is happening on Everdrive, I don't expect this to be some unknown mapper nuance, so maybe something is happening that's setting the x nametable bit to 0. At the moment, I'm not sure what that might be. Assuming no one else has any insights, I'll probably make some tests to narrow down what's going on.

Fiskbit
Posts: 120
Joined: Sat Nov 18, 2017 9:15 pm

Re: Unemulated problem in Alien Syndrome (J)

Post by Fiskbit » Thu Apr 23, 2020 7:11 pm

I put together a test which writes tiles #$30-4F to PPU $2220-223F in order to test my guess that the horizontal nametable bit is getting cleared somehow. Indeed, when the text flickers, this row of tiles becomes visible directly under the text. Nametable x appears to be the only thing changing; all other positioning looks the same. I've attached an IPS patch with these changes.

It's still not clear what is triggering this, nor why it doesn't affect the first line of text, since the splits look like they're handled pretty much the same.
Attachments
Alien Syndrome (J) - Test1 - Nametable.ips
(49 Bytes) Downloaded 27 times

Fiskbit
Posts: 120
Joined: Sat Nov 18, 2017 9:15 pm

Re: Unemulated problem in Alien Syndrome (J)

Post by Fiskbit » Thu Apr 23, 2020 9:22 pm

Sour and I were able to figure out that this is the $2006 second-write glitch, after all. The glitch affects not just coarse x, but also nametable x, which makes sense because it may need to move to the other nametable during an increment. This was missed in previous testing because split_scroll_test_v2.nes uses horizontal mirroring, so the glitch was invisible. I've attached a version of the test that uses vertical mirroring, which reproduces the issue. In this test, the numbers are scanline delay (up/down), cycle delay (left/right), pre-split nametable (select), and $2006 write value (a/b/start). On an alignment that jitters on power-on, if you set the $2006 write to 0500 (press A 32 times), you should see flicker on odd pre-split nametables with delay 40,34, and on even nametables with delays 40,31; 40,2C; 40,29; 40,24; 40,21; 40,1C; etc.

The newest Mesen appveyor build (0.9.9.32) should have the fix. You'll need to make sure the $2006 scroll glitch emulation is enabled under Options->Emulation->Advanced.
Attachments
split_scroll_test_v2_vertical_mirroring.zip
(7.53 KiB) Downloaded 37 times

lidnariq
Posts: 9491
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Unemulated problem in Alien Syndrome (J)

Post by lidnariq » Thu Apr 23, 2020 11:27 pm

... I just thought of another way to elicit this same bus conflict glitch. If a read from or write to $2007 (which trigger an increment) collides with a reload (dot 257 for X reload, or several times during the pre-render scanline for Y load), it should also end up holding the result of this bus conflict.

Since reads from $2007 are already glitchy (and writes are much worse), it's probably not worth pursuing.

Fiskbit
Posts: 120
Joined: Sat Nov 18, 2017 9:15 pm

Re: Unemulated problem in Alien Syndrome (J)

Post by Fiskbit » Fri May 08, 2020 3:37 am

I've written and attached a test that confirms this $2007 behavior for reads. Here's what I found:

- The increments from $2007 accesses appear to be delayed 5 or 6 dots depending on the alignment, which seems like a lot. This means that to land on dot 257 to conflict with 'hori(v) = hori(t)', the access needs to happen on dot 251 or 252.
- Coarse X glitches occur on dot 257.
- Y glitches occur on prerender dots 280-304.
- The Y increment is lost on dot 256 (only 1 increment occurs).
- The coarse X increment is lost on multiples of 8 dots (only 1 increment occurs). [Edit: To be clear, this happens on multiples of 8 from dots 8 to 248 (256?) and on dots 328 and 336.]

From the readme, here are the specific settings to try, with two ranges included when the range varies due to alignment:
- Dot 256 Y behavior can be seen as one scanline of jitter at V66-67,H76 or V67-68,H76.
- Multiples of 8 coarse X behavior can be seen as 1 sliver of jitter when subtracting multiples of 8 from H at V66-67,H76 or V67-68,H76.
- Dot 257 coarse X behavior can be seen as positional glitching on the remainder of the screen at V67-68,H76 or V68-69,H76 when trying different values for X scroll.
- Pre-render line Y behavior can be seen on the whole screen from V00,H2F-37 with non-zero Y scroll values (jittery on the right end on one alignment set, and jittery on both on the other set), but note that H adjustments always move in units of 3 dots and jitter in this case is by 2 dots instead of 1 because this is the pre-render scanline, which occurs before the skipped dot on scanline 0.

Some things I'm still not sure about:
- Does the same $2007 increment behavior happen with writes?
- Is the $2007 increment behavior reliable across the whole screen during rendering, or can it sometimes not increment on X, Y, or both? (It looked reliable to me)
- Given that there's a delay between the access and the increments, what is the increment behavior for accesses 5-6 dots before rendering begins or ends?
[Edit: - I assume the X and Y glitches are the typical AND behavior, but I haven't actually verified this yet.]
Attachments
2007_increment_glitch_test_v2.zip
(15.73 KiB) Downloaded 18 times
Last edited by Fiskbit on Sat May 09, 2020 5:30 am, edited 1 time in total.

lidnariq
Posts: 9491
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Unemulated problem in Alien Syndrome (J)

Post by lidnariq » Fri May 08, 2020 10:37 am

Fiskbit wrote:
Fri May 08, 2020 3:37 am
- Does the same $2007 increment behavior happen with writes?
Ulfalizer said they do.
- The Y increment is lost on dot 256 (only 1 increment occurs).
- The coarse X increment is lost on multiples of 8 dots (only 1 increment occurs). [Edit: To be clear, this happens on multiples of 8 from dots 8 to 248 (256?) and on dots 328 and 336.]
[...]
- Is the $2007 increment behavior reliable across the whole screen during rendering, or can it sometimes not increment on X, Y, or both? (It looked reliable to me)
Ulfalizer agrees with you.
If the $2007 access happens to coincide with a standard VRAM address increment (either horizontal or vertical), it will presumably not double-increment the relevant counter.
- I assume the X and Y glitches are the typical AND behavior, but I haven't actually verified this yet.
I agree that I don't see any way for it to be anything other that a wire-AND bus conflict.

Fiskbit
Posts: 120
Joined: Sat Nov 18, 2017 9:15 pm

Re: Unemulated problem in Alien Syndrome (J)

Post by Fiskbit » Sat May 09, 2020 5:57 am

I've updated the above 2007 glitch attachment with a new version that contains a write version of the test (with improved CHR and palettes to see nametable changes) and improves the controls by allowing the joypads to be swapped using the A button so it can be fully controlled with one joypad. The timings should all be the same.

The delay on the scroll increments for $2007 writes appears to be the same as the delay for reads, and the scroll glitches and lost increments all seem to behave the same. Compared to Mesen, the timing of the actual write appears to also be delayed by the same amount as the increments; performing writes 6 dots early on hardware roughly matches Mesen, though there are additional nametable updates on hardware at unexpected locations.

lidnariq
Posts: 9491
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Unemulated problem in Alien Syndrome (J)

Post by lidnariq » Sat May 09, 2020 10:21 am

Both reads from and writes to $2007 cause extra bonus superimposed behavior with the PPU's multiplexed bus.

1- If anything tries to read (fetch cadence or read from $2007), that changes the PPU's multiplexed address/data bus to high-impedance. These two processes can generate a situation where /RD and ALE are both asserted at the same time, and the PPU leaves the data bus undriven, producing an analog feedback loop from the memory through the 74'373 and back. But at least the effects are transient and only affect the result of the fetches at this moment.

2- Writes to $2007 are the same, only more so, because it can have lasting effects on multiple bytes.

Last time I said:

[ LeftHalfDot=pclk0 RightHalfDot=pclk1 | same for next pixel ]
Fetch cadence: [ ALE idle | RD loadRD ]
rd2007: [ALE ALE | idle idle | RD RD ]
wr2007: [ALE ALE | idle wrongWR | rightWR idle ]

I haven't looked up what the address bus multiplexer does at these times either, which will make things even messier.

Post Reply