CD-i: Unclear correct configuration for 625 scanlines

[Vincent-Halver]

MAME version

0.272 (mame0272-397-ge2e6629e89b)

Emulated system/software

CD-i

Incorrect behaviour

High Res patterns missing all odd-numbered lines.

1. Use the Validation Disc (Europe)
2. Phillips Tests > 1st option > Drawing > Clut 4 High Res
3. Click through the examples. Take special notice of the "Outline" (Example 3)
   
4. Compare to how the outline is supposed to look (e.g. one of the other draw modes). Notice how many horizontal 1 pixel tall features are missing.

If you look at cdi.cpp

	screen.set_raw(14976000, 960, 0, 768, 312, 32, 312);

Then you will see the vertical height is only 312, with a 32 line vblank. Though this is to spec, the screen needs 625 lines to support High Res.

Expected behaviour

All CD-i players are expected to support the "Base Case". Clut4 High Res mode is in the base case.

High Res mode renders interlaced. According to the Green Book Spec, page V-38:

The video decoder scan timing is such as to drive a standard 525 line (typically 60Hz)
or 625 line (typically 50Hz) television display, with two fields per frame.

In the extended case, High Resolution images may be displayed with two interlaced
fields per frame, or line sequentially.

Given there is only 312 lines of output, it's not obvious where to draw the additional lines. So the screen must be adjusted.

screen.set_raw(14976000, 960, 0, 768, 625, 64, 625);

This was my attempt, however I'm looking for guidance on whether this is a correct setup of the Screen object.

Additional details

The minimal patch to fix this issue will be to increase the screen resolution, and then update the screen_update to

1. Skip all processing after line 312
2. Preferably have each line draw two output lines (2N and 2N+1) to avoid regression of the visuals.

Only after the resolution is corrected can support for High Res image decoding be added.

[mamehaze]

I'm assuming this is an interlace mode of some kind and the extra lines are on the 2nd field, and therefore should be shown every other frame (creating fake hi-res modes is not a real solution)

[Vincent-Halver]

Example diagram I found. Yes, each "Field" runs for 312 lines. It seems likely to me that the screen must be 625 lines tall. But this also then leads to the image appearing squished. To properly interlace, some tricks can be done to correct the image, but before I get too deep doing that, I wanted some feedback on the expected idiomatic way that it should be done.

[mamehaze]

Deinterlacing should probably be done with a shader in post processing. MAME should just generate each field the way the hardware does, no fake double fillrates. Plenty of drivers do break this convention and output fake modes, or do things in their own weird way, but in reality those should eventually be updated to generate interlaced signals instead. The fact that it would take ugly hacking of the screen sizes and other timing related parameters here to create a fake hires output is all you need to know. Real hw only ever generates 312/313 lines a frame or field, once every 50/60th of a second, it never generates 625 in that time period, MAME should not either. Amiga gets this right (one of few things it does mind you)

…

On Wed, 15 Jan 2025, 01:49 Vincent-Halver, ***@***.***> wrote: Example diagram I found. Yes, each "Field" runs for 312 lines. It seems likely to me that the screen must be 625 lines tall. But this also then leads to the image appearing squished. To properly interlace, some tricks can be done to correct the image, but before I get too deep doing that, I wanted some feedback on the expected idiomatic way that it should be done. image.png (view on web) <https://github.com/user-attachments/assets/5a3f26b6-cb6d-4ac0-8dee-790f2ae6b8f4> — Reply to this email directly, view it on GitHub <#13231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBR6GZLNLQ7NKUNJPX26UE32KW5BHAVCNFSM6AAAAABVD7NRZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJRGQ3DIMRVGU> . You are receiving this because you commented.Message ID: ***@***.***>

[angelosa]

I've actually implemented a rough form of interlace in n64 driver about two years ago. Unfortunately you still need some glue logic to hold up all of this, particularly in the realm of bumping the vertical total and clock to x2:

mame/src/mame/nintendo/n64_v.cpp

Lines 174 to 188 in 8a960d3

	if (m_rcp_periphs->is_interlace_mode())
	{
	m_rcp_periphs->video_update(m_interlace_bitmap[m_rcp_periphs->get_current_field()]);
	for (int y=cliprect.min_y; y <= cliprect.max_y; y ++)
	{
	const u8 line_field = y & 1;
	const u16 y_field_line = y >> 1;
	for (int x = cliprect.min_x; x<=cliprect.max_x; x++)
	{
	bitmap.pix(y, x) = m_interlace_bitmap[line_field].pix(y_field_line, x);
	}
	}
	}
	else
	m_rcp_periphs->video_update(bitmap);

[mamehaze]

I've actually implemented a rough form of interlace in n64 driver about two years ago. Unfortunately you still need some glue logic to hold up all of this, particularly in the realm of bumping the vertical total and clock to x2:

mame/src/mame/nintendo/n64_v.cpp

Lines 174 to 188 in 8a960d3
if (m_rcp_periphs->is_interlace_mode())
{
m_rcp_periphs->video_update(m_interlace_bitmap[m_rcp_periphs->get_current_field()]);
for (int y=cliprect.min_y; y <= cliprect.max_y; y ++)
{
const u8 line_field = y & 1;
const u16 y_field_line = y >> 1;
for (int x = cliprect.min_x; x<=cliprect.max_x; x++)
{
bitmap.pix(y, x) = m_interlace_bitmap[line_field].pix(y_field_line, x);
}
}
}
else
m_rcp_periphs->video_update(bitmap);

but this isn't really how it should be done is it @cuavas ? I'm under the impression we don't want to be doing the de-interlace handling like this in the drivers, but allow the shader to combine the fields in post?

[cuavas]

It’s complicated. If a system really needs interlace modes to be usable, we accept stop-gap measures in the drivers themselves for now. Yes, the screen device needs major surgery to support this kind of stuff properly, but it’s so tangled up with everything that’s very difficult at the moment.

[angelosa]

Also Amiga does something similar with the flickerfree stuff, not necessarily true to reality anyway (can't really tell if a line is short or long already).

[Vincent-Halver]

It's not 100% clear to me from the spec, but it seems to say that High Quality mode in CD-i can use either interlace OR line sequential. The reason for this is that the CD-i supports both traditional TVs and computer monitors.

Given this, I think the CD-i needs the Screen Object to keep track of whether the screen is a "TV" or "Monitor". This will impact the execution order of visual processing. The Greenbook then warns the programmer to ensure their control logic is order independent.

Edit: If the user community feels that Monitor is a good default, then interlacing may not be needed. However this seems like a matter of opinion on whether a computer monitor is a reasonable default.