Bienvenido Vlad, vamos por partes:
La discrepancia con el refresco original no se traduce en "tearing" sino en saltos o "hipos" en el scroll. En principio, teóricamente un emulador debería ajustar la velocidad de emulación al refresco de pantalla cuando activamos la opción de sincronización vertical. De esta manera se podría llegar al caso extremo de correr un juego NTSC (60 Hz) sobre un modo de vídeo PAL (50 Hz) manteniendo un scroll totalmente suave, a costa de modificar la velocidad original del juego. Lo que ocurre es que la gran mayoría de emuladores tratan de mantener la velocidad original además de esperar al refresco vertical, lo que hace que la sincronización sea problemática y aparezcan hipos intermitentes.
Hago esta introducción para subrayar que no es necesario buscar una precisión obsesiva con los refrescos hasta el tercer decimal, porque un emulador bien programado debería poder absorber estos pequeños errores, además de que hablamos de valores nominales que con toda probabilidad ni siquiera serán los realmente existentes en el hardware original, ya que los cristales de cuarzo a fin de cuentas están expuestos a variaciones de temperatura que alteran sus propiedades.
Respecto al problema que expones, si lo que observas es "tearing", es que la sincronización vertical no está funcionando en absoluto. Para lograr la sincronización vertical, el emulador recurre a OpenGL o DirectX, que por su parte se comunican con el driver del fabricante de la tarjeta, que es el que en última instancia proporciona las funciones de hardware correspondientes. Si algo falla en la cadena, la sincronización vertical no funcionará, y lo que es peor: el emulador ni siquiera lo "sabrá". Los diferentes fabricantes no implementan OpenGL de la misma manera, desgraciadamente. En mi experiencia con OpenGL y tarjetas ATI, la sincronización vertical sólo funciona correctamente si se fuerza externamente desde el panel de control de la tarjeta. Con tarjetas Nvidia esto no es necesario. Los resultados con DirectX son mucho más predecibles que con OpenGL. En tu caso, probaría a usar DirectX (Direct3D) en las opciones de Retroarch.
Habría que decir que las opciones de sincronización de Retroarch son algo extravagantes. Que el usuario tenga que introducir el refresco del monitor como dato conocido no deja de ser pintoresco. Dicho esto, hasta donde yo sé, Retroarch sí que permite absorber una cierta desviación del refresco, ajustando la velocidad de emulación y el audio. Si bien inicialmente había un límite pequeño a la desviación permitida, creo haber leído en algún sitio que ahora ya permite una desviación arbitraria.
Finalmente, si quieres mejorar la exactitud de los refrescos, mejor hacerlo manualmente que con la opción "iterations", ya que puede haber variaciones incluso entre las 9250 (rizando el rizo uno podría crearse su propia tabla de dotclocks para su tarjeta específica). Lo que te sugiero es que cargues la resolución que usas para Higan en Arcade OSD, y desde ahí midas el refresco (botón "5"). Prueba tras ello a desactivar la opción "lock vfreq" para poder modificar el valor de dotclock, en principio usa los valores inmediatamente superior e inferior al que tengas, y realiza de nuevo la medición del refresco. Por último, puedes añadir líneas en blanco al "vertical back porch": esto rebajará el refresco de golpe, lo que te obligará a incrementar el dotclock para compensar y volver al valor original. En muchas ocasiones, tras añadir una o más líneas y compensar el dotclock, el refresco resultante es más exacto que el original (esto es lo que hace la opción "iterations"). Yo, francamente, no me calentaría la cabeza.