Hybrid Scanlines

Viewing 15 posts - 76 through 90 (of 98 total)
  • Author
    Posts
  • #19858
    paulb_nl
    Participant

    @Fnnrqwin A few posts back I already told Borti how to fix the glitches.

    #19870
    borti4938
    Participant

    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.

    #19876
    Fnnrqwin
    Participant

    I’ll post a video of it when I’m off work. Basically, in 5x mode 240p sources create small vertical black lines in semi-random locations. Seems like they mostly cluster, or at least are most noticeable, in brighter sections. This happens with scanlines on or off. 2x through 4x does not create this problem. Vanilla 5x works perfectly on my setup still.

    #19877
    borti4938
    Participant

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

    #19878
    paulb_nl
    Participant

    I have run the updated build for a while and didn’t get any glitches. Someone on the shmups forum did report glitches but dont know if he used the latest firmware.

    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.

    #19879
    marqs
    Participant

    Meeting timing requirements is likely to get harder as the design progressively grows, thus leaving less resources for routing. With couple last official firmwares I’ve had to run around 20 iterations with different initial placement seeds to minimize violations. Another challenge is muxing of various clock sources (PLL outputs etc.) which potentially increases skew. Ideally only a single PLL output would be routed to logic and PLL settings could be changed dynamically, but changing PLL configuration (via ALTPLL_RECONFIG) is not very straightforward with Cyclone IV and would likely consume at least 1 M9K. Timing constraints have also been quite a mess with all inter-clock relationships, but I’ve now made a rewrite of those using additional generated_clocks which simplifies SDC and hopefully improves robustness.

    #19880
    marqs
    Participant

    @paulb_nl: did you check “Hold summary” on Quartus II reports? In many cases hold violations are more severe as they are in effect even if effective pixel clock is lower than given constraint/maximum. A good guideline is to check that there are no setup violations in fast corner and no hold violations in slow corner(s). Minor violations are still acceptable (and often unavoidable) as gate models always include some pessimism.

    #19886
    borti4938
    Participant

    @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?

    #19890
    marqs
    Participant

    @borti4938: there is an explitcit rule in ossc.sdc line 64, but it requires certain naming from the pipeline registers so it may not apply to your added registers. I just pushed the commit with rewritten timing constraints – it’s not fully tested yet but something like that should work better.

    #19892
    borti4938
    Participant

    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.

    #19974
    Fnnrqwin
    Participant

    Update on the firmware: the latest firmware resolved the glitch I was having with 5x mode. However, on the vanilla firmware my TV is compatible with the NES and SNES in 5x mode. With this custom firmware, they only display up to 4x. Genesis and N64 work fine in 5x.

    The fact that the TV works with the vanilla firmware for those 2 consoles and but not this firmware hints that something’s still up with the way this firmware treats 5x.

    #20007
    mdd45
    Participant

    So hybrid scanlines feature is going to be included in final 0.81 fw ?

    #20061
    borti4938
    Participant

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

    #20062
    rock145
    Participant

    I tested the the hybrid scanlines beta firmware and I like it very much. I would like to thank everybody that contributed in getting this to work with ossc. I wanted to know if it is possible to add a scanline thickness setting. I think that fighting games look better with thicker scanlines like: Streetfighter 2, Mortal Kombat,Art of fighting and many more. It would give a cga arcade look to it.

    Here is a link when it was previously talk about. https://videogameperfection.com/forums/topic/scanline-thickness-setting/

    #20131
    Harrumph
    Participant

    Tested bortis build now, really liking the hybrid scanlines, thank you paulb_nl and borti! Great to see such collaboration!
    I see flickery pixels here and there in Lx5 optimized modes, so that bug is not completely ironed out it seems. Tested with both 256×240 (snes) and 320×240 (gbi).

Viewing 15 posts - 76 through 90 (of 98 total)
  • You must be logged in to reply to this topic.