[Zacabeb]

Since the OSSC Pro oversamples the input at low resolutions and discards samples to reduce jitter, it’s harder for it to find an optimal phase setting.

What I do instead is to set the phase manually by finding the worst setting that blends pixels the most and then offset the phase from that by 180°. It gives a good approximation of optimal phase.

[Zacabeb]

Going by what I can find, while the AV output of the Neo Geo AES has the same pinout as the Genesis/Mega Drive model 1, they use slightly different DIN connectors. That makes them mechanically incompatible if outfitted with the RGB pins unless you use an adapter dongle. Check that the two pins in the DIN plug closest to the key indentation haven’t been pushed in or become bent. Many RGB cables for each console may take its sync signal from pin 7, which is one of the pins that are aligned differently (the other one is pin 6 which is used for red.)

If you don’t have an adapter, you either need one or a bespoke Neo Geo RGB SCART cable to avoid damaging the Genesis/Mega Drive one.

If, on the other hand, the cable is not outfitted with the full set of pins in the DIN plug it will fit without problem in both consoles but only carry composite video, making it incompatible with the OSSC Pro since it requires RGB (unless you outfit it with the Legacy AV In expansion to get separate composite and S-video inputs.)

[Zacabeb]

When it comes to the PS2, games can run in various horizontal resolutions which are pixel repeated in its output. There the optimized timing in the OSSC Pro has to be selected to match the resolution a particular game runs in, which requires either trial and error to find the best match, or looking up if others have already established in which resolution the game runs. If it’s mismatched there will be alternating bands where the picture is sharper and softer.

Using the generic timings the OSSC Pro captures the picture in a much higher resolution, better accommodating the various game resolutions. It’s a tradeoff between convenience and trying to get absolute pixel accuracy in a particular game.

The GC as far as I know doesn’t support the plethora of rendering resolutions the PS2 does, so there the optimized timings may work more broadly across games.

[Zacabeb]

Yes, it’s largely that things look different. It’s not just nostalgia – it’s that with a scaler like the OSSC Pro the picture reproduces the source so cleanly that it reveals the limited resolution of the source as well as any cheats used by developers to hide it. Since we also tend to use much larger displays now than we did then, the perceived resolution is different.

Finally, CRT displays had a particularly pleasant softness that didn’t feel blurry because of spot size and blooming, something which is hard to emulate. The shape and falloff of the spot belied the limited resolution and made the picture feel sharper than it actually was.

[Zacabeb]

On the Xbox, both 720×480 and square pixel 640×480 are in fact supported rendering resolutions, but how they’re handled for output differ between encoders as mentioned in another thread. 🙂

Square pixel 480p (780 samples per line) of course differs from VGA (800 samples per line,) making them incompatible for proper aspect ratio and centering. But there’s nothing stopping the use of any pixel clock in analog video so long as the signal is within bandwidth, permitting NTSC square pixel and BT.601 to coexist.

There is a dilemma when it comes to ITU-R BT.601 and derived 480p and 576p standards. The pixel aspect ratios aren’t always adhered to in accordance with legacy. When converting HDTV to SDTV or EDTV, scaling down to cover the full 720 pixel raster including margins instead of the correct 711, 704, or 702 pixels was not only technically easier, but helpful as it extended picture into the blanking area for masking to suppress ringing from the leading edge of active video. The vertical scaling was not modified to keep the proper pixel aspect ratio, leading to new pixel aspect ratios. The same can happen in upscaling to HDTV. The assumption was that the discrepancy would be small enough go unnoticed by most viewers.

The standards have actually become quite a mess. 😄

[Zacabeb]

Regarding the Conexant CX25871, looking at the datasheet again there is no preset configuration for square pixel mode, but it seems flexible enough in configuration that it likely supports square pixel output. I can’t verify it though. What I think happens in monitor mode is that it works as a pure video DAC, bypassing the scaling and filtering section (including the conversion to YCbCr and subsampling to 4:2:2.)

When it comes to the Focus Enhancements FS454, the supported output clocks are listed in the Software and Firmware reference document under “1.3.2.2 Graphics Modes for SDTV” and “1.3.2.3 Graphic Modes for HDTV” and don’t contain a square pixel mode. It scaling the output of 640×480 games to 720×480 is also consistent with the optimized timings derived by Sestain and listed on the Classic Console Upscaler Wiki. The timings match the ≈53.33 µs/106.67 µs of 720/858 samples rather than the ≈52.15 µs/104.30 µs 640/780 samples of square pixel mode. https://junkerhq.net/xrgb/index.php?title=Xbox

