Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for new "sdtv_mode" for vintage 819 lines TV sets. #1471

Open
f4hga opened this issue Sep 21, 2020 · 6 comments
Open

Request for new "sdtv_mode" for vintage 819 lines TV sets. #1471

f4hga opened this issue Sep 21, 2020 · 6 comments

Comments

@f4hga
Copy link

f4hga commented Sep 21, 2020

I use the Raspberry PI to connect to a vintage CRT television from 1955 (Yes !)
At this time the French standard was 819 lines which was replaced by 625 lines later on.
I have modified my vintage TV for 625 lines, and I am very pleased with the raspberry PI video, which I use to play
old black and white movies.
I would like, if possible a new "sdtv_mode" for 819 lines, so that I could use the TV with its native resolution.
The characteristics of 819 lines is here : https://en.wikipedia.org/wiki/Analog_high-definition_television_system
This is an interlaced system like PAL, only the timings need to be changed, like this:

frequency :50 Hz
Active picture: 737-lines
Field blanking: 41-lines
No. of broad pulses: 1 per field
Broad pulse width : 20.0 μs
Line frequency : 20475 Hz
Front porch : 0.5 μs
Line sync : 2.5 μs
Back porch : 5.0 μs
Active line time: 40.8 μs
Video/syncs ratio : 70/30

From what I saw, these timings seem to be used in linux "display_timing.h" file

If think this mode will interest the community of people fixing these old TV sets.
Thank you in advance.

@popcornmix
Copy link
Contributor

popcornmix commented Sep 21, 2020

I think we're unlikely to add this to the closed source firmware driver, as are trying to move towards the open source kernel driver.

It may be possible to configure the timings using the kernel driver (dtoverlay=vc4-kms-v3d) and standard linux configuration commands.

You may want to look here: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/gpu/drm/vc4/vc4_vec.c for the source which drives the composite output.

(edited)

@6by9
Copy link

6by9 commented Sep 21, 2020

It's actually vc4_vec.c that defines the timings for PAL and NTSC.

Timings are set up by selecting the appropriate output TV standard, however there's something wrong with that as noted in #811 (comment) and https://www.raspberrypi.org/forums/viewtopic.php?f=67&t=271568&p=1719513

To check, is this a mono mode only, or is there a colour subcarrier?

@f4hga
Copy link
Author

f4hga commented Sep 22, 2020

Thank you for the information, I was wondering how the values where computed.
Ii is a mono mode only with no colour subcarrier.
I am not a linux expert (unfortunately), but I think that this modification it just about setting a new option with specific parameters, and should not involve changing the existing code.
Any help or guidance is greatly accepted from my side.
Thanks in advance.

@6by9
Copy link

6by9 commented Sep 22, 2020

I am not a linux expert (unfortunately), but I think that this modification it just about setting a new option with specific parameters, and should not involve changing the existing code.

The parameter that userspace sets for analogue video is the standard to use, not the timings. It's up to the driver to take the standard and convert it to timings and the required setup of colour subcarriers etc. It therefore does require driver changes, but largely only adding an entry into a table or two.

Currently this driver doesn't have a "no colour subcarrier" mode, so that's the first requirement (set VEC_CONFIG0_BURDIS in VEC_CONFIG0).
Secondly you need to define a new standard for this new mode and create a new entry in vc4_vec_tv_modes. As mentioned selecting this new standard from userspace seems to be incorrect at the moment.

Please use the rpi-5.9.y branch if you want to investigate this yourself. The rpi-5.4.y branch has an earlier version of the Pi4 KMS driver and it has a few issues. 5.9 has the latest (final) patchset merged and should be fairly reliable now.

@kFYatek
Copy link

kFYatek commented Mar 18, 2021

I tried to tweak the KMS VEC driver a bit, and also ended up writing this little utility - https://github.com/kFYatek/tweakvec - and as far as I understand the VEC registers, I don't think an 819-line mode is possible.

The video encoder generates 525- or 625-line sync on its own, largely ignoring the timings from PixelValve - well, they seem to be used to sync the beginning of the frame/field, but nothing more; you cannot have a custom horizontal scanning frequency. So unless someone figures out some secret register (which may or may not exist) or does some really weird shenanigans with clock settings, there is no way of generating timings compatible with 819-line sets.

@kFYatek
Copy link

kFYatek commented Mar 21, 2021

Another update: I played with the KMS driver a little bit more, and I think there might be hope for things like 405-line British system, the pre-war German 441-line system etc. The VEC is normally clocked at 108 MHz (eight times the pixel clock, which is 13.5 MHz as per BT.601 convention), but it happily runs at different clock speeds. So by clocking it at e.g. 69498 kHz, when set to NTSC mode, the horizontal scanning frequency becomes 10125 kHz, exactly what the 405-line British system used.

The VEC will also respect timings which use fewer lines than the regular 525 or 625 - so it is entirely possible to create a modeline that will closely approximate the 405-line (or 441-line etc.) system's spec. It will most likely not be fully conformant, but maybe it'll be enough to get a usable picture on a 405-line set. I don't have any of these, so I can't check that.

Anyway, the biggest problem with the 819-line French system is that is has more lines than either the 525-line ("NTSC") or 625-line ("PAL") system. The VEC will generate vertical sync pulse after 262.5 or 312.5 lines on its own if the PV doesn't provide one earlier, so while you can get fewer lines, you can't get more. So anything higher-definition than 625 lines unfortunately seems out of the question and I haven't found a way around it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants