Menu

Show test image during no sync to prevent monitor turn off.

Home Forums OSSC OSSC – Feature Requests Show test image during no sync to prevent monitor turn off.

This topic contains 9 replies, has 5 voices, and was last updated by  James-F 8 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #19246

    James-F
    Participant

    My PC monitor (most if not all) keeps turning off when I switch the console off to change a game, or change to a different scart (console), sometimes hundred times a day (what.. I experiment šŸ™‚ ).
    This shortens the life of the monitor greatly, and adds long seconds of waiting time between game changes till the monitor boots up and turns on its backlight.

    To prevent this, a function of sending a test pattern (already exists) to the screen when “NO SYNC” will be fantastic, or even a black screen to prevent showing anything (good for recording) while keeping the screen alive, or even just sending some sync signal without image content, or a button on the remote control to manually show the test pattern will do fine if automatic switching is troublesome.

    Many thanks if you decide to implement this marqs.

    #19287

    SirRockALot
    Participant

    I found it initially strange that the OSSC does not return to the boot up test screen when it loses sync. But wouldn’t it be distracting to see the test screen flicker up every time a console switches video mode? Also going to the test screen before switching to whatever signal the console next outputs would likely slow down the mode transition. The TV now has to do two video mode transitions instead of one, might be in the middle of syncing to 480p from the test screen when the console starts outputting a 480i signal etc. I can see there being good reasons why it is done this way. Is there no option on your display to prevent it from turning off?

    #19289

    James-F
    Participant

    99.999% of PC monitors will turn off after 2 seconds of no signal at the input, and changing a cartridge or a disc definitely takes longer than that.
    It should be a compatibility option that the user can switch on/off if a TV or PC monitor is used.
    Yes, there might be a problem with automation as you described, but that’s why I also suggested a button on the remote to switch to the test pattern for breaks longer than 2 seconds. The pause button on the remote looks really good. šŸ™‚

    #19292

    nmalinoski
    Participant

    If it’s truly a problem, you could look into getting an EDID minder; I suppose you just better hope that everything coming out of your OSSC ends up as 480p.

    #19294

    James-F
    Participant

    I am sure the OSSC with its Altera Cyclone IV in the hands of a bright engineer can solve this problem in no time, no need for additional external mystery boxes.
    I believe once the OSSC uses the miniSD card, its true potential will be revealed.

    #19360

    marqs
    Participant

    There’s a pending pull request on automatic mode switching, I’ll see if this feature could be integrated at the same time.

    #19361

    BuckoA51
    Keymaster

    (copypasting marqs response to the question about using MicroSD as memory on Shmups)

    the ideal solution for getting more memory in use would be locating soft-CPU’s code segment into on-board flash which has more than enough space. However, running code from SPI flash (or micro-SD) without caches (not supported by Nios II/e) would drop CPU performance to somewhere between 1/50th and 1/100th of current architecture which offers single-cycle access to memory. While the CPU is only doing control tasks, such big drop would likely lead to sluggish UI and slower mode detection. The solution would be to get rid of Nios II, and replace it with an open-core such as OpenRISC, LM32 or RISC-V. However, it’s far from a small task as you’d need to integrate the core to the subsystem, implementing any missing/implementation-specific parts (e.g. JTAG, bootrom&loader, linker scripts) and re-design firmware storage/update procedures. There’s a couple projects like Vectorblox ORCA and FuseSoC which could reduce required integration work, though – I should take a closer look when I have more time.

    #19364

    James-F
    Participant

    Oh, I wasn’t aware of the automatic mode switching pull request, thank you for looking into this.

    +static const char *auto_input_desc[] = { "Off", "Current input", "All inputs" };
    For people who do not switch often between 480i and 480p in PS2 games, I think “Test Pattern” should be included here.
    But as pointed by SirRockALot, timing is critical here for different monitors, so maybe “auto_input_timestamp” should be user adjustable?

    I should add that my mod-chipped (Matrix Infinity) PS2 PAL console switches between 626i and 525i modes back and forth around 10 times like crazy before an NTSC game starts.

    As for the OS on the MiniSD, I understand.

    #19382

    SirRockALot
    Participant

    The amount of mode switching my PAL PS2 does when going from PAL Bootup -> FreeMcBoot -> OPL -> NTSC Game 480i -> NTSC Game 480p is pretty annoying šŸ˜‰ Probably better to not instantly switch to the test screen each time.

    Thanks for the details on freeing some precious FPGA RAM by offloading your CPU code to flash. Shame there isn’t some really simple option like synthesizing a different variant of the core that just supports executing from flash with a small RAM cache.

    #19387

    James-F
    Participant

    Probably better to not instantly switch to the test screen each time.

    The timer will start only when there is ‘no sync’, nothing will be instant nor auto-switching if the user doesn’t want it.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.