Need to verify PAL functionality

[Roger-random]

When I extracted the video signal generation code from ESP_8_BIT, I tried to preserve PAL support. Since I only have a NTSC TV, I couldn't verify that PAL support is still functional. I would appreciate one of the following:

1. Someone to test PAL and verify it works.
2. Someone to fix any PAL problems and create a pull request.

Note that I can't do anything about "PAL doesn't work" absent a fix, as I have no way to diagnose, debug, or verify fixes without a PAL TV.

[bootrino]

As I mentioned on Twitter ... newer analog televisions often have both NTSC and PAL built in. You might easily find a cheap one that supports both, making your development easier.

[Roger-random]

I hadn't known that! Thanks for the tip.

Unfortunately the TV I have on hand doesn't seem to be bilingual. Or maybe it is, and my PAL path is broken. I don't know how to tell between those two possibilities.

And it just occurred to me that there is ambiguity even if a picture was displayed. Maybe my PAL path is broken in a way that sends valid NTSC, and a TV that understands both would show the picture for a false sense of confidence.

This problem has become more interesting than I initially expected.

[bootrino]

The TV I have has a menu option to choose PAL or NTSC. I picked up the TV from outside someone's house who was throwing it out.

[Roger-random]

Thanks to @bootrino I went looking in my hoard of hardware. I found a video projector with support for both NTSC and PAL, and it also has an information screen showing which video signal format it is. This allowed me to find and fix a small visual artifact bug and now I can say the library supports both PAL and NTSC with confidence!

[kostuch]

Hi Roger, I tried to run your code with PAL, but it doesn't work for me. This same tv monitor I tested with bitluni's PAL code and it works. Also it works with your code set to NTSC. Are you positive, that it still works with PAL? Unfortunately I don't have good enough oscilloscope to see what's wrong with the signal.

[Roger-random]

Sorry to hear there are potential problems with PAL mode.

I can confirm it still works with my representative PAL device: BenQ MS616ST video projector. I don't know how it differs from your PAL device. If you can uncover additional technical details please open a new bug for tracking and hopefully we can figure something out.

[kostuch]

Thank you for the confirmation, that on your device code works with PAL. My device is small LCD car monitor (but as I wrote, it has no problem with Bitluni's PAL code). No place for real tv set on my desk :)

I managed to get picture changing function void ESP_8_BIT_composite::begin() At the end I put call to video_init() with first parameter set to 3 instead 4 // Start video signal generator video_init(3, !pal);

But the picture is without the colours and shifted to the right side.

[kostuch]

I wonder if the logic related to pal variable is ok? No matter if I initialize SP_8_BIT_composite videoOut(false); or SP_8_BIT_composite videoOut(true); This variable in function start_dma() is always false and the fragment

    if (!_pal_) {
        switch (samples_per_cc) {
            case 3: rtc_clk_apll_enable(1,0x46,0x97,0x4,2);   break;    // 10.7386363636 3x NTSC (10.7386398315mhz)
            case 4: rtc_clk_apll_enable(1,0x46,0x97,0x4,1);   break;    // 14.3181818182 4x NTSC (14.3181864421mhz)
        }
    } else {
        rtc_clk_apll_enable(1,0x04,0xA4,0x6,1);     // 17.734476mhz ~4x PAL
    }

always initialize NTSC section

Forget above - I made mistake in my trials/errors. I have to find another device with analog AV input.

[kostuch]

Hi, Just for the record. I played a bit with this library on PAL equipment. Apparently there are devices more and less sensitive for horizontal synchronization patterns. On the most modern tv sets it doesn't matter what combination is set in table uint8_t DRAM_ATTR _sync_type[8] = {0,0,0,3,3,2,0,0}; Even {3,3,3,3,3,3,3,3} (eight long sync lines) works fine.

But in case of some devices, you should avoid sequence starting with short sync lines. I have monitor like this: https://www.amazon.com/Monitor-Screen-Foldable-Resolution-Engineer/dp/B092MFM2YW/ref=sr_1_4?keywords=backup+camera+monitor+only&qid=1641491697&sr=8-4

Standard pattern give no picture, but if you drive it with {3,3,3,3,3,2,0,0} or anything that start with some long sync lines, picture is fine. Maybe these cheap chinese monitors are out of specs, but this is the only way to make them work with this lib.

[bootrino]

Pretty much any "recent" analog TV supports both NTSC and PAL - these are easily and cheaply purchased on eBay or similar second hand sites.

[Roger-random]

Thanks for the info @kostuch. Unfortunately I'm not familiar enough with PAL details to know which should be the correct solution. Perhaps I can document alternate _sync_type values as something people can tailor to fit characteristics of a particular display?

[kostuch]

The default PAL sync pattern is exactly {0,0,0,3,3,2,0,0}. As I wrote - these cheap lcd car monitors are just "close to PAL specs" and need other sequence to get stable picture. They also accept NTSC, but picture in such case is too big to fit screen area. Also NTSC picture on every device I tested, showed slightly different (infamous Never This Same Color ?)

By the way: is there any specific reason to generate only 256x240 resolution? I modified (PAL fragment) to create 288x240 picture. The unused side borders are much smaller.

[Roger-random]

256x240 was the resolution used in the SEGA emulator portion of ESP_8_BIT, from which this project was derived. I chose SEGA over the Nintendo or Atari portions because I preferred its RGB332 256-color palette.

256 pixels per horizontal line, being a power of 2, also makes it convenient to allocate aligned frame buffer memory.

Those are the reasons, they may or may not apply to a particular project. If you can make it work at another resolution that fits a specific display better... by all means go for it!