1 (edited by goscickiw 2024-03-10 14:28:20)

Topic: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

goscickiw on 2023-09-28 wrote:

I have a Radeon HD5450 card with CRT Emudriver installed. I'm using the PAL TV monitor preset with the following user modes:

 768 x 576 @ 50.000000 desktop
 384 x 288 @ 50.000000 desktop

When viewing the signal with an oscilloscope, I have noticed that the equalizing pulses are missing and the vertical sync pulse is 0.128ms (2H) long, instead of 0.160ms (2.5H), despite 0.160ms having been set in the PAL TV monitor preset's VSyncPulse field.

This is the vertical blanking period:
Left side - from HD5450, after a circuit that combines the VGA output's RGBHV signals into Y+Sync;
Right side - from a Meratronik K944 test pattern generator, for comparison.
https://i.imgur.com/6JWy5op.png

This seems to make my oscilloscope unable to properly distinguish between field 1 and field 2. It works fine on my TVs, but makes it harder to tell which field/line I'm actually looking at on the scope. Also, I made an AD725-based PAL encoder which doesn't seem to work quite well, and I'm not sure if the cause is an issue with the encoder itself or something else such as this, so I want to eliminate other potential causes.

What should I do to get the equalizing pulses to work and get the correct length of the V-sync pulse, if it's possible at all?


I have decided to completely uninstall CRT Emudriver and reinstall it from a fresh download, so that all settings are back to default. Once again I have set the PAL TV monitor preset, enabled EDID emulation, generated and installed modes.

Now the vertical sync pulse is 3 lines long at the start of even field, and 2 lines long at the start of odd field. The odd field also starts 1 line too early, which causes the lines to not show in the right order on certain displays. This effect was previously described on this forum by robhart in the topic "Interlaced modes look like two offset images", which doesn't have a solution.

Here is a scan of a printout from the oscilloscope where I marked everything that is not as I would expect. To generate the signal I have created a 768x576 image where the 1st and 575th rows of pixels are all white, the 2nd and 576th rows have 256 white pixels, then 256 black and another 256 white, and rows 3-574 are gray:
https://i.imgur.com/8J6oc98.jpg

2

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

I'm sure Calamity will give this a look as soon as he finds a moment, whenever that happens. In the meanwhile, please, keep the subject within one only thread, even if you have to "reply" to yourself.

How exactly did you uninstall CRT Emudriver?

3

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

I ran Setup.exe and used the "Uninstall driver" option, then deleted the directory containing Setup, vmmaker, the ini files etc. Then I unpacked a freshly downloaded crt_emudriver_&_tools_2.0_beta_15_16.2.1_W.7.8.10-64_nieg.exe where the files were previously. Then installed normally.

Before installing, I had to unplug my PC from the network so that Windows won't automatically install the default AMD drivers again after I remove them.

4 (edited by goscickiw 2023-10-12 18:17:17)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Some updates

When using this custom monitor preset:

monitor "pal_exact", "PAL TV Exact - 50 Hz/625", "4:3"
        crt_range0 15625.00-15625.00, 50.00-50.00, 1.650, 4.700, 5.700, 0.160, 0.160, 1.248, 0, 0, 288, 288, 576, 576

and deleting all modes from driver, without generating and installing them again (which I assume is not how it's supposed to work), I get rid of the "swapped lines" issue, but the sync is still weird and it still causes problems. This time, vertical sync pulse is 2 lines long on both fields as I originally had it:
https://i.imgur.com/zqDZABD.jpg

Also, I now have a Tektronix VITS 201, and it works well with other video sources such as a DVB-T decoder or my Meratronik generator, but it doesn't genlock to the CRT Emudriver signal ("UNLOCKED" LED is on). I assume this is because of the weird sync.

I also tried with this user mode, but I get the same results:

 768 x 576 @ 25.000000 desktop

Also, would it be possible to move my post from my previous thread ("Equalizing pulses are missing, v-sync pulse is 2H instead of 2.5H") and put it at the start of this one, then delete the old thread?

5

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

We cannot merge threads, but you can paste that post's content here by editing any of your posts as you like (except for the thread's title).

Let me know when it's done and I'll delete the other thread afterwards.

6 (edited by goscickiw 2023-10-13 20:49:09)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Yesterday I tried to add the contents of the post from the old thread at the start of the first post in this thread, so it's in chronological order, but there is a 1 link limit and I have attached pictures in both, so I can't put all of it in 1 post.
For now I'll just put this here. I'll move this to the first post when/if it's going to be possible.
Edit: I removed the old post from here as it is now a part of the first post.

