Menu

RF & Composite support

Home Forums OSSC OSSC – Feature Requests RF & Composite support

This topic contains 9 replies, has 6 voices, and was last updated by  iGPLTV 4 months, 3 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #19666

    renegadeandy
    Participant

    Hi,

    I would love to see RF & Composite input support. I understand this would introduce board changes, for me it is a major hole in the ossc’s functionality.

    #19667

    nmalinoski
    Participant

    I think it would be more economical to develop a discrete RGB/YPbPr decoder device that can take S-Video, composite, and RF; rather than integrate this functionality into the OSSC.

    Whether or not decoding functionality is integrated into the OSSC, the chips required are scarce, if available at all, and such a device will likely require yet another FPGA to perform the decoding.

    Currently, it seems the best options for S-Video and Composite are 1) finding a pro decoder to get RGB and/or YPbPr, or 2) dealing with the lag and lack of quality of the cheap scalers you see on Amazon; and the best options for RF are a) finding an old VCR with S-Video or component out, or b) finding a standalone analog TV demodulator–both of which you’d probably need to run into the decoder/scaler you use for composite and S-Video.

    #19670

    renegadeandy
    Participant

    Hi nmalinoski, I understand and here you, but all of your suggestions completely undermine the purpose and simplicity the ossc delivers.

    @marqs what are your thoughts on this one?

    #19678

    nmalinoski
    Participant

    all of your suggestions completely undermine the purpose and simplicity the ossc delivers.

    Depends on your point of view, I suppose. To me, adding RF, composite, and S-Video would undermine the simplicity of the OSSC as it exists now. Integrating those additional formats would require a redesign (likely a new, larger FPGA, and more complicated software), and that would do nothing for existing OSSC owners.

    A standalone decoder would work for all existing OSSC owners, and it would have purpose beyond just the OSSC, such as letting people like me connect S-Video sources to their recent TVs that have YPbPr but lack S-Video.

    And besides; since RF and composite are so heavily degraded to begin with (S-Video is actually pretty fine), something like this would only be a stopgap for most interested people–to hold them over until they can get an RGB or HDMI mod installed.

    As for the rest of my post, I wasn’t attempting to suggest alternatives; rather I was trying to illustrate the less-than-desirable hoops that we currently have to go through to connect our legacy consoles to modern displays.

    #19687

    renegadeandy
    Participant

    Understood nmalinoski. But I really still would like to see it, of course in a new OSSC board revision. Please help @marqs, I can help design it.

    #19710

    BuckoA51
    Keymaster

    This one again 🙂

    If this happens it will be an external transcoder type device, it doesn’t make sense to add functionality and cost to the base product that many people will never need or use. However despite approaching several companies to get a transcoder, none of them seem to be able to come up with one that will support 240p (we got close with a company in the US but their transoder failed with 240p). All ICs that older transcoders are compatible with are long since out of production.

    I’ll keep trying.

    #20166

    SpeccyFan
    Participant

    I’ve recently ordered myself OSSC, intending, apart from all RGB-capable machines that I have, to plug composite and s-video machines like C64 and Atari 65XE. Then I realized there’s no support for those 😛

    I thought about making some kind of composite/s-video to RGB decoder using older analog TV circuits and processors like TDA3566, TDA8362+TDA4665, etc. I still considering making such decoder as the “last resort”.

    I don’t know yet all the technical details of what’s going inside the FPGA of OSSC and how full it is at the moment, what kind of sample rates are used, etc., but I have this theoretical idea that maybe, color demodulation of PAL/SECAM/NTSC may be offloaded onto FPGA, so those inputs could be implemented without extra hardware at the cost of extra logic inside FPGA.

    From what I’ve figured out (I may be wrong here), in order for that to work, those conditions need are needed:
    1. Composite video/S-video luma is plugged into green channel of RGB input, so ADC can extract sync from it as if it were sync-on-green. I suspect that I should be atleast able to see monochrome image from composite in RGsB mode – that “trick” seems to work with CRT television that I have. ADC most likely doesn’t care if it received RGB or composite, we just need to extract signal value;
    2. ADC on the board can be set up to pass the entire line of data (to extract composite colorburst portion) into FPGA with sample rate high enough to accurately sample colorburst to properly sync to it – seems possible, judging by its (TVP7002) datasheet;
    3. There’s enough space in FPGA to put a PAL/SECAM/NTSC color demodulator in there and how much will it take – I don’t have any idea at all. And, as far as I’m aware, nobody wrote such demodulator at this point.

    I might tinker with that idea in my spare time once I receive my OSSC, not sure what would come out of it, if anything.

    #20188

    marqs
    Participant

    I shortly thought about possibility of custom PAL/NTSC decoding at some point, and while theoretically possible, I concluded that it would require a bit too much effort with end result likely not looking very good (even for composite). I think the largest issue is the lack of exact subcarrier clock. The only fixed clock on the board is 27MHz, and I’m not sure if you can get very close to 3.57MHz (NTSC) or 4.43MHz (PAL) frequency or their multiples using Cyclone IV PLLs. Even if you were able to sync to color burst (should be possible), phase error towards end of a scanline would get severe unless you had good enough frequency reference. With some systems it might be possible to derive subcarrier frequency from line period, but that’d lock you into a specific sample rate.

    DSP part of the implementation (QAM demodulation) would include implementation of mixers(multipliers) and various filters (low-pass, bandpass, comb) which should be possible with the FPGA’s resources even though analog implementation would sound more natural (for me at least).

    #20215

    SpeccyFan
    Participant

    Yeah, same as my thoughts, more or less. I wonder if phase error accumulation could be mitigated by DDS with high enough phase resolution, but it depends on the sample rate. Hmm.

    I decided not to mess with old TDAs in the end, some of them are “unobtanium” for me anyway. I have a whole bunch of TVP5150AM1 ADCs and a small Cyclone II board sitting around gathering dust, so I might as well try to build a one-off composite/s-video -> YPbPr/VGA/etc converter and use it with OSSC :). I’ve seen cheap composite to VGA converters being sold in many places, youtube reviews suggest that they don’t get along with home computers at all.

    #21206

    iGPLTV
    Participant

    I would prefer for them to make a box to do that so I can use it without buying a new one (alot).

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.