April 11, 2018 at 5:35 PM #20722
The 1Chip SNES outputs slightly hotter signal of 0.8V instead 0.7V and as a result the brighter shades are clipped in the digitization stage of the OSSC (and Framemeister), NOT in the 1Chip SNES itself.
Currently the solution is to modify the console, but there is a better (and much simpler) solution for OSSC owners which is not implemented yet (hopefully).
Will it be possible to add a Coarse Gain/Offset (page 12, 38 of datasheet) which scales 0.5Vpp-2.0Vpp before ADC to 10bit of the OSSC?
Currently the OSSC has the Fine Gain/Offset controls which are Post ADC, while all Coarse parameters are Pre ADC and missing from the OSSC menu, and probably set to default of 700mV so anything above that is clipped.
I think the Pre (coarse) ADC controls are much more important, than the Post (fine) controls that can be done on the LCD anyway.
It will be really nice not having to mod a stock vintage 1Chip snes or any other slightly hotter console like the PSOne once the Pre ADC Gain/Offset controls are implemented in the OSSC.
You can see the clipping in this ‘My Life in Gaming’ video at 8:21 and 8:38:
I believe it was captured with the Framemeister because the OSSC clips only last 2 stripes in the grey ramp test pattern on my hotter 1Chip, but in MLiG video almost 8 stripes are clipped.
I assume the XRGB-Mini has lower digitization voltage as peak white than the OSSC.
Unlike the Framemeister, this can be fixed to be easily adjustable in the OSSC menu with a few more code lines.
Still waiting for a reply from marqs… or anyone willing to implement this.
Just to make the programming (which I cannot do myself) easier:
Blue and Green Coarse Gain: Subaddress: 1Bh, Default: 77h (MSB Green, LSB Blue). Red Coarse Gain: Subaddress: 1Ch, Default: 07h (LSB Red).
A single control in the menu that controls all RGB channel together from 0-FFh/0Fh (0-16) will cover the 0.5v-2.0v input range.
Just lowering the default from 77/07 to 66/06 or 55/05 will prevent all input clipping of hotter consoles on the OSSC.
Fine Gain controls (currently default to 26) should be re-adjusted accordingly to bring back up the lowered PRE Gain of spec 714mV back to step 255 digital output.
Hopefully OSSC developers will see the importance of this addition.April 12, 2018 at 3:49 PM #20741paulb_nlParticipant
Here is a firmware with a setting for the coarse gain. https://drive.google.com/file/d/1cUGuJSTHoOrThnycG4vg197bmirrQZIi/view?usp=sharing
The setting is called Analog gain for now and range is 0.5-2.0 like in the datasheet. It defaults to 1.3 like it was. A setting like this is called ADC Level on the Framemeister and maybe that is a better name?April 12, 2018 at 5:47 PM #20743
I am truly grateful for this paulb_nl, thank you very much.
As I thought, no clipping from a stock 1Chip with one click lower from 1.3 to 1.2, and the whites are slightly below 255 now but that can be fixed with the Fine Gain controls.
I would suggest naming it “Pre ADC Gain” which explains it better and combines ‘Analog gain’ and ‘ADC Level’.
If you will, please make it a ‘pull request’ on OSSC GitHub as I feel it is a VERY important feature, and I don’t understand how marqs overlooked it for such long time.
Small rant ahead;
I don’t understand why MLiG pushing hardware modification if the Framemeister and now the OSSC can do that without modification.
Maybe they are not aware that the Framemeister could do that, or maybe they just use FBX presets without digging deeper into it?
If the knew about it, why didn’t they at least mentioned the possibility of lowering gain before ADC in the Framemeister?
Personally I do not suggest modding a vintage console, and definitely use Pre ADC Gain.
I want to add and say;
On a digital display it is important that the whole analog signal of 714mV is correctly mapped to 0-255 digital, not less or more.
The reason is the 2.2/2.4 Gamma curve on digital displays is fixed and the image looks correct only when peak white is at 255 or very close to it.
If the peak white is lower than 255 the effective gamma of the image lowers and the image looses depth and perceivable contrast.
If the high shades are clipped, the middle shades are pushed and colors begin to look washed out (less saturated), and obviously the higher shades are one solid color.April 12, 2018 at 11:15 PM #20744
Thanks paulb_nl for implementing the feature. Pre-ADC gain/offset controls were not originally included in the firmware as I assumed most console outputs to be close enough to 0.7Vpp to avoid clipping. With current settings there’s even some headroom (up to 0.77Vpp should still map correctly if you decrease fine gain correspondingly), but apparently more is needed for certain sources.
As for modifying consoles itself, you could think that as fixing the root cause, and personally I still see that as the best solution since it doesn’t then matter whether you use it with OSSC, FM etc. It’s certainly good to have ADC adjustment as well, especially when it’s as easy to implement as here :).April 13, 2018 at 5:58 AM #20747
Actually, these consoles were designed to work on a CRT which has quite large input voltage tolerance before clipping on all inputs, so the effect of higher input levels is exactly like raising the Contrast control on the CRT, definitely not clipping.
There is no “root cause for clipping” when playing on a CRT which the consoles were originally designed for, that’s is why I’m against modifying the original hardware.
Thank you again for considering including this in the next firmware.
Will it be merged with the main ossc code on github?
Input (analog) to output (digital) mapping equation for the OSSC:
0.714 peak input voltage.
1.3 (default in OSSC) coarse gain (0.5-2.0).
26 (default in OSSC) fine gain (0-255).
Pre ADC input level (0.714*1.3) should be less than 1.0 to prevent clipping in the digitization stage.
Total result should be exactly 1.0 for proper mapping to 0-255 digital.
1Chip SNES consoles output 0.8V stock.
Video Level Specification is 0.714V.
Thought I should include that here for people to understand what’s going on.April 14, 2018 at 1:23 PM #20789
It will be merged once we get more memory resources in use (e.g. by replacing current soft-CPU with a more optimal one) – currently the situation on audio firmware is so tight that even adding a single menu option can lead to crashes/corruption unless stack usage is carefully monitored.April 14, 2018 at 4:14 PM #20793
Can you please share what are your plans to optimize the current FPGA resources?April 15, 2018 at 10:08 PM #20809
The planned short-term solution is to integrate zero-riscy core from Pulpino project, which should help further reduce CPU code size with its compressed ISA.April 16, 2018 at 5:32 AM #20819StarmanParticipant
I would just like to say that I am very interested in this feature.April 22, 2018 at 9:35 PM #21042yoshiyukibladeParticipant
This is definitely a nice option to include in the firmware. I don’t have a 1CHIP SNES to test it on, but I did mess around with it a bit on my older model SNES. My unit seems to output a weak signal. Working backwards from the equation in James-F’s post, it would have to be under 0.65 V for the peak input. Pushing the coarse gain to 1.4 appeared to be fine, but 1.5 showed signs of clipping, even if it should theoretically be OK (less than 1.0 after multiplication). A pure white screen isn’t at 255 at the output either. I’m not sure why that is, but I’ve been basing the output values off of lossless RGB recordings made in OBS, so anything along that video chain may affect the final output.
Interestingly, I found no immediately-visible differences between high coarse/low fine gain vs low coarse/high fine gain. I tested coarse gains at 0.8 and 1.4, saving each setting to their own profiles and switching between them; they looked pretty much the same to me. I was assuming that pushing analog gain close to 1.0 would be most optimal, similar to “exposing to the right” (ETTR) in digital photography, but it doesn’t make much of a difference in the end.
On a side note, the output video on the test firmware was odd. The best way I can describe it is that it was outputting 4:2:2 or something. Optim. mode colors were not clean, but the resolution was fine, judging from the black-and-white checkerboard pattern in the 240p test suite. I could kind of salvage the video output by sampling at 682 and setting the active area to 512, but it’s not as good as it should be.
That’s all for now. Thanks paulb_nl for providing us with a test build!
- You must be logged in to reply to this topic.