OSSC Pro

[6t8k]

i tested the de10-vd_isl on my original playtronic snes pal60 system. this was special for the brazilian market.

Ah, thanks for clarifying! Should've checked back with you, Occam's razor at work ^^;

That could be done with a headphone jack. There are phones jacks used on equipment that has internal speakers which are designed to switch an external transistor network when a plug is present. (essentially to route audio away from the speakers and turn them off) That kind of switch could be used to close a resistor when unplugged.

Good idea! That could make it a bit easier to use. May be easier to find well shielded coaxial cables with RCA plugs (you could of course always make your own), and the relatively complex shape of the contacts inside such a socket is not ideal, but it could work. I also realized that the circular cutout on the back of the console could be repurposed if the RF modulator is removed.

I guess the question is whether or not this is a bigger pain in the ass than just doing the de-jitter mod?

Looking at the installation instructions, the average de-jitter mod installation requires a bit more work and parts. The de-jitter mod also cannot dejitter the 50Hz 576i mode, and ever so slightly changes gameplay speed (not relevant during "normal" gameplay, but may be relevant for speedrunning). Still, I wouldn't recommend using the master clock for sampling in the scenario at hand if you can avoid it, but I think it could be an interesting experiment.

[vol.2]

...

did you just want to see if i would notice? lol

[6t8k]

Whoops, sorry :'D I rarely use the "quote" button, so that's probably how that freudian slip snuck in, heh.

I've by the way been meaning to mention this photo of an earlier prototype, which I've found to be an interesting comparison (click for a larger version):


(source)

[Unseen]

The de-jitter mod also cannot dejitter the 50Hz 576i mode, and ever so slightly changes gameplay speed (not relevant during "normal" gameplay, but may be relevant for speedrunning).

It's not relevant to speedrunning unless the speedrunners calibrate the crystal frequency in their console at least once every few years and ensure that the console is used in an environment that is within a few degrees celsius of the temperature at the time of calibration.

(dejitter causes 11.2 ppm difference)

[marqs]

I guess the question is whether or not this is a bigger pain in the ass than just doing the de-jitter mod?

Looking at the installation instructions, the average de-jitter mod installation requires a bit more work and parts. The de-jitter mod also cannot dejitter the 50Hz 576i mode, and ever so slightly changes gameplay speed (not relevant during "normal" gameplay, but may be relevant for speedrunning). Still, I wouldn't recommend using the master clock for sampling in the scenario at hand if you can avoid it, but I think it could be an interesting experiment.

Sampling using console master clock or externally generated (not hsync-based) clock is mainly useful if the sync signal is either so bad or aperiodic that H-PLL cannot lock into it. It is somewhat separate problem from generating a framelocked output clock that is stable. Obviously framelocked output clock cannot be easily generated if sampling is done using fully external clock, not even with Pro HW. If master clock is used for sampling, framelock can be safely maintained with Pro HW only if the number of clocks per frame is deterministic. At least on NES the short scanline doesn't necessarily occur every other frame, I'm not sure if it's consistent on SNES 240p.

[6t8k]

Thank you both for the valuable comments.

It's not relevant to speedrunning unless the speedrunners calibrate the crystal frequency in their console at least once every few years and ensure that the console is used in an environment that is within a few degrees celsius of the temperature at the time of calibration.

It looks like I had a lacking understanding of how verification of tool-assisted speedruns on genuine NES and SNES hardware is performed. I thought the controller (port) was driven with button inputs that were simply played back according to a separate, finely adjusted clock. You'd have to adjust the clock anyway of course - I thought the constant frame times due to the dejitter mod could introduce a factor for headache e.g. when switching from console to console, potentially making existing replays incompatible because the drift is then nonlinear. For example, when TASBot debuted on GDQ with Gradius, it desynced ~1m50s in, but as became apparent to me, there are other reasons for something like that. How it's (properly) done is that you wait for a pulse from the console which signals that the game wants to read in the current controller state, after which you have a specific timeframe to apply the next state to the PISO shift register that sits on the original or vicarious controller.

(dejitter causes 11.2 ppm difference)

Yes, at max. That's assuming that the short scanline occurs during every frame. If it occurs only during every other frame then it's consequently only half of that:

Spoiler

If master clock is used for sampling, framelock can be safely maintained with Pro HW only if the number of clocks per frame is deterministic. At least on NES the short scanline doesn't necessarily occur every other frame, I'm not sure if it's consistent on SNES 240p.

