scaling filters

[paulb_nl]

Some observations:
– sampling phase issue is fixed. No need to fiddle with it anymore.
– My monitor syncs much faster to the optimized 256×240 mode and red sync warning led does not turn on anymore.
– Optimized modes show the image too far to the right. need to increase h.backporch ~11 compared to original firmware.
– Nintendo64 now needs 270deg instead of 90deg in optimized mode.
– I noticed the flickering pixels sometimes in linex3 too
– With samplerate 682 h.active 512 linex2 mode for SNES the filters didnt seem to work.

I like the lq filter the most. eagle indeed does not look so good.

[redguy_]

Thanks for trying it out.

– I’m not sure why the image shifts, but I thought I set the default to +12 for M3 and +15 for M2 to fix that. I’ll check if that made it into the binary I posted. This is caused by the timing changing in a way that I don’t understand.
– The pixel flicker is still a mystery. I think there’s too much filter logic to fit in the output clock, but some fixes for that are not showing a difference. Maybe it’s not a timing problem. Applying filters that were originally designed to work on precise values of a digital image (in an emulator) that is actually passing through a DAC->ADC conversion is not ideal.
– I’ll have to look at linex2 with those settings and see if there’s anything that can be done there. It would be nice if all modes could stop using the clock divider in the tvp but I wasn’t able to get that to work properly.

I’m going to remove the eagle filter and have just two options: none and scale. Then there will be an additional option for filter strength which will be controllable in 12.5% increments. 50%=current lq and 100%=current scale. That will enable more fine-tuning of the existing filters.

[paulb_nl]

Yea I should have mentioned that I noticed you changed the defaults. I first noticed the image shift when I tested my PAL SNES so you probably didn’t change the 288p defaults.

Will you share the samplephase code changes with margs? It seems to work great.

[redguy_]

My changes are at: https://github.com/RedGuyyyy/ossc/tree/master

Marqs suggested the fix for the sampling phase shift so I’m sure he knows what needs to be done and a cleaner way to do it. My fix is also incomplete. It would be better to move the clock divider for all DIVBY2 resolutions to the FPGA, but when I tried doing that both linex2 and linex3 m0/m1 would occasionally flash a set of black frames. If I can figure out why it would simplify the change.

[redguy_]

https://drive.google.com/file/d/0Bx9gzQZCkH8qOGFKSTFncHB1bVk/view?usp=sharing

FW 0.75-rg0a

– Added scaling filter strength and removed eagle/lq. 50%=lq, 100%=scale.
– Updated all linex2/linex3 modes to use a DIVBY1 clock in the tvp.
– Updated hsync and hbackporch settings for DIVBY1 mode.

The flashing screen in linex2 and linex3 M0/M1 ended up being different hsync requirements in DIVBY1 mode. I don’t have a PAL nes/snes or higher resolution sources and had to guess at the hsync and hpackporch changes. I suggest anyone trying this firmware to reset your settings and see if the defaults work correctly.

Still looking into the flickering pixel problem with scaling filters.

[marqs]

I’ll take a look into the implementation later this week.

Now that I thought about how Line3x M2/M3 could be implemented better considering TVP7002’s limitations (jitter at low PLL frequencies, broken DIVBY2 etc.), it would actually make sense to sample at 4x/5x of console’s dotclk rate, multiply resulting clock by 3 and utilize every 4th/5th sample while drawing output. That way sampling clock would be high enough to provide minimal jitter without DIVBY2, and it would also provide more granularity for sources that have fractional number of dots per line like PSX 320×240 with 3413/8 = 426.625 dots.

[marqs]

I implemented 5x oversampling for 256-column mode tonight, and it seems to work great. Phase selection is no more randomized, and overall clock stability is much better than before. These changes also allow evading SC-512-L/DVI’s color inversion bug by setting samplerate (=output pixels per line) off by 1/5th source dot (no visible degradation).

[redguy_]

That sounds ideal for handling the low res sources. Is there any real downside to oversampling by 5x? I guess the tvp may run hotter and draw more power, although, it may actually be optimized for higher resolutions. Is it worth averaging (or median?) the samples rather than dropping them?

I looked into adding the hqx filter, but the implementations I’ve seen all generate a large lookup table to handle the RGB->YUV conversion and also perform some of the calculation. The tvp can output YUV, but I don’t think that helps. I wonder what happens to the filter if bits are dropped (or maybe hashed together) from the RGB value to make the lookup table a reasonable size.

[paulb_nl]

@marqs, Sounds great. fractional sampling rate should also help with the Nintendo64. Does that mean we have to set the sampling rate for example to 1705 instead of 341 in the timing tweaker?

@redguy_ Have you seen Ludde’s hq2x implementation? He mentions that he removed the YUV stuff.
http://fpganes.blogspot.nl/2013/02/the-worlds-most-compact-hq2x-in-verilog.html
https://github.com/strigeus/fpganes/blob/master/src/hq2x.v

[marqs]

@redguy_ I haven’t yet noticed any notable downsides compared to all the benefits. Averaging is probably not a good idea, as 1-2 of the samples end up being taken on source dot boundary and thus are fuzzy/unstable. I made the implementation so that upper bits of phase select control which sample of the sets of 4 (320×240 mode) or 5 (256×240 mode) are used, and lower bits control TVP sampling phase.

@paulb_nl Yes, H. samplerate should be then set to 5x source dot rate when using 256×240 mode. H. active, H. synclen and H. backporch values are still shown/set as before, and multiplied by 5 internally.

[marqs]

Updated code is uploaded to github, it should make optimized modes much more usable now.

[paulb_nl]

Thanks Marqs! I have tested the latest changes and I have some issues. Sampling phase works great.

-With horizontal scale for 256×240 smaller than 4 I get a doubled image to the right.
-256×240 and 320×240 optimized randomly show a light or striped vertical bar at the right side of the screen. It happens frequently with 320×240 optimized with settings for N64: H.samplerate 1546, H.synclen 22, H.backporch 36. sampling phase 0. Sometimes you have to turn the console on and off a few times to make it appear.

Btw, I found a typo in scanconverter.v with double G_pp1 and G_out at https://github.com/marqs85/ossc/blob/release/rtl/scanconverter.v#L342

[marqs]

Yeah, work is still in progress so not everything works correctly. Newest commit should fix masking issue (+adds line4x) though, but I’m not sure if your latter problem is part of that.

[redguy_]

@paulb_nl Thanks for the links on hqx. I implemented hq2x and hq3x, but have several bugs to sort out with both.

I took a look at the changes in the latest release branch. Oversampling the input definitely helped to simplify the code related to optimized line3x modes. One change I’ll have to make when I merge again will be to drop the samples when writing into the linebuffer rather than when reading. With a 4k total linebuffer I split it into 4x 1k buffers and need the write pointer to stay under 1k to support the 3×3 (1×3 per cycle) read bandwidth of the filter logic. A 8k linebuffer would also work, but I didn’t try to fit it.

[paulb_nl]

Yeah, work is still in progress so not everything works correctly. Newest commit should fix masking issue (+adds line4x) though, but I’m not sure if your latter problem is part of that.

Both problems were fixed with the masking update. I saw you also corrected the typo but you missed the second typo 🙂 https://github.com/marqs85/ossc/blob/release/rtl/scanconverter.v#L395

[Author]

Posts