Search options (Page 1 of 11)

Thanks, I had missed that one. I'll work with that then.

This is my understanding of what might be happening on the 5450:

pal: "768x576_50 15.62KHz 50.00Hz" 14.88 768 792 864 952 576 582 587 625 interlace -hsync -vsync

* odd  field start 2.5 2
576 last visible line
578 front porch 1
580 front porch 2
582 front porch 2.5 = sync pulse start
584 sync pulse 1
586 sync pulse 2
588 back porch
590 back porch

* even field start 3   3
575 last visible line
577 front porch 1
579 front porch 2
581 front porch 3
583 sync pulse 1
585 sync pulse 2
587 sync pulse 3
589 back porch

pal_exact: "768x576_50 15.62KHz 50.00Hz" 14.75 768 792 864 944 576 581 585 625 interlace -hsync -vsync

* odd  field start 2   2
576 last visible line
578 front porch 1
580 front porch 2
582 sync pulse 1
584 sync pulse 2
586 back porch
588 back porch
590 back porch

* even field start 2.5 2
575 last visible line
577 front porch 1
579 front porch 2
581 front porch 2.5 = sync pulse start
583 sync pulse 1
585 sync pulse 2
587 back porch
589 back porch

My current supposition is:

- When the video card's line counter matches the modeline's vertical sync pulse start value, it triggers the vertical sync pulse at half of the hsync period of that line.

- This happens regardless of the field parity. So setting the sync pulse start on an even line number causes the half line to happen at the start of the odd field, like in the "pal" preset case, which results in the fields being swapped.

- The sync pulse end isn't shifted from the line boundary in any case, making it impossible to achieve a 2.5 lines pulse on both fields. You only get the required half line on the field which matches the modeline's sync pulse start.

Hi goscickiw,

I'm trying to figure out which modelines match your drawings in each case.

My guess is this:

pal

"768x576_50 15.62KHz 50.00Hz" 14.88 768 792 864 952 576 582 587 625 interlace -hsync -vsync
                                                       6   5  38  (VFP, VSP, VBP)

pal_exact

"768x576_50 15.62KHz 50.00Hz" 14.88 768 792 864 952 576 581 586 625 interlace -hsync -vsync
                                                       5   5  39   (VFP, VSP, VBP)

Modelines represent the values that end up populating the crtc registers. These are always integer values. This means the video card must have a rule to add the half line required for interlaced modes. We don't know how this is achieved by the hardware. Probably, the vertical sync pulse start is simply delayed by half hsync period for one of the fields. Probably this isn't consistent between different video cards either.

If you have a chance to try, I'd appreciate seeing how different front porch/sync pulse values are translated to actual sync signals. Arcade OSD is great for this because you can modify those values on the fly and see the result on screen.

Also, it's not fully clear to me whether your "pal_exact" preset actually results in correct PAL modes for you or not.

I'd like to remark that on the screens I've tested interlaced modes, I've got correct results regardless of the preset, that's why I've assumed the modelines were correct. With the notable exception of a Hantarex Polostar I used to have, where interlaced modes would randomly appear with the fields inverted, as you describe. So I wonder if some chassis are less tolerant to non-compliant interlaced modes for some reason.

Hi goscickiw,

First of all, sorry for my late answer.

I'm pretty sure PC video cards don't output any equalizing pulses. This is part of the broadcasting standard, but here we're dealing with pure RGB signals, and these cards were designed for monitors that, in their electronics, had probably already solved the issues that equalizing pulses were meant to address.

Besides, the interlaced video that these cards are able to produce is rather crude, as you have found and shown here. I would have expected that at least they respected the half line shift (vsync at mid-hsync) feature. This has been a nasty surprise, that suddendly explains why some monitors have trouble with field displacement. I appreaciate you sharing this with us.

Despite this, many TVs just show decent enough interlace video, so for some reason it just ends up working well on them, even with the 2-3 or 3-2 vsync patern instead of the proper 2.5-2.5.

The problem behind this is that we have only control on the modeline computation. What the hardware actually does with the numbers in order to produce interlaced video is a unknown. Long ago I found that, despite an even vtotal was admitted, it produced wrong timings, so always an always-odd vtotal was stablished in the computation. Just recently, we've found that many AMD APUs actually hate an odd vtotal, and in fact require to keep the same parity over all the vertical fields.

