PAL-M is broken

[franmagneto]

When I boot with sdtv_mode=3 or use tvservice -c "PAL_M 4:3" I get 720x576 at 50Hz, but it should be 720x480 at 60Hz like NTSC, that's the correct format for PAL-M.

[popcornmix]

You are right that the behaviour doesn't match the description of PAL-M.
The code seems to change resolution/refresh and colour carrier settings bases on the sdtv mode chosen.
I don't have any PAL-M equipment to test, but I've made changes to the firmware to match what I understand is correct. I may have misunderstood things.

Can you try this test firmware:
https://drive.google.com/uc?id=0B-6zmEDJwxZEd0RhcFR6NHlyXzQ&export=download

and let me know if the behaviour seems better?

[franmagneto]

Thanks for your reply. With this firmware the resolution and frequency is correct, but it still have no colors. If I plug it on a TV expecting NTSC, it shows wrong colors, I think this is not expected, because reading about PAL-M on Internet, it's said that NTSC signal on PAL-M TV shows correct picture, but without colors, and the same happens with PAL-M signal on NTSC TV.

[popcornmix]

So you are testing with a TV that only supports PAL-M?

What was the behaviour with the original firmware?
What is the behaviour with the test firmware?

[pelwell]

Although I haven't found a definitive statement, I suspect that PAL-M uses a 3.58 MHz colour subcarrier (like NTSC) but with PAL encoding, rather than the 4.43 MHz subcarrier of PAL-60.

[popcornmix]

Yes, according to firmware code:

PAL             /* PAL-B,G offset :  4.43361875 MHz. Clock is 13538462. */
PAL_M           /* Colour subcarrier - 3.575611 MHz. Clock is 13369909. */
NTSC/NTSC-J     /* Colour subcarrier - 3.579545 MHz. Clock is 13369909. */

[franmagneto]

You're right, the colour subcarrier frequency is not the same as PAL-60. I have a PAL-M only TV, that outputs monochrome with NTSC signal. When I choose PAL-M on the original firmware the behaviour is the same if I chose PAL, it shows no color and I see horizontal stripes moving. With the new firmware it shows the same as NTSC, clean picture but with no colors. I can use a friend's TV that works with NTSC signal, and on that TV I can see colour with the new firmware, but it's wrong, the four raspberries logo on boot shows like a "rainbow", with color changing along the logos.

[franmagneto]

It still doesn't work with PAL-M, when this mode is selected, the output is NTSC with a "rainbow" pattern

[franmagneto]

I'm still getting no color if the TV is PAL-M. If the TV is set to NTSC, it shows a rainbow pattern, but it must show no color. Maybe the color subcarrier frequency is wrong, I think it must not be the same of NTSC. Wikipedia says that a PAL-M signal shows no color on NTSC TV and vice versa.

[ghost]

I'm also facing the same problem. The equipment I'm using is a National (Panasonic) Panacolor TC-14R1M in pretty good shape, quite popular back in 70's.

I was using a really old Retropie build (outdated for +6mo), so I decided to update the distro+firmware. No luck.

I also tried patches you've released here: #811.
I also tried a clear install + rpi-update (master), but it didn't work.

Then I tried back again to use #811 patches in top of up-to-date fresh install, but it still didn't work.

I started changing sdtv_mode values in /boot/config.txt through PuTTY, save and reboot, and this is what I've found:

Tested with master build 18/07

0 - OK BW
3 - Rolling Screen (BW)
10 - Rolling Screen (BW)
11 - OK (BW)
12 - OUT OF SYNC
13 - OUT OF SYNC
14 - OUT OF SYNC
15 - OUT OF SYNC
16 - OK (BW)
17 - OK (BW)
18 - Rolling Screen
19 - OK (BW)
20 - OUT OF SYNC
21 - OUT OF SYNC
22 - OUT OF SYNC
23 - OUT OF SYNC
24 - OK (BW)

0x20 - I do not recall the result, but no color.
0x22 - I do not recall the result, but no color.
0x30 - OK (BW).
0x32 - Rolling Screen (BW).

Build 23,25 and 27-May patches: #811

