Uridium and Nightshade regressions

[hoglet67]

With Uridium there is now continual switching in/out of MODE 7 on the Joystick/Keyboard selection screen.

With Nightshade there is a similar provlem within the game itself

When did this regression occur?

• The 2020/05/04 stable release is fine
• The 2020/09/08 dev release, and all subsequent release have the problem
• Bisecting shows it was introduced by a change of thresholds in ec04f8c

Changing FIELD_TYPE_THRESHOLD from 45000 back to 32000 on the latest (2021/12/24) build resolves the issue with both games.

Probing the exact thresholds:

• For Uridium: 43,000 fails but 42,000 is OK
• For Nightshade: 45,000 fails bit 44,000 is OK

Here are some scope shots of the end of VSYNC in the various cases:

Normal Mode7

Normal Mode 4

Uridium

Nightshade

Interlaced Timings

Normal Mode 7: 23us / 55us

Normal Mode 4: 21us / 53us

Uridium: 11us / 43us

Nightshade: 13us / 45us

Conclusion

Reducing the field type threshold from 45us to 40us will avoid making an incorrect field type decision with Uridium and Nightshade.

The wrong field type is confusing the mode 7 detection as follows (using Uridium as an example)

• 11us and 43us are both less that 45us, so are seen as odd fields
• this causes the 22.5us ODD_THRESHOLD to be used for mode 7 detection
• the 11us fields are seen as MODE 0..6
• the 43us fields are seen as MODE 7
• hence the contnual switchig

When the field type threshold is reduces to 40us:

• the 11us field is detected as an odd field, so uses the 22.5us ODD_THRESHOLD
• the 43us field is detected as an even field, so uses the 54.5us EVEN_THRESHOLD
• in both cases the field < threshold so the mode is deemed to be MODE 0..6
• this is the correct decision, but more down to luck than anything else

Uridium is using a technque known as "Vertical Rupture"

[hoglet67]

It looks like Uridium is using a reduced size version of MODE 1 for it's intro screen.

MODE 1 is normally 320x256 (20KB)

This reduced size MODE 1 is (160x200) (8K)

The 6845 timings (c.f. normal MODE 1 values) are:

R00 H Total = 7F (Standard)
R01 H Displayed = 28 (Non standard; normally 50)
R02 H Sync = 4E (Non-standard, normally 62)
R03 V/H Sync Width = 28 (Standard)
R04 V Total = 26 (Standard)
R05 V Adjust = 00 (Standard)
R06 V Displayed = 19 (Non-standard, normally 20)
R07 V Sync Pos = 1D (Non-standard, normally 32)

To centre the screen horizontally, the sync position is changed by 10us (HSync pos 62->4E). This is consistent with what see on the scope.

The Nightshade looks slightly wider.

[IanSB]

The reason for the change was that the default setting of 32000 didn't work on the Amiga's interlaced video and 45000 was a compromise that appeared to work on both the BBC and the Amiga.

Using 40000 should work on the Amiga as the comment mentions 34000 as the limit.
However I'm a little wary of adjusting this value for all circumstances in case it breaks something with the Amiga

A possible workaround would be to set the value as 40000 or less on "Auto" (Used by bbc profiles) and 45000 on "Interlaced" (used by Amiga profiles).
i.e "Auto" prefers the beeb and "Interlaced" prefers the Amiga

There is already a similar setting which filters out equalising pulses when "Interlaced" is selected but not when Auto is selected so the Amiga has to use "Interlaced" rather than "Auto" anyway because it produces equalising pulses. That filtering can also upset some things on beeb profiles which is why the filtering isn't on Auto as well.

[IanSB]

Can you try Beta53:
As described above this sets Auto mode to 39000 (I reduced it further for more safety margin) and Interlaced mode to 45000
https://github.com/IanSB/RGBtoHDMI/releases

[hoglet67]

That seems fine.

I'll close this issue now.