[borti4938]

I‘m glad to read that! 😀
I wish you many beautiful hours with your renewed SNES 🙂

[borti4938]

The problem you have is related to a SuperCIC which does not properly sync with the CIC-key on the cartridge. By looking at your installation pictures, you also forgot to solder one of the CIC pins at the cartridge slot (pin 24).

[borti4938]

Do you have any installation pictures? Otherwise it‘s somehow hard to say what is causing your issue.

[borti4938]

It has been merged into official source and will be in.

[borti4938]

Thank you very much 🙂 Also using the /* synthesis ramstyle = “logic” */ primitive on the post-processing registers helps a lot to relax timings. Fw-build runs through but I haven’t tested it yet.

[borti4938]

@paulb_nl

Why didn’t you just revert those 2 commits I mentioned instead of changing more of the code? With the reverts Fmax on pclk_5x is 158 & 161Mhz and now with your updated code Fmax of pclk_5x is only 137 & 150Mhz. So that is quite lower than the needed 161Mhz.

Because I didn’t got the same results as you did? Do you use the same fitter seed as I committed (or in general the same qpf file)? Do you use the latest quarts prime version?
With the latest build and by stuck at your ‘benchmark’ I got F_max 165MHz and 177MHz.

@marqs:
Most timing violations I have seen are in the PP-pipeline – either between two RAMs or between the two concurrent multiplier. However, launch clock is always pclk_indirect and latch clock one of the pclk_act, which makes me wonder. Shouldn’t be that added as false paths?

[borti4938]

Also in the updated build? The timer analysis give higher F_max for pclk_5x than the values above.

[borti4938]

Could you please retest the builds in my GitHub test branch for its LineX5 capability?
https://github.com/borti4938/ossc/tree/dev_lcdbl
Could you also define “glitch” for me?

I‘ve done a bit in order to get a better understanding what the Synthesis can effort and how to tweak the overall speed just by changing the code a bit.

[borti4938]

Ok, the linex5 does not work on my setup; so I didn’t know.

Could you download the source and remove the latest code change commit where I add an additional output register on the top level entity?

https://github.com/borti4938/ossc/commit/3714ad4f734d9cf8107d52c6b41ba1d8e039ac5e

Maybe it’s related to that test!?

[borti4938]

@paulb_nl

