Capture Sizing and Aspect Ratio

NewHome Forums OSSC, OSSC Pro and DExx-vd isl OSSC – Discussion and support Capture Sizing and Aspect Ratio

Viewing 12 posts - 16 through 27 (of 27 total)
  • Author
  • #23472

    The horizontal timings have to be measured with an Oscilloscope so they are not always available. However using the pixel clock as Harrumph said seems to be accurate.

    Pixel clocks for the Saturn can be found here

    Looks like 320×240 is 6.711646875 MHz.


    Sample rates for those modes are already given by FBX in the thread I linked, also you will see if you scroll up I had already written the dot clocks for Saturn earlier in the thread.

    Basically 320 mode is same as Genesis/Playstation in the pin-eight table, and 704 mode is just double time 352 (logical when you look at the numbers).
    Afaik you already get everything you need from FBXs numbers, including the Jaguar.

    Regarding Gamecube you can check out a thread where I discuss this with Jademalo at shmups forum, we conclude the PAR seems not always to be 10:11:
    Maybe at this point it will more confuse than clarify though… 😉

    Regarding AES, I believe they did that to ensure compatibility with home CRT TVs (even CRTs have their limits I guess), lifting the refresh rate from ~59.2 to ~59.6 Hz.


    I still don’t understand how the OSSC outputs 960×720 in 3x mode but the display receives a 1280×720 widescreen signal.
    Does the OSSC respect the advanced timing in 3x (960×240) or it puts them “inside” a more standard 1280×720 timing?
    Can anyone please clarify this?

    If I would have to guess, I would think the display only sees the total vertical pixels (263*3=786) and decides what mode it is by that.
    Since the OSSC is a line multiplier and cannot change the total amount of vertical pixels, that number is set by the multiplier from the base 263p signal.
    That raises the question how the OSSC changes between the 5x 1080/1200 modes if the total vertical pixels are fixed?

    I would very much like answers to these questions since the wiki page is moot about how the OSSC does actual line multiplication.


    @Harrumph, thank you for the help. My apologies and again I’m not trying to be dense here: what is the formula to get PAR given H. active and H. samplerate?

    It seems like you can get it by doing 6.14 / (sample rate * 263 lines * refresh rate), but I feel like there must be a simpler method here.


    You can divide the generic square pixel sample rate, 390, with the optimized sample rate for the console. But do note this will be less exact due to exact optimal sample rates really not being whole integers (but OSSC can ofc only sample as integers). This may or may not make a difference for rounding to integer after line multiplication. So it’s better trying to derive from exact frequencies.

    nes/snes 390/341 = 1,14369…
    True nes/snes PAR: 8/7 = 1,14285…

    Yeah I’m still wondering the same. I even took a look at the ossc code , but didn’t get further than seeing that generic lx3 4:3 was treated as an exception, but I could then not figure out how this exception worked (I hardly know any programming…). EDIT: Rechecking quickly, in software/sys_controller/tvp7002/video_modes.c there is a reference to FPGA_H_MULTMODE_ASPECTFIX under the case MODE_L3_GEN_4_3. But there are so many documents, iirc I don’t think I found this ”ASPECTFIX” anywhere else.


    OK, that’s useful. And just so I’m clear, the 390 (and 780) are constants, and those come from the default Rec.601 spec?

    “So 858 samples for 704×480 -> 780 samples for square pixel 640×480 -> 390 samples for 320×240.”

    ^ you wrote that earlier in the thread, but just checking that 390 and 780 are constants across the board. Looks like 390 samples * 263 lines * 59.9x refresh rate = ~6.14mhz, which correlates with the 1:1 entry on your dot clock page.


    I’m not affiliated with pineight btw, just a useful page I found when I was trying to figure this out myself after I got my first OSSC some years ago. ?

    If you want to read some more on the topic of dot clocks etc, there are some really useful posts by awe44, Marqs and others in this thread:
    I remember the information there and the following page clarified a couple of the relations of this quite complicated topic for me. 🙂


    I’ve updated my Google doc to use the H. samplerate as the basis for PAR and damned if it isn’t close.

    In short:

    Get your source width as SW
    Get your line multiplier (e.g., Passthru = 1, Line2X = 2, etc.) as LM
    Get the H. sample rate from FBX’s page for each console as HSR
    Divide the source height by 240 for source height multiplier SHM

    Target Width = (SW * LM) * (390 * SHM)/HSR

    You can check my values here:


    I still don’t understand how the OSSC outputs 960×720 in 3x mode but the display receives a 1280×720 widescreen signal.
    Does the OSSC respect the advanced timing in 3x (960×240) or it puts them “inside” a more standard 1280×720 timing?
    Can anyone please clarify this?

    Line3x Generic 4:3 is a special case which uses a hack that effectively multiplies all horizontal timings by (4/3) while still outputting 960px wide picture centered on the frame.


    Thank you Marqs.

    I have a few more questions to clarify things further, if that’s okay.

    So in 3x 4:3 mode, H.Samplerate, Sync Length, and Back Porch are multiplied by 4/3, while Active Length stays 960 and padded with black pixels, or padded some other way?

    Is it the same with 5x 4:3 (1600×1200) mode too?
    If so, the wiki page lacks the 3/4 explanation in 5x modes when selecting 1920×1080/1200 formats.
    Also, why 1536×1200 and not 1600×1200 for exact 4:3 as default?

    As for Vertical Samplerate, it is fixed to 263/525 or whatever the input is and cannot be changed, is that why some displays will not accept the 720p resolution since it got more total vertical pixels than the standard?

    I’ve had the OSSC for a year now, yet still have so many questions even with 100 hours of use and endless tweaking. 🙂


    What’s the correct re-sizing for the original Xbox? Is there a specific PAR we should be targeting?

    From a shmups thread, we found that GameCube should be:

    For Gamecube, active pixels with those settings is 660, which is the actual output resolution with square pixels. I’d advise you to crop to this point first to prevent the edges getting feathered on the resize.
    The dot clock rate means it has a 10:11 PAR, so you need to do (660/11)*10, which is 600×480.
    If you’d rather just resize the whole thing then crop (which I don’t recommend, but whatever), then the maths is (720/11)*10, which is 656×480.

    Gamecube is a little bit weird though, but I won’t get into that too much. Read this thread if you’re curious – viewtopic.php?f=6&t=62790
    For all intents and purposes though, the above calculation is correct for what it would have looked like on a CRT.


    Per that same shmups forum, user Jademalo was kind enough to get an answer for Xbox:

    * Same PAR as GC (10:11)
    * Same samplerate as GC (858)
    * Different from GC, Xbox uses the full 720 pixels for horizontal resolution

    As a result, 480p content should be resized to 654.55 (round up to 655) pixels wide.

    I’ve updated my Google doc to match.

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