Ah right, I hadn't thought of that. It probably would get challenging to compensate for the variable frame time if it's nondeterministic, which, if it can't be done sufficiently, would probably give rise to compatibility issues on the sink side again.

[whatamansion]

One brand of tv that really needs to be put through the paces during testing of the OSSC Pro are Sony tv's. Sony tv's currently do not work with NTSC SNES/NES on the current OSSC. I can get picture to flicker in 5x modes, but that's it. Maybe adaptive line mode would work? Also, would tv's that have VRR be more likely to receive these consoles out of spec signals? Sony is bringing VRR to at least one of their sets soon (X900H) in a firmware update.

[kitty666cats]

One brand of tv that really needs to be put through the paces during testing of the OSSC Pro are Sony tv's. Sony tv's currently do not work with NTSC SNES/NES on the current OSSC. I can get picture to flicker in 5x modes, but that's it. Maybe adaptive line mode would work? Also, would tv's that have VRR be more likely to receive these consoles out of spec signals? Sony is bringing VRR to at least one of their sets soon (X900H) in a firmware update.

Are Samsungs still more-or-less the “go to” modern TVs for the original OSSC? Every Samsung I ever tried with an OSSC usually worked wonderfully, I even had one that synced back up faster than my CRT presentation monitor whilst testing 240p<->480i switching in Silent Hill 1 (via a PSIO, not a disc)! I believe this was just via a generic line 2x mode, may have been a FBX profile but I forget.

[nmalinoski]

Are Samsungs still more-or-less the “go to” modern TVs for the original OSSC? Every Samsung I ever tried with an OSSC usually worked wonderfully, I even had one that synced back up faster than my CRT presentation monitor whilst testing 240p<->480i switching in Silent Hill 1 (via a PSIO, not a disc)! I believe this was just via a generic line 2x mode, may have been a FBX profile but I forget.

I think TCL's 6-series is still on the acceptable list, as well as LG's OLEDs.

[orange808]

The Samsung I tried was managing compatibility by applying frame rate conversion. Not suitable for a game of Contra or Gunbird--where you're working in tight spaces. YMMV

[whatamansion]

One brand of tv that really needs to be put through the paces during testing of the OSSC Pro are Sony tv's. Sony tv's currently do not work with NTSC SNES/NES on the current OSSC. I can get picture to flicker in 5x modes, but that's it. Maybe adaptive line mode would work? Also, would tv's that have VRR be more likely to receive these consoles out of spec signals? Sony is bringing VRR to at least one of their sets soon (X900H) in a firmware update.

Are Samsungs still more-or-less the “go to” modern TVs for the original OSSC? Every Samsung I ever tried with an OSSC usually worked wonderfully, I even had one that synced back up faster than my CRT presentation monitor whilst testing 240p<->480i switching in Silent Hill 1 (via a PSIO, not a disc)! I believe this was just via a generic line 2x mode, may have been a FBX profile but I forget.

I've seen Samsung listed as one of the brands that does work with OG OSSC (4k tv's). I've not personally tried Samsung, but I remember seeing a video on youtube of a Samsung tv working with the SNES in 5x mode.

Like nmali said, TCL and LG seems to be the best. I've tried both of them. One was a TCL 4 series and the other a LG NanoCell. SNES and NES worked great on both.

Sony seems to be the biggest pain in the arse from the bigger brands though. It just doesn't work with NTSC SNES/NES. I've tried on two different Sony tv's and get the same result. One was the X900E and the other X800D. I want to get another Sony next year when they release more sets with HDMI 2.1. I like processing on their tv's. If the new Pro can somehow make that wonky signal compatible with Sony tv's, I will be super happy

[Ms. Tea]

Sony seems to be the biggest pain in the arse from the bigger brands though. It just doesn't work with NTSC SNES/NES. I've tried on two different Sony tv's and get the same result. One was the X900E and the other X800D. I want to get another Sony next year when they release more sets with HDMI 2.1. I like processing on their tv's. If the new Pro can somehow make that wonky signal compatible with Sony tv's, I will be super happy

I have an X800D and my SFC works perfectly through a Framemeister with the resync mode enabled. Should work just as well with the OSSC Pro!

[jmsbosss]

When can we buy this product

[vol.2]

The developers have said that they hope sometime in the first half of next year, but there is no release date yet.