I delayed the start of the reverse lpf by one tap now (https://github.com/borti4938/ossc/commit/145e3a5). This reduces the logic after the large multiplexer (R_act,G_act,B_act were written into two following registers and used in an adder/sub). I hope this helps a bit.

I also merged latest official fw into the branch. Here is the new build: https://github.com/borti4938/ossc/tree/dev_lcdbl/fw_build

To the main topic:
If there is nothing to add / no bugs found in the scanline generation, I will update the upstream branch for the pull-request 🙂

[borti4938]

This is great Borti! Nicely done. Though for the casual user it probably makes more sense to just display Sl.hybrid str. as 0-15 (save 1 bit ? ) or display 0-100% for 0-15.

Great that you like that, too 🙂

Indeed, I was thinking about exactly the same display solution, too. This are the reasons why I decided against that:
– displaying 0-15 are some kind of ‘magic numbers’ for the user
– displaying 0-15 as 0-100% is not what exactly calculated
– 1 bit extra has no cost in sw (it’s a 8bit variable anyway)
– 1 bit extra in hardware is neglectable

The only odd feeling was to stop setting at exactly 10000; but hey, if it is so, it is so 😉
Another soultion I had in mind was stopping at 150% or 175% but I wanted to have it sharp.

What about other opinions?

While we are beta testing, maybe make all parameters variable (0-100%) so we can find a few sweet spots?
That would be: Contrast str, Scanline str, Gamma fix str.

One side note: setting 100% sl.str., 100% hybr.str. and mult. method gives you an x^2-function* at the output. A special case of gamma adjustment in the scanline.
(* not 100% as I used Y (YCoCg appr.) for multiplicationand not RGB individually; so it is R*(R/4+G/2+B/4), G*(R/4+G/2+B/4) and B*(R/4+G/2+B/4))

Indeed its not caused by your firmware. I had tried it on previous firmware before I reported it and it worked properly then but it was just a coincidence. It works randomly. I’ll have to check it out why this happens.

It strange is that it works / works not by random.

Edit: I’ve an idea where this problem comes from. But I just can test it this evening. @paulb_nl

[borti4938]

OK; I updated the GitHub branch once again:
-> hybrid strength can now be adjusted from 0% (off) over 100% (SL-str is 0 exactly at I_max, i.e. 255) up to 200% (SL-str becomes 0 at 0.5 x I_max, i.e. 127) in steps of 12.5%. (yes, 17 steps (5bits needed). I had 16 steps before (4bits) but stopping at 188% looked a bit strange)

Reverse LPF works now but in Optimized mode the first column of pixels skips the reverse LPF every other line so it results in a checkerboard effect.

Have checked that and I was able to reproduce that. But it was the same on the fw-build 0.79, which I downloaded from official hosting page. Could that be a trigger issue (I haven’t change anything at the trigger)

Yes I know the scanlines lose color but his pictures showed extreme results with the car picture almost black & white. Even with 100% black scanlines there is still color in the picture so it should not be black & white.

You are absolutely right! My comment was regarding the off-colours (not the b/w)…

Anyway – back to topic; the hybrid scanlines:
I guess we found a very good common approach. Hope you are fine with it

[borti4938]

The automatic bl off/on won’t be part of the official fw. It’s on my test branch because I personally don’t want to switch bl everytime off and on every time. Implementation is 100% HDL to not use software code space for that.

[borti4938]

Two fun facts beforehand:
– We talk about ‘scanlines’ but we mean off-scanline, which is the line to be darken. But I will keep our false friend 😉
– Multiplication and subtraction are both linear operations

The new hybrid method vs current method is like multiplication vs subtraction so if you want to keep that maybe you can set multiplication to use the new method and subtraction to use the current method?

Give me one good reason why keeping your origin hybrid approach?
The main drawback in my point of view is that the saturation point (point where the scanline completely disappears) massively depends on the scanline strength.
My modification on your approach resolves the problem (yes, it is a problem in my point of view). And as said, it can be overdriven without any problem such that the saturation is before intensity equals 1. See the comparison here:

In this perspective one could call this option hybrid strength and make this a variable number from e.g. 0 to 15, where 0 is off and 8 is 100%.

Linear with old hybrid produces the most convincing (CRT like) scanlines but the gamma is too high (dark image).
Multiplication will have more correct gamma but the scanlines do not vary with brightness enough.

In the same way the multiplication can be overdriven, too. This would allow the user to set the output to zero right for small intensities.

Gamma in the scanline is atm only possible by either tailor approximation or piecewise linear interpolation. I would delay this for now.

And what now? I corrected the GitHub branch. Hybrid contrast is still the modified approach with example values off = 0, low = 50%, med = 100% and high = 125% -> https://github.com/borti4938/ossc/tree/dev_lcdbl (RLPF also corrected)

I also want to mention that the discoloring observation by @retrorunner with subtraction method for scanlines does not come from his TV. I build a firmware where you can see, what the scanline really looks like.
it can be downloaded here: https://www.dropbox.com/s/g499kqjklbqoceq/ossc_0.80-what_sl_do.zip?dl=0
Just set the scanlines to manual and vertical to draw all lines as like as they were scanlines. You can definitely see the discoloring effect which is increased in certain circumstances with hybrid scanlines. And no: do not compare with pure color bars, compare at ‘ordinary’ material, where you have mixed colors. E.g. the logo in F-Zero will become red with the subtraction method.

[borti4938]

The clipping looks awfull on my set. So I would love to keep that as it is.
However, what I‘ll do is to make overstearing possible such that the curve saturates before 255.

I‘ll take a look into the rlpf. I have an idea where a bitshift error is. I ask you because it was never stable for me. (and also I’ve a weird feeling about it from what I‘ve learned about equalization in communication engineering, but that’s another point)

Will got you back soon.

[Author]

Posts