Hello there! Apologies for the newbishness. My first time with crt_emudriver and I'm very excited. I know this is so close to working perfectly but I could use some pointers. There's not much info on these forums about V hold or vertical rolling. On 240p modes, my image rolls upwards continuously; on interlaced modes, the vertical position of line 0 is random every time the mode is entered.
First, what I'm working with:
ATI R9 200
CRT_emudriver 2.0 beta 15
DVI-I -> HD15 breakout box -> RGBS -> component transcoder -> YPbPr -> JVC D-Series
CSYNC enabled, taken from HSYNC pin 13
NTSC range, tried a few variations with no luck
Transcoder is a build of dekkit's
https://github.com/dekkit/RGB-to-Component-TranscoderI have tried this with the LM1881 sync separator as designed, as well as (currently) removed, jumpering C_IN of U3 to C_OUT of U3 (see
https://github.com/dekkit/RGB-to-Component-Transcoder/blob/master/VA03a/Schematic_Dek's%20RGB%20to%20Component%20Transcoder_2021-03-08.png schematic). U3 is removed from the PCB as well, just saying where the bypass is. In the physical board I've jumpered where pin 2 of the LM1881 would be to the leg of R12.
Identical results with and without the sync separator.
To eliminate other issues, I can confirm that the same transcoder worked as designed with my RGB-modded Famicom and PC Engines (both use sync on composite).
I've tried all combinations of sync polarities, only -/- (default) appears correct.
For the rolling modelines, I can adjust the speed and direction of the roll in discrete steps with the v pulse, however a stable middle would be between two steps; it's always going to roll in one direction or another.
For the vertical offset modelines, I can adjust the V Center in arcade OSD but to no avail, since the position of line 0 is not stable, it will shift the next time the CRT displays the modeline.
I have tried some other CRT ranges like custom and 15khz default, which are generally worse with more extreme rolling. My thinking is that NTSC is the most conservative and constrained range and thus the baseline I want to get working first.
As far as eliminating the TV as a potential cause, I am getting the same effect when plugging into my Sony Trinitron TV; also I can run other component sources on the JVC with no issue (Genesis with HD Retrovision cable for example).
I hope that someone with better knowledge of NTSC and CRT_emudriver can hear "V hold" or "V rolling" and aha! point to a specific thing I should be investigating... It's quite likely the issue is with csync and my transcoder. I can take some readings of DC levels, I'm not sure what range I should be shooting for in this application though.
Thanks everyone! And amazing work on crt_emudriver and groovymame, I'm beyond excited to get this working!