[jmsbosss]

The Samsung I tried was managing compatibility by applying frame rate conversion. Not suitable for a game of Contra or Gunbird--where you're working in tight spaces. YMMV

I want it to be released after March 2021 and there are a lot of people out there right now who don't have a job and they can't make money and they don't buy anything.
It's better to release the product when everyone has a job

[ldeveraux]

The Samsung I tried was managing compatibility by applying frame rate conversion. Not suitable for a game of Contra or Gunbird--where you're working in tight spaces. YMMV

I want it to be released after March 2021 and there are a lot of people out there right now who don't have a job and they can't make money and they don't buy anything.
It's better to release the product when everyone has a job

It's better to buy this product when it's ready to use, and not a minute earlier.

[vardoger]

It's better to release the product when everyone has a job

You’re joking, right? These are not limited food rations being released. This is a luxury item, and one that will in all probability still be available for purchase once poor old Billy Joe regains the ability to purchase this vital, life saving, product.

It's better to buy this product when it's ready to use, and not a minute earlier.

or later.


BTW, I tested out the mClassic today. I had major screen tearing’ish behavior in Xenoblade on my Wii U. My TV, although not zero lag, produced very little ringing by comparison and did a better job preserving details, color, and contrast. Additionally, I noticed 720p on the Wii U is noticeably degraded compared to the 1080p output regardless of internal rendering; so it would be a bit foolish to disable the Wii U’s upscaling and rely solely on the mClassic. Anyway, I think it’s hot garbage, and I can’t wait for this device to come out.

[vardoger]

The upcoming prototype can output up to 1920x1440@60Hz, but there are plans to evaluate Sil1136 TX chip before release. Its 300MHz pclk support enabling modes such as 1920x1080@120Hz and 2560x1440@60Hz is tempting, but at the same time it's a major risk due to practically non-existent documentation and support. So even if it appears to work fine on an evaluation board, a lot of verification needs to be done to ensure coverage of all current and potential future requirements before it could be considered as a replacement for the current TX chip. That would mean yet another delay. Another challenge is the +50% performance requirement of such modes, meaning the FPGA model would possibly need to be higher speed grade which equals higher price. In short, 2560x1440@60Hz output might be possible but not without added delay and cost.

It seems like this would be perfect for borderless, non-blurry, scaling to 1080 (integer scale up a bit past 1080, and then scale down to 1080) It also seems like it would be excellent for 4K TVs that support 2560x1440 input, for 720x2 content.

I assume it is too late for this to happen, but do you foresee support for higher resolutions (sub 4k) coming in a later revision? My TV does an excellent job upscaling both 1080p and 1440p with low lag, but 720p...not so much. I also would love to see the horizontal borders go without adding typical bilinear blurriness.

BTW, I know jack about analog signals, but maybe this could be a solution for input detection:

Create a passthrough connector for rgb or audio inputs that slightly modifies the signal so it can be uniquely identified (The ossc could compensate for this known signal modification if it would affect picture/sound quality).

So, for the gcompsw, 8 passthrough connectors would be needed for 8 inputs. Either with a switch to enable a particular identifiable signal (like a Wavebird dongle), or 8 unique connectors with the signal modification hardcoded.

[orange808]

@marqs
I'm not familiar with the hardware, but there are lots of inexpensive Chinese boxes that upscale 1080p to 4k and downscale 4k to 1080p. That's all they do.

HDFury was the first big name to have it, but I see it in a lot of products, now. I think new 1080p beamers (no pixel shifting) that "support 4k" are using the same chipset to downscale 4k to 1080p.

I strongly suspect everyone is using the same hardware. That might be an inexpensive way to add 4k output. If the results look like the HDFury Linker, it would be pretty good.

[Unseen]

That might be an inexpensive way to add 4k output.

Would that result in an improvement compared to the display's own 1080p->4K scaling or would it just be a checklist feature?

[orange808]

That might be an inexpensive way to add 4k output.

Would that result in an improvement compared to the display's own 1080p->4K scaling or would it just be a checklist feature?

Given the results I observed with the HDFury Linker, it would be pretty good.
Also, I suspect the chipset is programmable, so the idea has potential. The downside is the FPGA is outputting 1080p, so you won't have absolute "pixel by pixel" granular control over the porches at 4k.

Of course, it would add complexity. I also never tried it with odd refresh rates from the Neo Geo or arcade PCB's. Although, all of that could probably be sorted out.

