raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.15k stars 1.68k forks source link

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

Open f4hga opened 4 years ago

f4hga commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/raspberrypi/firmware/issues/811#issuecomment-683153942 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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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.