Menu

marqs

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 449 total)
  • Author
    Posts
  • in reply to: Amstrad Mega PC with OSSC #26224

    marqs
    Participant

    I checked the changes and there are a few possible causes. Could you try if the following helps with the newest fw: when you have sync locked, press profile load hotkey (TV/AV) on remote but don’t select a profile. That rules out the CPU detecting sync/mode change which could cause erratic behaviour if bad status is received from the digitizer.

    in reply to: Amstrad Mega PC with OSSC #26220

    marqs
    Participant

    Could you also try other firmware versions between those? It could help pinpointing the change that affects this.


    marqs
    Participant

    If anyone of your friends have OSSC or alternative RGB cables for the problematic system, you should try those before investing into new cables. If you have original composite cables for the systems, you could even try hooking composite into Y (green) input and check if you see same sync issues in YPbPr mode (which then gives a BW picture). Otherwise this is a hard case to debug without starting to ask opening scart cables or probing sync signals via oscilloscope.

    in reply to: Amiga – Multiple OSSC power cycles needed to sync #26181

    marqs
    Participant

    Ok, the asterisk in 263p* indicates that Amiga is using alternate field ID on VSYNC, and unfortunately the digitizer chip has trouble locking to that reliably (like with Jaguar in PAL mode or Taito F3). There are a couple workarounds (e.g. having another source initially connected to component input or SCART via a switcher, and then changing to Amiga input after both machines are powered on) but the only reliable solution is to hook the problematic system to VGA input (RGBS mode) which has a bit different sync processing.

    in reply to: Amiga – Multiple OSSC power cycles needed to sync #26177

    marqs
    Participant

    Can you post the details shown on the info screen (press INFO on remote) when it’s synced. I also recall some Amiga models/modes needed H-PLL pre and post coast adjusted to 3 in sync menu.


    marqs
    Participant

    That sounds like a defective OSSC, although it’s a bit strange that you don’t see any issues with SNES. Before sending it to warranty replacement, you could try adjusting sync Vth setting in sync menu.

    in reply to: OSSC Firmware build fails on linker #26160

    marqs
    Participant

    Did you configure the toolchain with correct arch and abi options?
    ./configure --prefix=/opt/riscv --with-arch=rv32emc --with-abi=ilp32e

    in reply to: Free PINS on the Cyclone iv in OSSC V1.5? #26133

    marqs
    Participant

    SD card pinout. SD_DAT[2] are SD_DAT[1] are unused in SPI mode.

    in reply to: OSSC self built. Weird color issue. #26132

    marqs
    Participant

    Are you sure THS7353 input coupling caps (C3-C7, C12) are correct value? You could also try with higher that default value, e.g. 4.7uF.

    in reply to: Amstrad Mega PC with OSSC #26106

    marqs
    Participant

    The digitizer chip is a bit picky on HSYNC/VSYNC alignment which might be the issue here. You could try enabling “AV3 interlacefix” on the compatibility opts. Another option would be a sync combiner (dedicated or as part of VGA->SCART RGB converter) if you happen to have one.

    in reply to: Swap RGB #26069

    marqs
    Participant

    I recall bumping into this issue with SC-512N1 with certain lineX / optimized mode configurations. One workaround there was using different surface format, but that had a few drawbacks and might not be available on other cards. I’ll have to check if a simple R< ->B swap compabibility fix could be added on the firmware.

    in reply to: Is this amount of flickering normal? #26066

    marqs
    Participant

    The video doesn’t seem show it properly, but yes, that level of flicker is expected from interlaced sources which don’t use any flicker filter. Any scaling and framerate conversion performed by the display / capture card is also going to make it worse. It seems that vg275q doesn’t indeed support interlaced sources, but fortunately at least most PSX games use non-interlace modes primarily.


    marqs
    Participant

    Audio is tapped from digital path before the amps, so it doesn’t necessarily end up louder than other sources.

    For CPS1, there is a small adapter board on the works that will enable using the base cps2_digiav board on it neatly.


    marqs
    Participant

    On-board clocks / game speed is not altered in any way, and no framerate conversion is done (so your display must support ~59.6Hz). There’s not many scanline options yet, but they’re fairly easy to merge from OSSC project once OSD & control features are implemented. As for digital volume control, it’s possible to implement but why would you want to adjust volume via the board (which may reduce dynamic range) instead of a receiver on the other end of HDMI cable?


    marqs
    Participant

    Support for composite and fancy de-interlacing was conciously left out when OSSC was designed, and lack of those features should become apparent when reading wiki or other introduction materials. That said, the former becomes a limitation only with a few machines like C64 (not likely to be 90% of potential users) while the latter is a problem mostly with PS2 or PAL GC games (most PS1 / Saturn games do not use interlace).

Viewing 15 posts - 1 through 15 (of 449 total)