0x22 - OK
0x30 - FLICKER (BW)
0x32 - CRAZY FLICKER (BW)

*Out of Sync - Static, no image at all.

I gave up testing because results of #811 although the sync issue, at least they were showing colors. I also tried the sdtv_progressive_scan, but results shown async.

I'd like to help as much as I can. If you provide me firmwares I can trial and error and report results, take pictures, anything.

Thanks in advance.

Best Regards,

[Sobakin76]

I own RPi 3b, and one of my CRT composite monitors is 15" Hitron CVM1574FP which supports many signal standards, including PAL-M.
In Raspbian after sending next commands:
tvservice -c "PAL_M 4:3 P"
fbset -xres 640 -yres 240 -match -a
fbset -depth 8;fbset -depth 32
when monitor in Auto mode it autodetects as NTSC or when I choose NTSC manually it shows this pitcure (running Midnight Commander):

Absolutely the same picture is in another monitor, JVC TM-H150CG, which autodetects sync and color system independently, so it correctly supports PAL-60 but I don't know about PAL-M (don't have such properly working signal source to check):

You may see what a little part of picture (column right after center) is shown in correct colors, but monitors in NTSC mode, not PAL-M.

When I switch monitor (Hitron) manually to PAL M, it shows B&W picture:

And when I switch RPi output to NTSC by
tvservice -c "NTSC 4:3 P"
It autodetects NTSC and shows correct image, except NTSC color artifacts, which almost no see on this photo:

but I don't like NTSC because of color artifacts in games (Grand Prix Cirquit in 4-color CGA mode in DOSbox), on both monitors the same (first is Hitron, second is JVC):

In pure PAL colors is ok, but image flickers (50Hz only) and is too compressed in vertical because higher scan lines count (288 lines in PAL vs 240 in NTSC/PAL-M/PAL60 progressive)

[ghost]

Okay, I've tried

tvservice -c "flag 4:3 (P)" with NTSC, PAL and PAL_M, also enabling/disabling P progressive scan. Just after doing setting tvservice, images goes black, reboot and all of them image pops up. No rolling screen or static. Clear, but no colors. :/

[Sobakin76]

tvservice -c "flag 4:3 (P)" with NTSC, PAL and PAL_M, also enabling/disabling P progressive scan. Just after doing setting tvservice, images goes black

After change mode by tvservice command You need to reset (or reinitialize?) framebuffer by commands:
fbset -depth 8;fbset -depth 32
Just make batch file (.sh) with this command sequence.
But this is offtop.

[ghost]

I do not know if I'm doing this correctly (no .sh skills) but:

1. Accessed through Putty.
   

2. Send command tvservice -c "PAL_M 4:3 P". This happens.
   
   A rolling line is noticeable

3. sudo reboot. This happens:
   
   Skewed image

4. It does start normally, clear image but no colors.

[franmagneto]

@Sobakin76 that is the output I get when I try to use RPI PAL-M signal, Black and White on PAL-M and that kind of "rainbow" pattern on NTSC (which is also the format that is autodetected).

[franmagneto]

Unfortunately, I do not have the TV I've used to test this anymore.

[franmagneto]

But I have a really old TV that I guess it supports only PAL-M.

[franmagneto]

But I've never seen color output on it using the AV connectors, because all equipment available are NTSC. With RPI I tought that I'd finally see color output through AV cables on that TV...

[Sobakin76]

Looks like software development of anologue output was stopped. It is sad :(

[ghost]

Indeed it seems to be stopped. But that's life hehe.
I'm going to try finding a technician who might convert it to NTSC (change the crystal etc) and last case, buy a NTSC-> PAL-M transcoder.

Thank you all.

[JamesH65]

Because analogue output is such a tiny use case, we can only really work on it when there is nothing more important to do. However, we are a small team, with a awful lot of very important work to do....

So, not stopped, just we don't have time to work on this sort of thing at the moment. Maybe @popcornmix is the expert here, but I know he is very busy. I don't know wanything about this stuff, so cannot really help. @pelwel Any ideas?

[ghost]

I agree with you James. There are plenty of important stuff to be done and this is a minor issue that may be bypassed by other means, such modding the TV set.

I do not want to sound rude, and this is not sacarsm. I realize most of us have got other stuff to care in life, such family and work, I've followed couple issue threads that popcornmix kindly put his/hers effort so I really do not to sound ungrateful. When the time comes, soma changes will be done, I'll keep updating rpi-update, check and report when I get a positive result.

Cheers ;)