Finally, when it comes to the Xcalibur, as there’s no publicly available information on it, I’m just going by observation. Setting up optimized modes on the OSSC or OSSC Pro for square pixel operation with 780 samples per line and 640 active pixels gives proper width and pixel recovery with games that render at 640×480, while setting it to 858 samples per line and 720 active pixels does the same with games that render at 720×480 (such as DoA3.) The picture is still heavily filtered though, so it’s not pixel perfect, just with less moiré.

Since the encoders are long out of production, the datasheets may be hard to find. In that case I can email them to you. 🙂

[Zacabeb]

The way the Xbox behaves differs a bit depending on the video encoder used. The Conexant and Xcalibur both support native 640×480 square pixel output in addition to 720×480 DTV output, but the Focus upscales square pixel content to full width 720×480 before output.

[Zacabeb]

It’s for antenna input although it seems it won’t be integrated onto the board until the firmware support for it has been worked out (it probably costs too much to include just for good measure.)

If it’s going to remain the Skyworks Si2177 tuner, it will be multistandard (B/G, D/K, I, M/N) and the existing ADV7280 video decoder in turn decodes pretty much all flavors of PAL, NTSC, and SECAM. Sound in turn will be mono only (no MTS, A2, or NICAM) as there are no means of decoding other formats, but since no console or home computer did stereo sound over RF as far as I know that won’t be an issue.

[Zacabeb]

If you’re using the generic timings, you need to adjust H.active and V.active of the mode currently in use by the OSSC Pro. The mode in use is usually preselected when you go to the advanced timings option, but if not you may have to find out which of the timings it is using. About 0.85x the original H.active value should make the PS2 image fill the screen.

You may want to disable framelock while making adjustments to reduce screen blackout as the OSSC Pro reestablishes sync with the input.

[Zacabeb]

I too had problems with the update initially not installing but the OSSC Pro getting stuck. After power cycling it functioned as normal however and I was able to upgrade the firmware from 0.76 to 0.77 without it taking very long at all (half a minute or so.)

[Zacabeb]

The flickering interferes with the polarity inversion done in the LCD to reduces image retention, with some models of panel being more sensitive than others.

I don’t know the exact timings for the N64 but I checked the optimized mode for it in the OSSC Pro. There the sample rate is set to 773.5 samples per line and 640×240 active pixels, so that could be a starting point for the OSSC Classic as well (the other parameters don’t carry over directly from the OSSC Pro to OSSC Classic.)

Given that the horizontal sync in 480i is 4.7 µs out of about 63.55 µs, the horizontal sync length should be set to around 57 or 58 and vertical sync left at 3. From there you can then adjust the horizontal and vertical backporches to align the picture.

For the PS1, from what I can find the sample rate should be 853.25 (rounded to either .20 or .30 I guess) with an active area of 640×240 and a horizontal sync of 63. The dot clock reportedly varies between hardware revisions though, so it might not be correct for your PS1.

Hope it helps. 🙂

[Zacabeb]

I’ve tried the same thing briefly and it does work fairly well, although I imagine the HDMI input on the OSSC Pro could be sensitive to jitter and require tweaking in the OSSC just like with displays.

There could also be limitations with higher scaling modes from the OSSC Classic, but there of course it can be set to a lower scaling mode or passthrough and let the OSSC Pro handle the scaling.

One of the limitations is that internally, the OSSCs can combine an unusually high sample rate with a low line rate to oversample the input, but that cannot be carried over from one OSSC to another over HDMI outside of using corresponding scaling modes before sending things across.

So passthrough of e.g. 240p won’t be higher than the normal ~860 samples per line while 2x or 4x modes can be higher. With 480i and 576i you may want to use passthrough to take advantage of the OSSC Pro’s adaptive deinterlacing in Scaler mode, but then too you’re limited to the OSSC Classic using a lower sample rate.

It can also get confusing when tweaking each OSSC as their menus have the same color scheme.

But with all those things considered, there’s no reason not to test it and check what works. 🙂

[Zacabeb]

Excellent suggestions! 🙂

I hope more people may join in on development to help implement those features. It feels like marqs is already doing the most he can in his spare time but a lot of our suggestions may go beyond what he has the time for.

[Zacabeb]

While @marqs can give a more accurate answer, my understanding is that since A-LM only uses a limited number of input lines for buffering, it shouldn’t cause much of a delay. The specs at https://junkerhq.net/xrgb/index.php?title=OSSC_Pro#Getting_started state a maximum latency of 60 lines, which would equate to 3.8 ms assuming a line length of about 64 µs. In practice it’s probably much lower.

[Zacabeb]

Sorry to derail the conversation for a bit, but which game is the Xbox screenshot from? It’s not a game I remember having played, yet the character looks familiar and it’s driving me crazy not figuring it out (I probably just recognize her from other screenshots of the same game.) 🤔

Edit: I found it is from the intro FMV to Dino Crisis 3.

[Author]

Posts