[ Cerrado ] Driver ATI Alternativo para CRT - Configuración automática para 15 kHz (Página 4 de 10)

Estupendo. Voy a añadir los enlaces a cada versión de correcta de CCC al post inicial.

La única opción es conocerlo a priori para cada juego, probando uno por uno, y crear un .ini manualmente, y aun así esto no es válido para los juegos que cambian más de una vez de resolución.

Mame nos da una información sobre cada juego en formato xml, usando el comando -listxml, por ejemplo:

mame 1942 -listxml

...nos daría todos los datos relevantes sobre el juego 1942. Esta es la misma información que aparece en MAWS, y que utilizan los frontends o MameUI para decirnos las "propiedades" del juego, y es todo lo que hay disponible a nivel de usuario.

El problema es que esta información es incompleta para los juegos que usan varias resoluciones, dado que la base de datos está diseñada para almacenar un sólo campo de resolución por juego, normalmente la primera que se usa.

Para conocer a priori todas las resoluciones que usa un juego, habría que ir al código fuente del driver de dicho juego y estudiarlo.

Retomando la discusión sobre la versión 'multisynch' -- estaba pensando si es posible generar modos de 512 líneas (como los que usa, por ejemplo, la emulación de X-68000 gracias a tu parche para WIN X68k HS) para un monitor convencional 'VGA'. En teoría, no hay ninguna limitación técnica, ¿verdad? ¿Lo has probado ya, quizás?

Maravilloso. Lo que implica para la emulación de X-68000 es impagable. Definitivamente, hay que intentar darle mayor difusión. Pásate por el subforo de desarrollo y dime qué piensas.

Lo más práctico será implementar un auto-test opcional que pruebe cada valor de dotclock in situ, para generar un archivo análogo al ATI9250.txt para cada tarjeta. La ventaja de esto es que una vez obtenidos los valores, VMMaker puede utilizarlos para obtener los refrescos exactos (para *prever* los refrescos exactos, mejor dicho). La pega es que el auto-test dura unas cuantas horas.

La verdad es que ahora no puedo probar la HD-4350 porque tuve que instalar de nuevo la 9250 para probar los drivers 6.5 para XP-64.

Puedes tratar de ajustar mejor ese modo yendo a "Edit modeline", y dentro desactivar "Vfreq_lock", y probar a subir un punto el valor "Dotclock", luego pulsa P1 para probar el modo y 5 para calcular el nuevo refresco.

Quizá VMMaker no haya obtenido el mejor valor para tu tarjeta, y manualmente lo encuentres (será el inmediatamente superior en todo caso). Verás que con cada valor de dotclock tendrás un salto en el refresco vertical. Esos son los valores que el hardware de tu tarjeta es capaz de obtener. Esta naturaleza granular del dotclock es más evidente en los modos de baja resolución (como 256x224).

Puedes conseguir mejores aproximaciones utilizando la opción "Iterations" de VMMaker. Esto prueba hasta cinco combinaciones con distinto número total de líneas (márgenes, las líneas visibles no varían) y normalmente obtiene valores más aproximados de refresco vertical. La pega es que aumenta la disparidad de valores de frecuencia horizontal, razón por lo que por defecto está desactivado. De todos modos, los valores que utiliza como referencia siguen siendo los de la R9250, por tanto tampoco es garantía de obtener mejores resultados en el caso de la HD4350.

Esto lo que permitiría es que VMMaker generase el refresco más aproximado del que tu tarjeta es capaz. Ahora mismo lo hace para la R9250, por eso digo que está optimizado para esta tarjeta. Eso no significa que la precisión final sea mayor: lo será en algunos casos, en otros será la misma. Lo que quiere decir es que los valores de cálculo que aparecen en ModeList.txt coincidirán prácticamente con los valores reales que midas en Arcade_OSD.

En cualquier caso, si tanteas ahora con Arcade_OSD, quizá obtengas un valor más aproximado. Pues bien, si VMMaker contara con los valores reales de dotclock de la HD4350, llegaría automáticamente al mismo valor que tú sin necesidad de reajuste posterior.

Me refería al caso concreto del modeline para la SFC, que me comentabas que se queda por debajo, por eso decía que el valor óptimo, si no era ése ya, sería como mucho el inmediato superior.

Los modos nativos de 31 KHz del driver siguen siendo funcionales (800x600, 1024x768, etc.), por tanto pueden usarse con un monitor VGA sin necesidad de definir ningún modeline adicional (modo "custom") de 31 Khz.

Para generar modelines a diferentes frecuencias (15/25/31Khz, etc.) lo que hacemos es definir los rangos que soporta nuestro monitor, de esta forma el generador de modelines escogerá el rango óptimo en el que calcular el modeline.

Es decir, que desde ReslList no podemos indicarle al generador que calcule un modeline a 31 Khz, sino que eso lo decide el generador en función de los rangos que definimos para el monitor.

Esto es así por razones prácticas, de todos modos cuando tenga lista la versión con interfaz gráfico quizá sí que sea posible mayor flexibilidad.