Considering this, it may well be true that older hardware also had parity requirements on the other vertical fields, like the front porch (which makes a lot of sense). But since it was somewhat more permissive, we hadn't noticed that. Probably, this is what you've indirectly found, by manually tweaking the crt range.

Unfortunately, VMMaker is somewhat outdated regarding this newer knowledge. Currently, Switchres has the options to produce interlaced modelines with consistent parity. The option you want to use is:

interlace_force_even 0|1

in switchres.ini, either on or off.

https://github.com/antonioginer/switchres

With interlace_force_even = 0:

Modeline "768x576_50i 15.625000KHz 50.000000Hz" 14.765625 768 790 859 945 576 583 588 625 interlace  -hsync -vsync

With interlace_force_even = 1:

Modeline "768x576_50i 15.600000KHz 50.000000Hz" 14.726400 768 790 859 944 576 582 587 624 interlace  -hsync -vsync

Hi peshti,

Not sure what your question is. I guess you have to focus on getting a compatible video card, and a proper VGA to SCART cable.

Hi akira251,

Sorry, I've just seen your post. Can you share what you did to fix it?

Hi DimisHg,

Yes, the drivers are compatible with those models. I have an R9 270 here, working fine.

Hi Haze,

First question is if your CRT can take RGB. If so, then you definitely have to use DVI-I to RGB.

If RGB isn't an option, next best situation would be component video, by using an RGB to component transcoder.

But you're probably aware of this and simply want to use S-video. Well, the problem with S-video is that this output has its own implementation path inside the hardware, that wasn't done with custom modes in mind. Basically, when using the S-video (TV-out) output on a video card, all is scaled/stretched into a single standard PAL/NTSC mode. So there's no point in using CRT Emudriver in the case.

Unrelated but important: if you're going to use CRT Emudriver on a Windows 10 setup, you'll have a better experience with an HD 5000/6000 card (DirectX 11 card). Pre-HD 5000 cards had poor support for the new driver model.

Hi Dancorp,

APU's support is sort of hit and miss because of the difficulty to actually own or have access the hardware required to test, and the (unfortunate) lack of user's interest.

I do believe, however, that interlace is supported on Linux through the radeon driver for that specific hardware.

I recommend you to check Groovy Arcade for this: https://github.com/substring/os/releases

V e r s i o n   h i s t o r y

- v1.6 - October 2021
    - Added support R9 380/380X.

- v1.5 - December 2017
    - Added support for composite sync.
    - Reduced BIOS hook size by 40 bytes, now only 532 bytes of blank space are required.

- v1.4 - November 2017
    - Fixed bug that caused wrong checksum correction in some cases.

- v1.3 - March 2017
    - Implemented GOP reallocation for EFI bios.

- v1.2 - September 2016
    - Detect blank space as a combination of 0x00 and 0xFF characters.
    - Reduce by 256 bytes the size required by the BIOS hook, now only 572 bytes of blank
      space are needed to patch the BIOS.
    - Fixed bug that caused wrong checksum correction in some cases.

- v1.1 - October 2014
    - Fixed critical bug that affected older Radeon cards (the X series at least).

- v1.0 - October 2014
    - First version released.

Hi icemac,

Please use the version based on Crimson 16.2.1.

The one based on 12.6 is ancient and just provided to support legacy (pre-HD 5000) cards. It's not suited for Windows 10. It used to work though with first Windows 10 releases (that's why it's labelled as Win-10 compatible). But Windows 10 is a moving target.

They work now, thanks!

Hi Ozzy,

Sorry for the late answer.

You should always use the latest version that supports your card, in your case the Crimson based one, specially if you're on Windows 10. The older 12.6 one barely works on 10 and is just provided for backwards compatibilty with pre-HD 5000 cards.

With regards to the issue you're seeing, it's not linked to Windows 10 actually, but to AMD External Events service, which forces 640x480 at 31 kHz when some programs don't explicitely ask for a specific refresh rate (many don't unfortunately). Anyway, the solution that has worked for many people is to disable this service permanently.