[redguy_]

Here’s the last version ported to the latest 0.77 source code. It includes audio. I use it without issues on my audio-less ossc. It’s still experimental and has several bugs.

https://github.com/RedGuyyyy/ossc/blob/master/fw/ossc_0.77-rg0d.bin

Not much has changed in the filters from the previous FW. For those who haven’t tried it before:
– [Post-proc] -> [Filter/Filter str] control the filters. You can choose between ‘scale’ or ‘hq’. Filter strength only affects scale. There’s also a test filter called ‘diff’ that shows which edges scale applies changes to.
– It works best at 240P x2 or x3 in the optimized format for your input. E.g. 8:7/4:3.
– 480i 2x (bob de-interlacing) and 480p 2x are also supported, but they don’t add much other than the flashing pixels (see below).
– Due to the nature of going through DAC (snes) -> ADC (ossc) conversion, applying a filter that was intended for digital input (emulators) results in artifacts that are most noticeable on static images. These artifacts are flashing pixels that jump between the original pixel and the filtered pixel. I’m not sure of a solution without having access to a frame buffer. Reducing the filter strength with scale will lessen the flashing.
– The filters add one scanline of latency over the base ossc FW.

[redguy_]

Yes on merging with 0.77. I already merged with an old version of 0.77 a while back but never posted it. I just tried to merge with the latest 0.77 changes and diff gave up and just told me the whole scanconverter.v file is different without identifying specific changes. It will be fixed this weekend and a new file will be posted.

l4x and l5x filtering is a lot of work that I don’t have time to look into right now. There’s not much space left on the FPGA without making some of the changes marqs mentioned a while back. I’m not sure whether 4x or 5x filtering is even possible without more room. scale4x is probably scale2x applied twice. Not sure if scale5x is even defined or if I would need to make it up. I took some shortcuts in hq3x to use a lot of the hq2x code (which was already based on code with shortcuts).

[redguy_]

Glad it’s working out for you. I don’t have a psx to test on, but you did motivate me to dig out my xbox and ps2 to see what they look like.

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

FW 0.76-rg0c

– Fixed non-optimized modes “black screen” bug.
– Added filter support for 480p line2x mode.

I had some time to look at the firmware again and realized the previous version broke a lot of the non-optimized modes.

I also looked at 480i and when line2x (bob deinterlacing) is enabled it can use the filters. Although, I’m not sure how desirable the effect is due to how a field gets scaled to produce 480p.

480p had me scratching my head for a while as going through the filter logic caused it drop pixels. It looks like the it6613 chip is used to perform the scaling on certain resolutions. I disabled that and forced it to behave like the other optimized modes. The pixel scaling filter effects start to vanish on inputs with much higher color selection and higher resolutions. 480p linex2 on ps3 with filters really only added flickering pixels and not much else.

[redguy_]

Currently, the filters are only enabled in line2x or line3x mode and if it’s one of the optimized 240P resolutions. That was to simplify the check for a H_TOTAL – H_SYNCLEN that’s under 1024 pixels so the linebuffer isn’t overrun. 480p and some of the other resolutions should work by just enabling the filter for them. Some of the higher resolutions may work with some changes to drop useless samples. I’ll give a try this weekend and see what happens.

Not sure how good 480i will look with filters given that it’s comparing every other row.

I haven’t solved the flickering pixel problem. It may be possible with a frame buffer, but there’s no room for one.

[redguy_]

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

FW 0.76-rg0b

– Merged with latest release
– Added hq2x/hq3x filters
– Fixed some bugs in scale3x filter
– Changed linebuffer to drop samples on write to support scaling filters

I like the way the hqx filter turned out. It’s heavily based on the fpganes implementation with updates to support hq3x. There’s also a temporary debug “diff” filter mode to help see what the hqx diff function output looks like. Pixels still flicker with the scaling filters, but I have some ideas on how to fix that now that I know what the problem is.

With the diff mode it’s easy to see why the pixels flicker. Even with static images there is some temporal change in pixels across frames. Since the diff function has a sharp cutoff any comparison that is near that boundary will cause it to bounce between different blending functions and any large changes in the output pixel will result in the flicker. I think I know how to fix it for the scale filter, but hqx will require some more thought.

[redguy_]