I think it could work very well, but it would add cost and complexity. Still much more affordable than trying to scale to 4k using the FPGA. It's almost "cheating", but it's the only inexpensive option I can imagine.

[6t8k]

BTW, I know jack about analog signals, but maybe this could be a solution for input detection:

Create a passthrough connector for rgb or audio inputs that slightly modifies the signal so it can be uniquely identified (The ossc could compensate for this known signal modification if it would affect picture/sound quality).

So, for the gcompsw, 8 passthrough connectors would be needed for 8 inputs. Either with a switch to enable a particular identifiable signal (like a Wavebird dongle), or 8 unique connectors with the signal modification hardcoded.

If you have something like the gcompsw or gscartsw - you can query/override the active input on those using their EXT header - you could simply connect that to the OSSC Pro's expansion port and execute commands based on that.

[bobrocks95]

BTW, I know jack about analog signals, but maybe this could be a solution for input detection:

Create a passthrough connector for rgb or audio inputs that slightly modifies the signal so it can be uniquely identified (The ossc could compensate for this known signal modification if it would affect picture/sound quality).

So, for the gcompsw, 8 passthrough connectors would be needed for 8 inputs. Either with a switch to enable a particular identifiable signal (like a Wavebird dongle), or 8 unique connectors with the signal modification hardcoded.

If you have something like the gcompsw or gscartsw - you can query/override the active input on those using their EXT header - you could simply connect that to the OSSC Pro's expansion port and execute commands based on that.

Extron switchers often have a 9-pin D-sub that I think could be used for the same purpose? You can query which inputs are active at the very least.

[marqs]

That might be an inexpensive way to add 4k output.

Would that result in an improvement compared to the display's own 1080p->4K scaling or would it just be a checklist feature?

Given the results I observed with the HDFury Linker, it would be pretty good.
Also, I suspect the chipset is programmable, so the idea has potential. The downside is the FPGA is outputting 1080p, so you won't have absolute "pixel by pixel" granular control over the porches at 4k.

Of course, it would add complexity. I also never tried it with odd refresh rates from the Neo Geo or arcade PCB's. Although, all of that could probably be sorted out.

I think it could work very well, but it would add cost and complexity. Still much more affordable than trying to scale to 4k using the FPGA. It's almost "cheating", but it's the only inexpensive option I can imagine.

Adding a generic scaler ASIC on output path is at odds with what the project aims for and could limit overall flexibility. The plan (still) is to evaluate SiI1136 on upcoming week since 2540x1440@60Hz & 1920x1080@120Hz capabilities would be nice to have.

On the automatic source identification, expansion port is indeed the way to handle this kind of case.

[Lawfer]

The plan (still) is to evaluate SiI1136 on upcoming week since 2540x1440@60Hz & 1920x1080@120Hz capabilities would be nice to have.

2540x1440? Shouldn't it be 2560x1440?

[kardus]

In its completed form (with whatever appropriate addon modules), would there be any concessions/disadvantages to using this as a console compared to a MiSTer? I am definitely getting an OSSC Pro but I've also been wanting a MiSTer for quite some time, would be great to only have or need one device.

[6t8k]

If you have something like the gcompsw or gscartsw - you can query/override the active input on those using their EXT header - you could simply connect that to the OSSC Pro's expansion port and execute commands based on that.

Extron switchers often have a 9-pin D-sub that I think could be used for the same purpose? You can query which inputs are active at the very least.

It looks like it's possible with these units using ASCII commands via RS-232, yes.

To add clarity, for gcompsw/gscartsw I meant querying which input is selected (which one is output), which by default is chosen automatically, and is also what you'd want to query on the Extrons for this use case. In distinction from that, there are Extrons that allow you to query active inputs (which inputs a signal is detected on), which so far is not possible with gscartsw/gcompsw.

[freyesm]

OLED display isn't a good idea.

It burn in and loses bright kinda fast, unless you are planning to show the information for just 5~10 seconds, then turn it off.

[strayan]

OLED display isn't a good idea.

It burn in and loses bright kinda fast, unless you are planning to show the information for just 5~10 seconds, then turn it off.

Explain how burn in would be visible with white text on a black background. Burn in is a non issue.

[Fudoh]

the pixels will age differently. But I also don't see the issue. Offer an auto-display off function after xx seconds or make the static info rolling/scrolling instead. Issue solved.