OSSC Pro

[windaddy01]

Hi I noticed on the junkerhq.net OSSC Pro wiki that Lowering scaler mode latency is a Scheduled improvement and am wondering how much is it even theoretically possible to lower latency in framelock and non framelock modes?

[Zacabeb]

Hi I noticed on the junkerhq.net OSSC Pro wiki that Lowering scaler mode latency is a Scheduled improvement and am wondering how much is it even theoretically possible to lower latency in framelock and non framelock modes?

Marqs gave a response earlier in the thread, saying it might take some time for the improvement to be implemented.

In theory, if the signal is framelocked onto the input in Scaler Mode there shouldn't need to be more delay than a few input lines, enough to supply the taps used by the upscaling algorithm, plus any delay necessary to account for differences in length of the vertical blanking interval between input and output signals. The de-interlacing IP core used (Intel's Deinterlacer II) also only relies on past fields and a few lines of the current field, so that doesn't require much of a delay either. So I imagine the total delay could be reduced to only a relatively small number of lines; a few hundred microseconds to a few milliseconds.

The output from the Deinterlacer II IP core is however written out to a full frame buffer before it is handed over the scaler. This currently uses Intel's Frame Buffer II IP core which doesn't allow for new data to be written while existing data is still being read, so two or more buffers are alternated between with one being read while new input data is being written to the other(s). This prevents the output from reading garbage from memory as well as preventing read and write operations colliding, but also as a result enforces at least a one field delay.

The solution is that if a custom frame buffer IP core is made, this limitation can be removed since the way the OSSC Pro works with framelock on can ensure that reading from and writing to the buffer don't collide. But designing a custom IP core requires a lot of time and testing, so it's a long term goal from what I understand.

When framelock is off, the delay probably cannot be worked around since the set output refresh rate may be both faster and slower than the input refresh rate, necessitating decoupling input and output through buffers. The exception might be when the output is set to match the input rate, but even a small mismatch there might require a buffer.

Edit: Corrected an error (rereading Intel's documentation it seems it's writing to the frame buffer that can't be done while it's being read, not the other way around.)

[marqs]

Is the 8 standard + 2 custom shado mask options a hard limit or is it possible that more can be added in firmware? I would love to have more than 2 custom options at least.
And would anyone know if someone is working on shadow masks that resemble the handheld screens of the GB/GBC/GG/GBA That is compatible with the OSSC Pro?

I think there are just the two custom slots for now. Maybe Marqs can add more.

I haven’t found anyone who is producing custom masks for it though.

I did experiment with importing some MisterFPGA masks which it is compatible with. The problem I found was there is no gamma compensation setting so the screen ends up way to dark, even with hdr and everything dialled to max.