Respecto a la cuestión de arriba, Calamity -- para que se creen modos exclusivamente para un monitor VGA (640 x 480 progresivo, etc.), ¿basta con editar esta línea en VMMaker.ini tal que donde dice "CUSTOM" diga "VGA"?:

; Monitor Type. Valid types: D9800, D9400, D9200, EGA, VGA, MULTI, H9110, PAL, NTSC, GENERIC, CUSTOM

    MonitorType = "CUSTOM"

¡!

Esto es lo que Mon-Info me arroja en mi monitor:

¿Es la última línea el 'modeline' patrón? ¿Me interesa crear con ella una línea monitor_specs o me conformo con MonitorType = "VGA" (no parece muy inmediato para mí...).

Es que estaba, por fin, probando esto. Configurando XML2INI para este monitor, me veo aún con dudas. Pongamos que --en tablas estáticas-- voy a ignorar la obtención de 'modelines' desde MAME y generarlos todos desde Reslist manualmente, dado que solo interesan los sistemas de alta resolución, que son pocos. ¿Qué ocurriría si vía Reslist le decimos que cree un 'modeline' que queda fuera de su rango?

Estoy pensando particularmente --y dado que aún no sé realmente el límite inferior del monitor-- en los modos de 24 kHz y las maneras de aproximarnos. Tenemos, por ejemplo, 640 x 400 a 50 Hz que usaban ordenadores como PC88 y FMT. El Mitsubishi parece aceptar 400 líneas horizontales, pero supongo que a 50 Hz queda fuera de rango, ¿qué pasaría si se "generara"?

En un caso así, parece obvio buscar el mínimo valor de la res. vertical que permita el refresco original en nuestro monitor, pero ¿cómo dar con él para generarlo vía Reslist?

¿Debo incluir también en Reslist los modos base de WIN (800 x 600, 1024 x 768, etc.) para que se generen o se crean automáticamente?

Los Minimum resolution values en XML2INI, ¿debo cambiarlos a valores más propios de la alta resolución (pongamos 496 y 400, que son los mínimos de acuerdo a la lista del otro día atendiendo a los 24 kHz)?

Recap,

En efecto esa es la información necesaria. Con esos datos y dejando un poco de margen para no ir muy justos podrías utilizar esta línea:

monitor_specs_0 = "30000-95000, 50-150, 1.000, 1.000, 1.500, 0.011, 0.0491, 0., 0, 0, 1200, 800"

Dependiendo de las circunstancias, el generador de modelines intentará forzar la resolución para que quede dentro de su rango, y si no es posible, la "virtualizará".

Si te fijas en el último valor de la línea que he puesto (800), pues bien, el generador de modos tomará como resolución mínima por defecto ese valor partido por 2, es decir, en este caso 400 líneas.

Por tanto esas resoluciones de 400 líneas a 50 Hz sí que son posibles para ese monitor.

Por debajo de las 400 líneas, el generador intentará escalar la resolución x2, x3, etc. Es decir, que 384 líneas pasarían a ser 768.

Si aun así modificamos el último valor de 800 a 768, entonces sí que intentará generar las 384 líneas sin escalar, pero si al calcular la frecuencia horizontal se queda ésta por debajo de lo permitido, el generador meterá líneas de relleno en los márgenes superior e inferior para compensar.

Asegúrate de utilizar la versión actualizada de VMMaker (es de hoy):

http://www.megaupload.com/?d=HO481JYE

Estaré fuera una semana, a la vuelta podré ver esto con más tiempo.

Saludos

Añado otra pregunta a la lista:

¿No hay que activar ninguna de las opciones del final de Video Mode Maker relativas al 'driver', teniendo en cuenta que uso el 'driver' de la versión 1.2, ya instalado desde un directorio antiguo?

Edito:

Creo que he comprobado que, al menos la de actualizar el Registro, hay que activarla... La de actualizar los archivos del 'driver' también la he activado, aunque no sé muy bien qué conseguimos.

Te voy dejando aquí los primeros resultados con la última versión (valores mínimos: 496 x 400), a ver qué te parecen:

- No me genera el modo 496 x 400 a 57 Hz y pico ni el de 640 x 480 a 50 Hz. Cualquier cosa que baje de ¿768? líneas parece que ha de refrescarse a un mínimo de ~60 Hz, o lo descarta.

- No me genera modos de 512 líneas (los del X-68000), ni siquiera el 640 x 480 a 55,45 Hz.

- Los modos de 384 líneas, tal como pronosticaste, los duplica en la dimensión vertical. Al adoptar 768 líneas, sí que respeta refrescos inferiores a 60 Hz.

- El modo 640 x 480 a 60 Hz, lo clava, según medición de Arcade OSD. Felizmente redondito. Pero solo si uso la línea monitor_specs_0 que me creaste; con "VGA" lo más que se acerca es 59,90.

- Se han perdido totalmente los modos de 800 x 600, 1024 x 768, etc. nativos.

- Finalmente, con la línea monitor_specs_0 que me creaste, la imagen se me desplaza a la izquierda y queda fuera del área visible, sin posibilidad de reintegrarla. Edité el valor "0." de tu línea en "0.524", por si hubiera influido.