You can delete the old thread now.

7

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Opening post edited; let me know if you don't like it.

There shouldn't be any limitation in regards to the number of posted links, if you face again the issue, please, post the content here under the code instruction so we can look into it:

http://geedorah.com/eiusdemmodi/forum/v … .php?id=58

8

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

This looks good, thanks.

9 (edited by goscickiw 2023-10-20 17:56:38)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

In case that these timing and sync issues aren't something that can be fixed in software, I'm considering making a contraption out of timers, counters, analog switches and a 64us delay line to fix the timings and add equalizing pulses, but I'm not sure if I'm skilled enough in circuit design to take on something like this, and I would rather not have to do this. Especially if it turned out I didn't have to do it because I just had some settings wrong.

Update - now I also own a Philips PM5655 VITS generator. It genlocks to everything except the CRT Emudriver signal just like the Tektronix generator.

10

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Update - I decided to check what effect the missing equalizing pulses have on the image. Apparently they help with the lines of interlaced fields being properly aligned with each other on old TVs with passive RC sync separators. This is what I observed on my Unimor Neptun 621:

Left - image from PM5655 test signal generator - fields are aligned with each other;
Right - image from the PC - fields are misaligned which results in a gap every two lines.
https://i.imgur.com/lZaHZNb.jpg

11

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Another update
Today I decided to experiment with the settings again a bit, and I found a way to get the interlacing to work on all displays with modes installed. I modified my custom PAL preset - I changed V-sync pulse from 0.16ms (2.5H) to 0.128ms (2H), and V-back porch from 1.248ms to 1.279 (I couldn't set it to exactly 1.28 because then VMMaker glitches out for some reason):

monitor "pal_exact", "PAL TV Exact - 50 Hz/625", "4:3"
        crt_range0 15625.00-15625.00, 50.00-50.00, 1.600, 4.800, 5.600, 0.160, 0.128, 1.279, 0, 0, 288, 288, 576, 576

Also I'm using these user modes now:

## Desktop ##

 768 x 576 @ 50.000000 desktop1
 384 x 288 @ 50.000000 desktop2

However I still have all the same issues as in my 2023-10-12 post, except for the inability to install modes and have interlacing still working.

12

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

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

13 (edited by goscickiw 2024-03-25 11:06:06)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Thanks, I'll test what effect the switchres setting has during the weekend. Also, is there a chance that a different video card would be better at producing the 2.5H sync pulse than the HD5450, or would it likely be the same on every card? If there is a chance, then which cards would be most likely to be able to do it?

Update - I have tested with Switchres (compiled using MinGW) but there wasn't any improvement - the resulting waveform was like the one in post #1 with interlace_force_even set to 1 (swapped lines issue was also present) and like the one in post #4 with interlace_force_even set to 0.

Also, do you know of any different method of generating a 100% standard-compliant PAL RGBHV signals (I will generate S-Video and Composite from the RGBHV using a hardware encoder such as TDA8501 or TDA8505) from a Windows PC, that would show up in Windows as a 768x576 50Hz interlaced display and would display that resolution exactly, so that 1 row of pixels in Windows = 1 scan line on the TV without any scaling or interpolation?

----

2024-02-20 Update:

I think I made a mistake in my original drawings. Looks like I mixed up the field order, which is odd field first in 625-line systems. Turns out that the even field isn't actually late/early relative to the odd field, but rather something is more wrong with the vertical sync pulse on the default PAL monitor preset than I originally thought. Now it makes more sense why the swapped lines issue appears with the default PAL preset, but not with my modified exact one.

Here are the corrected drawings:

Default PAL monitor preset:
https://i.imgur.com/eRCamH8.png

Modified PAL Exact monitor preset:
https://i.imgur.com/Rljtkle.png

Also, would it be possible to add the half line blanking on the first and 576th line of the picture? I think it might be possible to do this in software by just forcing some pixels to be black.

----

2024-03-03 Update:

I have extended the V-sync pulse to 2.5H using a monostable multivibrator and it solved the biggest problem I've been having, which is that the PAL decoders inside my TVs would only decode R-Y with correct polarity every other field and that caused this issue: https://i.imgur.com/HvTcos7.mp4
Now the color displays properly on the TVs. However my PM5655 VITS generator still can't lock onto the signal for some reason... are the equalizing pulses that important? I think adding them using monostable multivibrators would be possible, but a lot more complicated than just elongating the V-sync pulse (it would have to be two of the multivibrators to create the equalizing pulses by delaying H-sync pulses by 0.5H and another two to generate a 7.5H-long "enable" signal for them from V-sync, and even more of them if I wanted it to be fully accurate to the standard - 2.35us-long pre- and post-equalizing pulses and 4.7us-long positive pulses during the V-sync pulse, also some logic gates would be needed to combine all of this together). Is there an easier way?

Update: I might build something like this (the ICs are NE555, posting as image because CircuitJS link didn't work):
https://i.imgur.com/XB0zdCP.png
This isn't 100% standard-accurate but at least makes something that resembles equalizing pulses. I'll see if this is enough to resolve the rest of my issues.

Update: The circuit works, but I had to change some things because it didn't work in real life exactly as in the simulation (I expected that). Also it turns out that the AND, OR and NOT gates at the end can be replaced by a NAND gate arrangement, so I used a single 74HC00 for all the logic gates in the schematic except for the XOR gate which is part of the AD725 PAL encoder.
My oscilloscope now seems to properly detect which field is which. However there's still some problems: The second V-sync multivibrator, responsible for extending the V-sync pulse all the way to -2.5H before the next V-sync pulse, is quite unstable and the pulse they generate shifts around as a result (this seems to be a common issue with this method, I also found this problem in professionally made hardware such as the JVC KM-V7EG or the Sony SFR-1000 which generate a vertical blanking pulse this way). Maybe instead I could use a circuit that would output a pulse after counting a set number of H-sync pulses, with the V-sync pulse for reset (something like CD4024? It would have to count higher than 127 though). Also, I still couldn't get the PM5655 to lock onto the signal (it locks onto a signal from DTV decoder so it isn't broken).

Update: I came up with a design that (theoretically) should generate a 100% standard-accurate composite sync. It uses three monostable multivibrators, two 4-stage binary ripple counters, single 12-stage counter and some logic gates. I'm not sure how well it will work in real life yet, especially the H-frequency doubler part (inverter+XOR rising and falling edge pulse generator) and multivibrators connected to it. Also the real-life counters I'm going to use (CD4040, 74HC393) are triggered by falling edge instead of rising edge, so I might need some additional inverters. I wonder how all the delays will add up.
https://i.imgur.com/4k9xuM4.png

Update: Looks good so far. Currently the generated pulses seem to have a 300ns delay relative to H-sync. I wonder if 74 series chips would be faster, currently I'm using 4000 series (4538 and 4070) because they were a bit cheaper.
Maybe tomorrow I'll make the counters, but the entire thing probably won't fit on this one breadboard. When I'm done testing it I'll make it on a PCB.
https://i.imgur.com/19efLjV.pnghttps://i.imgur.com/1vf5A2l.jpg

----

2024-03-09 Update:

I have finished the whole thing. It works exactly as expected. I changed some things from the original schematic to directly use the output of the XOR frequency doubler as a clock for the counters and lessen the number of ICs, although there's still quite a lot of them and it might be possible to reduce the amount even more. I decided to change most of the ICs to 74 series because they were faster (some 74 series equivalents weren't available at my local store). I'm also considering changing the 32us multivibrator and XOR frequency doubler to a PLL so that it doesn't have to be manually adjusted.
However, the PM5655 still doesn't like something about this signal, though now it allows the signal to pass through instead of displaying a substitution testcard, but still can't insert any VIT signals. Maybe the half-line blanking really needs to be there? I can add an additional counter and some more gates to generate the blanking signal, but the AD725 doesn't have a blanking input so I'd probably need additional hardware to do the blanking on the RGB lines.
Currently used ICs:
2x 74HC4538
1x 74HC86
3x 74HC00
1x 74HC393
1x 74HC4040
1x 74HC04
1x 4073
1x 74HC20
https://i.imgur.com/ZYFNoRr.jpg
https://i.imgur.com/qsvoCVx.pnghttps://i.imgur.com/3AukG9m.png
https://i.imgur.com/Ag9SnQ4.png

Here is the current schematic:
https://i.imgur.com/jn8QCwd.png

Update: I finally got the PM5655 to lock on. Turns out it was a setting I changed earlier to see if it would lock on back when I was using the NE555s. Now all of my problems are solved. Later I might make a proper schematic and a PCB for my contraption and publish it on GitHub.

----

2024-03-22 Update:

I have replaced the first multivibrator and XOR frequency doubler with a 74HC4046 and 74HC74 PLL frequency doubler circuit which seems to work pretty well, but there's still some problems caused by the counter clock pulse appearing at the same time as the end of the counter reset pulse, which causes the pulse to sometimes be counted and sometimes not. Because of that the clock pulses have to be delayed by about 20ns for the circuit to work properly.

I have also found and ordered an integrated circuit called SAA1043, which might be able to do all of this and more, but it only has a composite sync input and I'm not sure if it will be able to handle the imperfect XNOR-combined sync.

Update: I read more of the SAA1043 datasheet and it looks like it can also accept separate H and V sync. Also I found SAA1101 which might be even better as it can run on 5V. I'm still waiting for both chips to arrive.

14

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Hi goscickiw,

Thanks again for sharing this. I would really like to get to the bottom of this. Specifically, your last updated drawings showing odd/even fields.

But first I need to make sure I'm understanding your drawings. What are the spikes on the first and last lines? Are you sending white lines on those to help identifying them on the oscilloscope?

15 (edited by goscickiw 2024-04-07 12:13:18)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Yes, this is the full image I was using for the test. First and 575th rows of pixels are white, second and 576th rows are white-black-white, the rest is gray:
https://i.imgur.com/P3PMft5.png

Also, today I tested the SAA1101 chip. It does everything that my monstrosity does, but better, and is much more stable. I also had to use 74HC04 to invert the signals because SAA1101 accepts and outputs positive sync instead of negative.
On the following photos, yellow waveform is output composite sync, magenta is VGA vertical, cyan is VGA horizontal and green is phase comparator output:
https://i.imgur.com/GS6M62r.pnghttps://i.imgur.com/VqDOfJQ.png
https://i.imgur.com/SjnmXWx.jpg

Also, I'm wondering if it would be possible to generate a color subcarrier that is synchronized with the line sync. The SAA1101 is seemingly able to do that, but from what I understand it seems that it can only do that when it generates the sync on its own instead of using external sync (I might be wrong though). Having the color subcarrier synchronized would be nice, as currently my PM5655 can only work properly with this signal when burst substitution is disabled (which isn't a problem with a signal from a DTV decoder for example). Also I suppose that comb filters might not work properly (or as good as they should) with my signal if the color subcarrier isn't synchronized.

----

Update: As the SAA1101 generates a blanking signal as well, I decided to add a 4053 analog switch for correct vertical blanking on field 1. I had to remove the 75 ohm termination resistors from my PAL encoder board and install them before the 4053, because its internal resistance is quite high and the voltages at the PAL encoder were too low.
https://i.imgur.com/kaR7Fc2.jpg
https://i.imgur.com/mAzxSZG.png
https://i.imgur.com/LQn4Jd1.pnghttps://i.imgur.com/vSKez1Y.png

16

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

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.

17

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

In my case, pal_exact generates these modelines (I use 768x576, also Windows shows it as preferred):

"720x576_50 15.62KHz 50.00Hz" 13.88 720 744 808 888 576 581 585 625 interlace -hsync -vsync
"744x576_50 15.62KHz 50.00Hz" 14.38 744 768 840 920 576 581 585 625 interlace -hsync -vsync
"768x576_50 15.62KHz 50.00Hz" 14.75 768 792 864 944 576 581 585 625 interlace -hsync -vsync

Default PAL preset generates these ones (with these, Windows shows 640x480 as preferred, but it leaves some lines empty. 768x576 fills the whole screen, but there's still the weird sync problem. Also the SAA1101 seems to be unable to properly lock onto the sync):

"240x192_50 15.60KHz 50.00Hz" 4.74 240 248 272 304 192 243 245 312 -hsync -vsync
"240x200_50 15.60KHz 50.00Hz" 4.74 240 248 272 304 200 247 249 312 -hsync -vsync
"248x192_50 15.60KHz 50.00Hz" 4.87 248 256 280 312 192 243 245 312 -hsync -vsync
"256x192_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 192 243 245 312 -hsync -vsync
"256x224_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 224 259 261 312 -hsync -vsync
"256x239_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 239 267 269 312 -hsync -vsync
"256x240_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 240 267 269 312 -hsync -vsync
"256x244_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 244 269 271 312 -hsync -vsync
"256x256_50 15.60KHz 50.00Hz" 4.99 256 264 288 320 256 275 277 312 -hsync -vsync
"320x224_50 15.60KHz 50.00Hz" 6.36 320 336 368 408 224 259 261 312 -hsync -vsync
"320x240_50 15.60KHz 50.00Hz" 6.36 320 336 368 408 240 267 269 312 -hsync -vsync
"320x244_50 15.60KHz 50.00Hz" 6.36 320 336 368 408 244 269 271 312 -hsync -vsync
"320x256_50 15.60KHz 50.00Hz" 6.36 320 336 368 408 256 275 277 312 -hsync -vsync
"336x224_50 15.60KHz 50.00Hz" 6.61 336 352 384 424 224 259 261 312 -hsync -vsync
"384x240_50 15.60KHz 50.00Hz" 7.36 384 400 432 472 240 267 269 312 -hsync -vsync
"512x448_50 15.62KHz 50.00Hz" 9.88 512 528 576 632 448 518 523 625 interlace -hsync -vsync
"512x478_50 15.62KHz 50.00Hz" 9.88 512 528 576 632 478 533 538 625 interlace -hsync -vsync
"512x480_50 15.62KHz 50.00Hz" 9.88 512 528 576 632 480 534 539 625 interlace -hsync -vsync
"512x512_50 15.62KHz 50.00Hz" 9.88 512 528 576 632 512 550 555 625 interlace -hsync -vsync
"544x242_50 15.60KHz 50.00Hz" 10.48 544 560 608 672 242 268 270 312 -hsync -vsync
"640x200_50 15.60KHz 50.00Hz" 12.36 640 664 720 792 200 247 249 312 -hsync -vsync
"640x480_50 15.62KHz 50.00Hz" 12.38 640 664 720 792 480 534 539 625 interlace -hsync -vsync
"768x512_50 15.62KHz 50.00Hz" 14.88 768 792 864 952 512 550 555 625 interlace -hsync -vsync
"768x576_50 15.62KHz 50.00Hz" 14.88 768 792 864 952 576 582 587 625 interlace -hsync -vsync

The pal_exact preset is the one that works correctly, but outputs 2H-long V-sync instead of 2.5H-long, which I can correct with the SAA1101 (which also generates equalizing pulses and blanking signal).
The pal preset isn't working correctly for me, the V-sync alternates between 2H and 3H long and is 0.5H too late, as if the field order was reversed, which I assume causes the swapped lines issue.

I have tried changing settings in Arcade OSD before, but I wasn't able to achieve 2.5H-long V-sync. Other timings seem to be correct.

The TV I'm using for the tests is Neptun M547 BT. It uses TDA4555 PAL decoder which doesn't seem to work properly when provided non-standard sync. I'm also using a BT878-based TV card with composite input, and it manages to decode color properly even with the non-standard sync, but is still susceptible to the swapped lines issue.

18

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Could you double check you haven't tweaked your "pal_exact" preset any further since you posted it here?

With your posted pal_exact preset I'm getting: 576 581 586 625 instead of 576 581 585 625.

19 (edited by goscickiw 2024-04-07 17:47:59)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

The one I'm using now is the one I described in 11th post:

monitor "pal_exact", "PAL TV Exact - 50 Hz/625", "4:3"
        crt_range0 15625.00-15625.00, 50.00-50.00, 1.600, 4.800, 5.600, 0.160, 0.128, 1.279, 0, 0, 288, 288, 576, 576

Also, I have replaced all of the other config files (vmm.ini, user_modes.ini, user_modes - super.ini, mame_favourites.ini) with default unmodified ones before testing today, just to make sure nothing else is changed.

Also, more detailed PC specifications just in case they are important:
Graphics card used for CRT Emudriver: AFOX AF5450-1024D3L5
Main graphics card: EVGA GTX 1070 SC2
Motherboard: ASUS M51AC (H87M Pro OEM)
CPU: Intel i7-4770
OS: Windows 10 home 22H2 build 19045.4239

20

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

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.

21

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Calamity wrote:

- 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.

I'm not sure if I understood this correctly, but the end of the V-sync pulse doesn't seem to have to coincide with the line end. On pal preset line 586 and pal_exact line 585 it ends half way through.
Or do you mean that the sync pulse lasts from the middle of line 581 (312.5) all the way to the end of line 584 (2) and contains both field pulses?

Also, if it's a hardware issue, does this mean that this behavior could be specific to this particular graphics card model, or would it also be present on other models?

22

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

goscickiw wrote:

I'm not sure if I understood this correctly, but the end of the V-sync pulse doesn't seem to have to coincide with the line end. On pal preset line 586 and pal_exact line 585 it ends half way through.

You're right. What is probably happening is that the vsync end copies the shift of vsync start. So there's no way to have 2.5 lines when vsync starts on a line boundary (odd field).

Also, if it's a hardware issue, does this mean that this behavior could be specific to this particular graphics card model, or would it also be present on other models?

It could be, but I'd say most early Radeon models probably behave the same. I do know that later APUs do it differently, which is causing us lots of pain.

When I have a chance, I will inspect how the blanking hardware registers are triggered in each case on the cards I have around.

23 (edited by goscickiw 2024-08-22 05:39:22)

Re: PAL vertical sync weirdness. How to fix? (Solved by extra hardware)

Thanks, I think I'll keep using my current 5450 with the SAA1101 for now. Maybe I'll experiment with other cards in the future.

----

2024-04-29 Update:

I have recently ordered a PCB to be made for my sync/blanking device and it has arrived today. It works pretty well. I have replaced the 5 MHz crystal with an inductor so it can work over a wider range of frequencies. Now it can work with 576i50, 288p50, 480i60 and 240p60, the standard can be set using a DIP switch.

I have also made another PCB myself, to test a SAA1044 chip for obtaining a color subcarrier that is synchronized to the line sync. The SAA1044 needs a 1.25 MHz reference, which I'm obtaining from the SAA1101's 5 MHz clock by using a divide by 4 counter. It (maybe?) also needs a 400 Hz signal for PAL, which I'm also generating from 1.25 MHz using a CD4059 counter.
Currently I also have to use an additional 74HC04 with a 17.734475 MHz crystal instead of the SAA1044's built-in 4.43 MHz crystal driver, as the AD725 PAL encoder needs 4Fsc instead of just Fsc. This gets divided by 4 by a counter before going into SAA1044. This won't be needed when I use TDA8501 instead.
This subcarrier generator also works quite good, and thanks to it my PM5655 can now fully lock onto the color subcarrier as well as the sync.

However, this solution to one problem made another appear. The SAA1044 forces the color subcarrier frequency to be exactly 283.7516 times H-sync, which should be 4.43361875 MHz if H-sync was 15625 Hz. The problem is that V-sync isn't exactly 50 Hz but rather 50.0025 Hz, which causes the H-sync to be closer to 15625.8 Hz, which in turn causes the color subcarrier to be closer to 4.43384 MHz. This seems to make it a bit harder for the TV to lock onto it, which causes the TV to sometimes display black and white image. Switching the source to RF and back to AV seems to help with this.

Would it be possible to get the sync frequencies closer to exactly 50 and 15625 Hz? Would it be something that can be done in software or would I have to modify the graphics card? Or both? Maybe replace the card's own crystal with a slightly different one, or increase its load capacitance slightly? Would it significantly affect its communication with the CPU?

https://i.imgur.com/KZl8j0j.jpg
https://i.imgur.com/VQgaol7.jpg
https://i.imgur.com/wdpmIN2.jpg
https://i.imgur.com/hTmNnMC.jpg

----

2024-08-22 Update:

I bought another HD5450 card, different manufacturer than the previous one. This one seems to be better tuned, the horizontal sync frequency is now 15625.1 Hz, and the synchronized subcarrier is 4.43365 MHz. This is close enough for the TV's local oscillator (and a vectorscope I recently obtained) to not have any problems locking onto the colorburst.

I also now use a TDA8501 and a TDA4568 instead of the AD725. It works quite well, but still has some problems mainly caused by the lack of a proper power supply - the whole thing is still powered by 5V from VGA pin 9. The 12V needed for TDA4568 has to be generated using a boost converter that causes some interference, and the whole thing draws so much power that the voltage drops to 4.75V which I assume is the cause of the chrominance having lower amplitude than it should.

For a future version of the encoder I plan to use an external 12V power supply, SAA1043 instead of SAA1101 so the extra pulse counter ICs aren't needed, a single set of standard setting switches for all the chips, NTSC encoding capability, maybe also TDA8505 for SECAM encoding, and an enclosure.

https://i.imgur.com/RPklme3.jpg
https://i.imgur.com/EfOBbzo.jpg
https://i.imgur.com/my2vRhX.jpg

Looks like SC/H is a bit off. I suspect that this is caused by the reference frequencies for the SAA1044 being generated by the pulse counters rather than directly by the sync generator chip, and also the SAA1044 being slightly undervolted. I hope that this will improve when I use SAA1043 and the external 12V supply with 6V voltage regulator.