The upcoming firmware has UI/customization improvements on shadow masks and scaling algorithms. Both have now a single custom slot accompanied by a popup menu where a custom configuration can be loaded from any shmask/*.txt or scl_alg/*.cfg files present on SD card. The custom mask/algo is also saved into the profile so SD card does no more need to be present after importing. On the masks, intensity can be adjusted to allow finding best balance. A .cfg file defines horizontal and vertical scaling algorithms with optionally an additional pair for edge-adaptive mode. The algorithm can be an existing one (e.g. "nearest") or a file name for custom polyphase coefficients.

Currently the highest scaler resolution available that's interlaced is 1920x1080i, but maybe Marqs can add two Line3x modes to scaler to suit your needs (for 1440i, and 1728i). I don't think it would be much harder than adding modelines for them, but I wouldn't want to compile the source code myself because toolchains for projects like this aren't always GNU/Linux friendly. and more importantly. I have been running out of storage for a while. Besides that, I don't even have a display that goes to resolutions that high.

There was some discussion about adding 1440i A-LM/SCL mode (especially 120Hz for CRTs) here, but ultimately that was dropped. FPGA bitstream & SW image btw. are built on GNU/Linux.

Anyway, it would be nice if the OSSC project could implement some sort of bounty system for feature requests. I certainly couldn't do it on my own either. And I understand that such a niche use case is unlikely to garner much developer interest, but with a bit of financial compensation there might be more incentive to cater to even the arcane ones.

A bounty system was actually planned very early in the project but unfortunately never materialized as all efforts went into getting the device out in the first place during component shortage at a reasonable price (which I consider a small miracle as we're still struggling with some parts). Maybe that's something we should reconsider.

Consider how long it takes for all the information in a single 60Hz frame to reach the display when directly connected to the display. That's straightforward. It's 16 and 2/3 milliseconds. Let's round it off. It's about seventeen milliseconds (~17ms). A CRT scans the frame as it arrives, but the entire frame isn't displayed until ~17ms have passed. Obviously, we can't display a frame without all the information.

It's arguable whether the scanout time should be included in overall latency numbers for a couple reasons. Personally I prefer to consider just the latency coming from the display and/or scaler to keep things unambiguous. A CRT (or modern displays using rolling scan/bar) never has full frame visible at a given time anyway, and the visible part can be theoretically generated just in time (no v-sync), thus causing no additional latency regardless of the position. Scanning out vsynced or frame-buffered content at higher rate obviously reduces overall latency so in practice there is indeed benefit at outputting such content at 120Hz vs 60Hz (average scanout delay of a pixel goes from ~8.3ms to ~4.2ms).

[jaffa225man]

There was some discussion about adding 1440i A-LM/SCL mode (especially 120Hz for CRTs) here, but ultimately that was dropped. FPGA bitstream & SW image btw. are built on GNU/Linux.

Thanks very much for providing GNU/Linux users a path to patching, I'll have to look into using it!

1080i range has been extended to 120Hz in ad9fbe3. I did some testing with 1440i but decided not to include it in the end due to it hitting several limitations of the HW:

1. Scaling to 2560x1440 at 100+Hz exceeds bandwidth of the scaler processing pipeline (that operates on progressive content) in many cases.
2. Outputting 2560x1440i 120Hz without reduced blanking requires higher pixel clock than what the FPGA can run stable with
3. HDMI input does not support 2560x1440

By reducing refresh rate and/or horizontal resolution 1 and 2 could be resolved, but no. 3 remaining means 2560x1440 sources are not supported anyway, thus blocking related use-cases.

In that discussion you state that 2560x1440 sources aren't supported on the HDMI input, but since no HDMI input exists on the original OSSC, that shouldn't effect this use case. They're already using 480i as the source to output 1440i from Line3x, likely at 60 Hz, which is working for them, so this looks very attainable.

Thanks!

[jaffa225man]

Currently the highest scaler resolution available that's interlaced is 1920x1080i, but maybe Marqs can add two Line3x modes to scaler to suit your needs (for 1440i, and 1728i). I don't think it would be much harder than adding modelines for them, but I wouldn't want to compile the source code myself because toolchains for projects like this aren't always GNU/Linux friendly. and more importantly. I have been running out of storage for a while. Besides that, I don't even have a display that goes to resolutions that high.

There was some discussion about adding 1440i A-LM/SCL mode (especially 120Hz for CRTs) here, but ultimately that was dropped. FPGA bitstream & SW image btw. are built on GNU/Linux.

Okay, I've installed the RISC-V GNU Compiler Toolchain, but am daunted by the massive size of even the Lite edition of Quartus Prime 21.1 (14GB required, 6.8GB just for the download). I am also a Free (As-In-Freedom) proponent and it appears that Quartus Prime doesn't adhere to respecting software freedom. Is there a method to compile the software without using it, or perhaps without using the RTL bitstream in general, however doubtful that seems?

I love the OSSC Pro and am not trying to cause you more work to support my strict morals. I've likely struck my impasse, and realize it probably just isn't possible.

Thanks!

[marqs]

Okay, I've installed the RISC-V GNU Compiler Toolchain, but am daunted by the massive size of even the Lite edition of Quartus Prime 21.1 (14GB required, 6.8GB just for the download). I am also a Free (As-In-Freedom) proponent and it appears that Quartus Prime doesn't adhere to respecting software freedom. Is there a method to compile the software without using it, or perhaps without using the RTL bitstream in general, however doubtful that seems?

I love the OSSC Pro and am not trying to cause you more work to support my strict morals. I've likely struck my impasse, and realize it probably just isn't possible.

Thanks!

If you are planning to only work with the software (i.e. not RTL), you can download just the Quartus programming utilities. It's found under "additional software" here and is around ~1GB unpacked (still ridiculous size as it comes with its own C, python etc. libraries).

[marqs]

Firmware version 0.76 has been released:

* Lumacode support added
* New line drop modes added
* Custom scl_alg/shmask loading improved
* Shadow mask strength adjustment option added
* 10bit coefficient support added for scaling algorithms
* Power-up state option added
* Added support for exFAT
* Fixed number of minor bugs
** SPDIF output active when power off
** random bobbing with analog HV sync sources when sync edges are closely aligned
** Garbage on topmost line with LM Bob deinterlace
** 0x00/0xff extreme RGB values clamped with HDMI input
** scanline issues on 2160p mode

[Zacabeb]

This is a very nice update. Now it's possible to create more realistic CRT simulation by combining different horizontal and vertical scaling filters, including ones with integrated scanlines for non-integer scaling factors in Scaler Mode.

There is still need for an adjustable gamma LUT to compensate for the darker output with scanlines and shadow mask, especially for SDR display, but if choosing faint scanlines and a reduced shadow mask intensity it already works very nicely.

[TechnoST]

Awesome update, by the way is there any chance that the OSSC Pro will get HDR10 or a way to calibrate the HLG colors that are a bit off? My LG C3 is a bit dim in SDR with game optimizer turned on.

[LDigital]

This is a very nice update. Now it's possible to create more realistic CRT simulation by combining different horizontal and vertical scaling filters, including ones with integrated scanlines for non-integer scaling factors in Scaler Mode.

There is still need for an adjustable gamma LUT to compensate for the darker output with scanlines and shadow mask, especially for SDR display, but if choosing faint scanlines and a reduced shadow mask intensity it already works very nicely.

Sounds good. Can you give some examples of this? I had previously being creating my own effect using both horizontal and vertical scanlines but I’m not sure what you mean on this due to the new update.

[Zacabeb]

This is a very nice update. Now it's possible to create more realistic CRT simulation by combining different horizontal and vertical scaling filters, including ones with integrated scanlines for non-integer scaling factors in Scaler Mode.

There is still need for an adjustable gamma LUT to compensate for the darker output with scanlines and shadow mask, especially for SDR display, but if choosing faint scanlines and a reduced shadow mask intensity it already works very nicely.

Sounds good. Can you give some examples of this? I had previously being creating my own effect using both horizontal and vertical scanlines but I’m not sure what you mean on this due to the new update.

Custom scaling algorithms are now defined with a [name].cfg file which specifies the scaling algorithms to use for horizontal and vertical scaling and optionally which ones to use for edge-adaptive scaling. They are stored in a separate folder named "scl_alg" in the root of a microSD card inserted into the OSSC Pro.

The .cfg files contain the following lines:
[name of horizontal algorithm]
[name of vertical algorithm]
(optional, for edge-adaptive scaling) [name of horizontal algorithm]
(optional, for edge-adaptive scaling) [name of vertical algorithm]

If you want to use one of the built-in scaling algorithms, you select one of the following names:
nearest, lanczos3, lanczos3_13, lanczos4, gs_sharp, gs_medium, gs_soft

If you want to use a file with a custom scaling algorithm (MISTer format, 4 taps, 64 phases, 9 or 10 bit coefficients) you put that in the same folder and simply list the name of it including the .txt extension. The .txt extension lets the OSSC Pro know that it's in a separate file.

For instance, if you want to create a scaling algorithm that uses Lanczos 3 for horizontal scaling and GS medium for vertical scaling, you simply put the following in your [name].cfg file (named anything you wish so long as it ends with a .cfg extension):

Code: Select all

lanczos3
gs_medium

If you want a filter that uses Lanczos 3 on both axes and Lanczos4 along edges, you put in:

Code: Select all

lanczos3
lanczos3
lanczos4
lanczos4

If you want a filter that uses a combination of built-in algorithms and custom ones, it looks like this:

Code: Select all

gs_medium
name.txt

Again, [name].txt (named anything you wish, so long as it has a .txt extension) is stored in the same folder and contains a scaling LUT in MISTer format.

When you save a profile with a custom scaling algorithm loaded, it's embedded directly into the profile, letting it be loaded along with the profile later without the original .cfg and .txt files needing to be present.

So far I've only done some basic testing, but here's a step-by-step example that combines the built-in GS Soft filter for horizontal scaling with one of the MISTer scanline filters for vertical scaling.

1. Create a folder on the root of the microSD card called "scl_alg". This is the folder into which custom scaling algorithms go.
2. Download Scanlines_75.txt file from the MISTer filter repository at https://github.com/MiSTer-devel/Filters ... 20Standard and put it into the scl_alg folder.
3. Create a text file named "Soft Scanlines 75.txt" in the scl_cfg folder and open it in a text editor. Enter the following text, including the line breaks:
   gs_soft
   Scanlines_75.txt
4. Change the file extension of the "Soft Scanlines 75" file from txt to cfg.
5. Insert the microSD card into the OSSC Pro.
6. Load any profile you wish and make sure the OSSC Pro is in Scaler Mode.
7. In the OSSC Pro menu, select "Scaler opt/Custom SCL alg". You should now see "Soft Scanlines 75.cfg" as an option. If everything has worked out, selecting this will display "OK" next to the option.
8. Now go into the "Scaler opt/Scaling algorithm" menu. You should now see "Soft Scanlinese 75.cfg" available as the last option for you to select.
9. You should now get an image that has some softness horizontally (how much depends on whether you're in generic or an optimized sampling mode) and scanlines. It will look best with 240p content.

Because the scanlines are embedded in the vertical scaling LUT, you are now free to adjust the vertical scaling without the scanlines misaligning with the pixel grid, letting you trim away underscan.

[LDigital]

That is a very detailed response. I think I will need to experiment to see how it looks in person. Thanks

[GK6475]

Could this feature be used or updated to do integer scaling by 2x or 4x, and then scale that to a 1080p window (also considering the user-set aspect ratio) using any other scaling method? And, for anamorphic widescreen games, could it be possible to use different integer multipliers for horizontal and vertical pre-scaling? It would result in the sharpest image that both fills the screen and does not distort pixel shape for 1080p. This is the main thing that I want from the OSSC Pro on my 1080p plasma. This would also be great for 768p "720p" flatscreens.

[spmbx]

I gave up monitoring for a while but now i see it's back in stock.

[marqs]

Awesome update, by the way is there any chance that the OSSC Pro will get HDR10 or a way to calibrate the HLG colors that are a bit off? My LG C3 is a bit dim in SDR with game optimizer turned on.

Try setting HDR color space to Auto instead of Native on the LG - on some models that results to proper handling of the source.

Could this feature be used or updated to do integer scaling by 2x or 4x, and then scale that to a 1080p window (also considering the user-set aspect ratio) using any other scaling method? And, for anamorphic widescreen games, could it be possible to use different integer multipliers for horizontal and vertical pre-scaling? It would result in the sharpest image that both fills the screen and does not distort pixel shape for 1080p. This is the main thing that I want from the OSSC Pro on my 1080p plasma. This would also be great for 768p "720p" flatscreens.

A separate (integer) pre-scaling option has been under consideration. How to integrate on the UI & modes without increasing complexity too much is still to be resolved.

[ryu]

Has anyone ever compared the OSSC's 480i handling to that of the iScan VP30 with upgrade card? Is the difference in detail very noticeable (like switching deinterlacing modes on the iScan)? Did the OSSC Pro maybe even improve on this?

Edit: Spent all day fumbling around with my equipment. There's nothing like the VP30's "Game Mode 2" on the OSSC. Is the Pro equipped with a similar feature however?
Edit2: Never mind, I think I figured it out

[GK6475]

Could this feature be used or updated to do integer scaling by 2x or 4x, and then scale that to a 1080p window (also considering the user-set aspect ratio) using any other scaling method? And, for anamorphic widescreen games, could it be possible to use different integer multipliers for horizontal and vertical pre-scaling? It would result in the sharpest image that both fills the screen and does not distort pixel shape for 1080p. This is the main thing that I want from the OSSC Pro on my 1080p plasma. This would also be great for 768p "720p" flatscreens.

A separate (integer) pre-scaling option has been under consideration. How to integrate on the UI & modes without increasing complexity too much is still to be resolved.
[/quote]

Great to hear, I'd love to see this feature implemented. It would be really beneficial on 768p and 1080p displays!

[AaronSR]

I'm probably going to get one of these within the next couple of months if they're still in stock. Currently using a GBS but want something more advanced with more inputs (especially VGA + S/PDIF is really good to have). I have a wide variety of devices but the main thing that I have issues with on the GBS is my retro PC, it works most of the time but often the sync is lost when resolution switching and I even need to power cycle it sometimes. How does the OSSC Pro deal with "extreme" resolution switching for example running a game at 1600x1200 and then a FMV cutscene switches to 640x480 and then back to 1600x1200, is it as seamless as any other resolution switching like for 240p/480i on PS1 and Saturn? And how does outputting 70Hz DOS work?

I know this can do 4K 4:3 but I'll only be using it for scaling to 1920x1440 and 2560x1440. Thanks.

[SGGG2]

Here's a video detailing the OSSC Pro with old PC's

https://www.youtube.com/watch?v=qK36-CdItaQ

[SGGG2]

Double post

[AaronSR]

Ah nice, that looks great. Can the OSD be turned off when the resolution switches in the top left?

Also another big thing is PSP being full screen which isn't quite possible on the GBS, that will be great to have since I know the original OSSC could do that too.

[jaffa225man]

Ah nice, that looks great. Can the OSD be turned off when the resolution switches in the top left?

Yes, by just changing the value of "Settings"->"OSD status disp." to "Off", or "Settings"->"OSD" to "Off"

Also another big thing is PSP being full screen which isn't quite possible on the GBS, that will be great to have since I know the original OSSC could do that too.

I don't have a PSP to check that, but am fairly certain if you are willing to use the Pure Line Multiplier mode, it's fully backwards compatible with the original OSSC. I wouldn't be surprised if both Adaptive Line Multiplier and Scaler modes work too, though. In case it matters, which is doubtful since you've said the original OSSC worked full screen with the PSP, both of the new modes have size/crop settings available. Scaler mode's size/crop lets you zoom indiscriminately, however, I seem to remember Adaptive Line Multiplier mode having practical upper and lower boundaries in those settings.

[AaronSR]

Yeah it basically outputs a 480x272 image inside a 720x480 resolution, so its just a case of cropping.

[Triple Lei]

Related... I've been making OSSC Pro profiles for PSP games (usually compilations) that have pixel-perfect modes, but zoomed in just enough so they match original hardware in Line5x. Observe!

CPS1 PCB vs PSP Capcom Classics Collection Reloaded


Final Fantasy Tactics (PS1) vs Final Fantasy Tactics: War of the Lions (PSP) with unstretch patch


Will probably share the rest soon, although phase adjustments are still by eyeball.

[b7se4RTD]

Would it be possible to use expansion port to monitor / send command to the OSSC Pro from an ESP32 ?
It would be to remote control OSSC Pro using Home Assistant.

IR Receiver could be a solution but I wouldn't get the information from the OSSC.

[Das Muel]

Do we know when more AV output expansions will be available?

[marqs]

Would it be possible to use expansion port to monitor / send command to the OSSC Pro from an ESP32 ?
It would be to remote control OSSC Pro using Home Assistant.

There has been some thoughts about enabling functional-mode UART on JTAG port (usable with USB-Blaster) to leave expansion port for actual expansions, but that has not been implemented yet.

Do we know when more AV output expansions will be available?

StoneAgeGamer should already have some available. It will be also restocked at VGP once some components get delivered (maybe in 2-6 weeks).

[b7se4RTD]

Would it be possible to use expansion port to monitor / send command to the OSSC Pro from an ESP32 ?
It would be to remote control OSSC Pro using Home Assistant.

There has been some thoughts about enabling functional-mode UART on JTAG port (usable with USB-Blaster) to leave expansion port for actual expansions, but that has not been implemented yet.

Do we know when more AV output expansions will be available?

StoneAgeGamer should already have some available. It will be also restocked at VGP once some components get delivered (maybe in 2-6 weeks).

If I read correctly, UART is already enabled in the Verilog part, and there are already drivers present.
It just needs to be implemented in the RISC-V software part or did I miss something ?

[marqs]

If I read correctly, UART is already enabled in the Verilog part, and there are already drivers present.
It just needs to be implemented in the RISC-V software part or did I miss something ?

Yes, JTAG UART HW is in place, and TX side is already used in the debug build. In addition of enabling RX, command format/structure would need to be defined and a command interpreter designed.

[Licentious Howler]

I don't know if OSSC Pro creators and contributors hear this enough, but I recently picked this up, and I've been extremely impressed and happy with it! Your hard work and striving for perfectionism is plainly evident, and is making my life easier than ever before.

I wanted to ask, is it normal and expected for Master System cvbs to have quirky sync when using the Legacy AV In expansion (at least for now)?
More specifically I have a Genesis that I'm using in SMS mode.
Every now and then the OSSC Pro will randomly detect the incoming signal is 261 lines, and then quickly jump back up to 262.
Turning off frame lock keeps the games playable, but it makes the picture jitter up and down a bit when this happens.
So far I haven't observed this when running Gen/MD games, and I made sure to test ones that use the 256 wide mode too.
I also haven't been able to reproduce it when running SMS games in RGB so far.
Is it possible that my Genesis may not be producing stable NTSC?

This source seems extremely challenging because no other processor I own can deal with it correctly, and honestly even with this jittering quirk, it's still better than 99% of kit out there, so thank you lol