The problem is pixel change between frames even with a static image. Within a frame (inside the linebuffer) they are stable unless I introduced a bug with the read/write addressing and enables I haven’t found yet.

For example, I added a filter that outputs a red pixel if the compare fails and a green pixel if the compare succeeds. With the TVP input there are pixels that toggle between green and red on a static image. With a generated input done within the RTL (input is written into the linebuffer the same way as the TVP input) the image is stable and no pixels change from green to red.

[redguy_]

I had some time to look at the scaling filters today. I added the filter and 4x linebuffer changes to the latest release code. The hqx output doesn’t look right so I ported the code (with as minimal changes as possible) to a snes emulator and got it working there. Unfortunately, that didn’t fix much as there was only one minor bug in the implementation of the hq3x algorithm.

The real problem is the comparison logic working on values from the TVP which are not stable like direct digital input in an emulator. With scale, it’s easier to work around than hqx since it does a binary comparison on a smaller set of neighbor pixels to decide to copy a neighbor (lqx does an average) or keep the current pixel value. The comparison can include some margin. The flashing pixels are due to comparison function failing on a set of frames and then passing on the next set of frames. With a small margin the delta between the pixels is small and the change between a comparison toggling isn’t noticeable, but nothing compares successfully and scale doesn’t do anything useful. With a larger margin the delta between pixels is bigger and flashing is noticeable, but then scale starts doing useful smoothing. A hack to fix this would be to perform interpolation at the edge of the comparison function to have the change be gradual and also support a margin.

Hqx also performs a binary comparison, but it does it against all neighboring pixels which feeds into a lookup table to say how to blend several of the neighbor pixels and current pixel together. The lookup table then provides an opcode for the type of blending to perform. So random changes in the comparison make the image crawl a bit and generally result in bad output. I can’t think of an easy hack to fix this.

Ideally, there would be a way to remove or ignore the variations in pixel values frame to frame when it isn’t actually changing. Something simple like dropping a number of the low order bits of the RGB values doesn’t seem to work well. I was hoping the latest release code with the oversampling of the input would improve things, but nothing changed. My current plan is to collect some statistics from static images and find out which pixels tend to change value and what the set of values are. This will hopefully lead to a better set of comparison functions. A frame buffer would help with this, but testing a few rows at a time is still useful.

Any ideas or suggestions are welcome.

[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.

[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.

[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.

[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_]

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.

[redguy_]

I updated the link to include FW without the audio features compiled in.

FYI, I also don’t have the audio board add-on and, as far as I can tell, it functions correctly with the audio compiled into the FW.

[redguy_]

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

FW 0.75-rg0
– Added preliminary scaling filters for linex2 and linex3 M2/M3 optimized video modes.
– Fixed (workaround) for sampling phase 180 degree shift in M2/M3 optimized video modes.

* I normally flash with jtag, but I tested the SD card and it was able to correctly flash to an unmodified firmware from 0.75-aud-rg0 and also flash from an unmodified fw to 0.75-aud-rg0.
* The scaling filters selection is available in the post-processing menu. It defaults to none. Eagle3x is an odd combination of eagle2x and lq3x which doesn’t always look very good. I usually use lq when I’m in the mood for filters.
* Filter delta controls the difference allowed when comparing two pixels. It’s best to leave this at 32 right now.
* Selecting a filter adds an additional 1 scanline of latency.
* Selecting a filter results in the image shifting down a scanline due to delayed data read relative to sync/data_enable. That’s a bug I have yet to fix.
* linex2 mode still has the flickering pixel problem when filters are enabled

I tested all basic functionality that I could think of (only on snes and nes), but please understand that this is an alpha, custom firmware and you should only try it if you understand the implications.

[redguy_]

I made a workaround for the flickering in (1) and fixed the missing column of pixels in (3). I’m still not sure how to fix the flickering pixels in linex2 mode with filters enabled (2), but I’ll keep looking at it.

Anyone interesting in trying a new firmware out? It hopefully fixes the sampling phase 180 degree shift problem after reset/desync and also adds some preliminary scaling filters for linex2 and linex3 optimized modes. I don’t want to post a public link because it includes 0.75 changes from marqs that he may not be ready to widely distribute.

[Author]

Posts