Forum Replies Created
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.
Could you also try other firmware versions between those? It could help pinpointing the change that affects this.May 13, 2019 at 3:30 PM in reply to: OSSC red light, losing sync on Genesis/Saturn after ~10min of use #26188
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.
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.
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.May 9, 2019 at 4:18 PM in reply to: OSSC red light, losing sync on Genesis/Saturn after ~10min of use #26163
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.
Did you configure the toolchain with correct arch and abi options?
./configure --prefix=/opt/riscv --with-arch=rv32emc --with-abi=ilp32e
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.
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.
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.
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.April 28, 2019 at 8:49 AM in reply to: Does the CPS2/CPS3 Digital AV Board overclock any of the CPS2/3 chips? #26058
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.April 26, 2019 at 4:19 PM in reply to: Does the CPS2/CPS3 Digital AV Board overclock any of the CPS2/3 chips? #26032
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?April 10, 2019 at 11:09 PM in reply to: Is outputting to a frame/proper de-interlacing possible on the 1.6 hardware? #25823
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).