Thanks once again,

[JamesH65]

No worries - you didn't sound rude - just wanted to get across that we are busy with stuff right now, so unfrotauntely this sort of thing cannot get much attention.

[kFYatek]

Hi,
Sorry for digging up such an old issue, but I have some additional insight. I'm writing a bit of code that simulates PAL/NTSC/SECAM encoding/decoding in software, so I thought that I might just as well try debugging the Pi's PAL-M output a little bit.

Everything was tested on a Raspberry Pi 3B+ with the latest firmware downloaded using rpi-update at the time of writing this post.

From my experimentation, it looks that whatever the Pi outputs with the sdtv_mode=3 setting, is not really PAL at all, but rather an NTSC-ish signal with a different subcarrier. Namely, 229.5×fH, which is 3611013.(986013) Hz.

Standard NTSC subcarrier is 227.5×fH (3579545.(45) Hz), and standard PAL-M subcarrier would be 227.25×fH (3575611.(888111) Hz).

Here's why I think that. I took this rendition of the PM5544M test pattern:

used my code (I'd rather not show it at the moment, it's quite messy) to encode it as a standard NTSC signal (227.5×fH subcarrier):

and then used my messy decoder tuned to 229.5×fH subcarrier (intentionally without any kind of comb filtering, to maximise use of Pi's color modulation):

Then I displayed that "decoded" image on the Pi that was configured to sdtv_mode=3:

DISPLAY=:0 pqiv -i --fullscreen decoded.png

and grabbed the output using a USB composite video grabber configured to standard NTSC:

As you can see, the final colors are almost correct. Here's what I read from that:

• The subcarrier is indeed 229.5×fH (3611013.(986013) Hz), or perhaps something very close to it - see the next point
• The slight inaccuracies shown in the blue bar and bottom-center red part may be either due to imperfections in my encoder/decoder, the Pi's modulator (unlikely, knowing that regular NTSC and PAL outputs work perfectly), or a slightly mismatched subcarrier frequency.
• All signals involved in generating this image are NTSC-style, i.e. there is no phase-alternation between lines. This makes me pretty sure that the Pi is not outputting a PAL-style signal at all. In particular, this grabber uses a comb filter - in NTSC mode, chroma information from subsequent lines is averaged. If the Pi was really outputting a PAL-style signal, there would be discoloration and instability due to the V channel being phase-alternated and as such averaging as zero - yet nothing like that is happening.
• The cross-color patterns interpreted by the comb filter as luma are slightly diagonal, which would also confirm the theory of my subcarrier frequency calculation being slightly inaccurate.

Anyway, the sdtv_mode=3 mode is definitely not PAL-M, but rather could be called NTSC3.61 - that is a format so non-standard that I don't think there has been any TV in existence that could display it. Basically, a useless setting. I agree with the previous posts that this is probably minor, PAL-M was almost exclusive to Brazil, and Brazilians stuck with PAL-M-only sets can mod them or use an NTSC-to-PAL-M transcoder. But I thought I might share my analysis in case anyone decides to try fixing this issue, after all.

[kFYatek]

If anyone is still interested, I've written a little utility for tweaking the VEC registers from user space: https://github.com/kFYatek/tweakvec

Configuring the firmware and OS for NTSC and then running sudo ./tweakvec.py --preset PAL-M should give you clear PAL-M. You might also want to add --pedestal 1 if the image is too dark - I'm not sure whether the black level pedestal is supposed to be there in PAL-M or not.

I tested the utility, but only with modern equipment, I don't have any CRTs (and certainly not PAL-M-capable) on hand.

[kFYatek]

Update: @Sobakin76 confirmed PAL-M working with their monitor, see #811