1920 lines horizontal sampling/output for all inputs + aspect ratio controls

NewHome Forums OSSC, OSSC Pro and DExx-vd isl OSSC – Feature Requests 1920 lines horizontal sampling/output for all inputs + aspect ratio controls

Viewing 9 posts - 16 through 24 (of 24 total)
  • Author
    Posts
  • #14644
    awe444
    Participant

    Do you know whether 512-column PS2 games use different dot clock than usual 480i games (858 dots per line), or whether PS2 internally scales framebuffer width to usual 640/720 output

    I investigated this a while back and measured the following dot clock rates for the PS2’s interlaced modes (assumes a 27MHz source crystal combined with observations from manually tuning the OSSC sample rate on appropriate pixel patterns):

    512x480i : 686.4 dots/line = (27MHz * (2/5) / (4.5MHz / 286))
    640x480i : 858.0 dots/line = (27MHz * (1/2) / (4.5MHz / 286))

    For progressive mode however, both 512 and 640 width games are output in 800 dots/line (the 512 wide games get black borders on the sides).

    #14668
    marqs
    Participant

    @Thomago: You can actually disable the “hidden” upsampling in 240p/288p/384p/480i/576i Line2x modes by enabling “AV3 interlace fix”. That way you can crank sampling rate to 2046 and still get a picture.


    @paulb_nl
    : It’d need a fixed pair of PLL outputs, e.g. 2x for sampling and 5x for output. In theory, Cyclone IV PLLs could be configured dynamically with ALTPLL_RECONFIG, but it’s not very flexible in practice (if I recall right, you can only switch between pre-defined configurations).


    @awe444
    : Are you sure native progressive mode games use 800 dots/line output? From what I could gather from an unofficial PS2 video mode doc, default parameters for DTV-480p indicate standard 858 dot output (sum HSVS and HS columns of SYNCH1 listing). For VESA 640×480 (VESA-1A), the number is spec-compliant 800, but it’d be a bit surprising if progressive scan games really use this mode.

    #14673
    paulb_nl
    Participant

    @marqs Doesn’t the OSSC use fixed PLLs for everything? If you would implement 5/2 for 480pX2 then it would work for both 640 and 720 sampling right? It would be great to be able to play 480p content without the monitor stretching it to 16:9.

    #14678
    Anonymous
    Inactive

    @marks: That works! However, H. samplerate = 2046 gave me a squished picture; with H. samplerate = 2288 (858/720*1920=2288) it looked as intended.
    I tried that with a 480i signal. Without manual adjustments, my monitor is compatible to passthrough as well as Line2x and Line4x; with manual adjustments only Line2x mode worked. I’d really like to use Line4x mode, as it might enable “constructing” a crude 1280×960 output mode, which would display in 4:3.
    Any ideas about that? I already tried stuff like enabling upsample2x and halving H. active to 960…

    #14685
    awe444
    Participant

    @marqs yes, I can confirm the 800 dots/line value for 480p directly from observations with the OSSC. It was an RGsB signal and I was using “VESA” sampling setting on the OSSC at the time (not the “DTV” setting). Also worth noting that I was using the GSM forced mode with “VGA” in the label (as opposed to the mode with “HDTV” in the label). Hence it is quite possible there’s a 858-dots/line mode for 480p as well.

    #14773
    marqs
    Participant

    Yeah, I’d guess all games that have native 480p support would use HDTV mode.

    #14853
    tcdev
    Participant

    @paulb_nl: In theory, Cyclone IV PLLs could be configured dynamically with ALTPLL_RECONFIG, but it’s not very flexible in practice (if I recall right, you can only switch between pre-defined configurations).

    Not quite. You can configure all the parameters from the NIOS, however they don’t publish the algorithms used to generate those parameters given the desired inputs and outputs.

    On a Cyclone V design we have a large number of PLL configurations – 30+ from last count – so I generated them all in the PLL wizard and then post-processed the .mif files to produce a series of arrays in C source for subsequent programming from the NIOS. Once you’ve got the QSYS and NIOS code working it’s pretty quick and painless to add another PLL configuration; in this case about 1 minute.

    An earlier incarnation was based on Cyclone III and my colleague ‘reverse-engineered’ the algorithms to produce the – admittedly simpler – PLL parameters on-the-fly for arbitrary clock values. At that time I only had peripheral involvement with the project but AFAIK it was successful for every case they required/tested.

    FWIW the above-mentioned designs are video boards that (amongst other functions) sample analogue RGB via the TVP7002 and drive digital video (DVI) out. That 7002 is a PITA, but then again my primary role was FPGA design and NIOS code and little to do with actually getting the video to work. At one stage – with the previous-gen hardware – I built my own cut-down version of the FPGA and was running both a Coco3 and Amiga on a VGA monitor. We had designs on producing a monster video converter for every system/configuration imaginable – there was an option to load composite video input connectors and it already had a triple frame buffer with clipping, scaling etc – but we were too busy with real work to do much about it.

    #14868
    marqs
    Participant

    @tcdev: Yeah, storing relatively large arrays/.mif:s for mostly similar configurations is not optimal considering current memory limitations. Also, many of the desirable fractional ratios are not achievable with Cyclone PLLs (indicated by a PLL wizard warning), limiting benefits of fully dynamic configuration even if that was made available (e.g. via reversing) for Cyclone IV.

    Out of interest, what made you select TVP7002 for your project? Did you try any of the alternative RGB video digitizers (which there are not too many publicly available)?

    #14871
    tcdev
    Participant

    @marqs: Yeah, storing relatively large arrays/.mif:s for mostly similar configurations is not optimal considering current memory limitations.

    For Cyclone IV (not III as I previously mentioned, that was the other FPGA on the board), we had 26 bytes for each configuration, though it’s possible that could be optimised. Our NIOS code was stored in external flash (EPCS device IIRC) and ran from DDR, so no such memory limitations for us! For Cyclone V, each configuration requires 6x 32-bit values, so about the same. It probably (also) depends on the number of output clock’s you’re using…

    Those design decisions were made by our client, not us (contract design engineers). That particular client was a component distributor and chose most of the silicon for us to use in the design, including the TVP7002. We have it all under NIOS control, so at least it’s trivial for us to tweak the registers.

Viewing 9 posts - 16 through 24 (of 24 total)
  • You must be logged in to reply to this topic.