No has iniciado sesión. Por favor, inicia sesión o registrate.
Postback » Hardware del vídeo y emulación avanzada » Driver ATI Alternativo para CRT - Configuración automática para 15 kHz
Yo soy el primer sorprendido pero, como ya te dije, podía probar las resoluciones "conflictivas" con el Arcade_OSD sin problemas y el único emulador que reiniciaba mi equipo era el MAME, con el resto nunca tuve problemas. ¡Estoy encantado!.
He actualizado los paquetes de los drivers, con las nuevas versiones de VMMaker y Arcade_OSD. Espero tener disponible en breve la versión 6.5 para XP-64, que dé soporte a las 9250, ArcadeVGA 9250 y similares para el sistema Windows XP de 64 bits. He movido los archivos definitivamente a megaupload para evitar problemas con mi servidor.
VMMaker viene configurado por defecto para utilizar una tabla de modos dinámica, mediante la opción "ModeTableMethod = 1" en VMMaker.ini. Para volver al funcionamiento anterior, es suficiente con poner esta opción a "0" y volver a generar los modos.
La utilización de tablas de modos dinámicas es la recomendada para GroovyMame:
http://forum.arcadecontrols.com/index.p … c=110905.0
Para ello, desactivaremos además la opción GenerateInis, ya que GroovyMame funciona sin "inis". De esta forma GroovyMame reajustará cada modo de vídeo de forma dinámica justo antes de lanzar el juego, e incluso durante el juego si fuese necesario.
Para versiones convencionales de Mame, utilizaremos una tabla estática de modos de vídeo. Para ello dejaremos activada la opción GenerateInis y usaremos ModeTableMethod = 0. De esta forma se generará, como siempre, una tabla estática de modelines, con sus "inis" asociados a cada juego.
Es importante aclarar que los ajustes posteriores que hagamos con Arcade_OSD sólo seran efectivos si utilizamos el segundo método (tabla estática), dado que con una tabla dinámica los modos de vídeo se recalculan cada vez que lanzamos GroovyMame, por lo que los ajustes que hagamos serán descartados. Por tanto, si nuestro monitor nos exige ajustes mediante Arcade_OSD, es conveniente utilizar el segundo método, al menos por el momento.
También estoy mejorando VMMaker para dar soporte a monitores multifrecuencia, así como dotarlo de una interfaz gráfica que con seguridad facilitará la configuración en gran medida.
El archivo al que está intentando acceder no está dsiponible temporalmente. Por favor, inténtelo de nuevo más tarde.
Excepto en la de 64 bits, esto es lo me dice Megaupload.
¡Y palabra que esta vez me disponía a probarlo...!
Parece que ya están disponibles otra vez, por alguna razón en megaupload suele ocurrir esto con los archivos nuevos, luego parece no dar más problemas.
Por cierto Recap, ¿vas a probar con la HD4550 o seguirás con la ArcadeVGA? Si vas a usar la HD4550, no está de más recordarlo: la salida que tienes que usar es la DVI, mediante un adaptador DVI-VGA, por la VGA no tendrás vídeo en el monitor arcade (no obstante sí que podrás usar un LCD conectado a la salida VGA por si te hace falta durante la instalación de Windows, etc.). Nada más, aparte de usar la versión adecuada del driver, que para la HD4550 es la 9.3, y volver a generar los modos con la opción "ModeTableMethod = 0" y "GenerateInis = 1" una vez instales el driver.
Por cierto Recap, ¿vas a probar con la HD4550 o seguirás con la ArcadeVGA? Si vas a usar la HD4550, no está de más recordarlo: la salida que tienes que usar es la DVI, mediante un adaptador DVI-VGA, por la VGA no tendrás vídeo en el monitor arcade (no obstante sí que podrás usar un LCD conectado a la salida VGA por si te hace falta durante la instalación de Windows, etc.). Nada más, aparte de usar la versión adecuada del driver, que para la HD4550 es la 9.3, y volver a generar los modos con la opción "ModeTableMethod = 0" y "GenerateInis = 1" una vez instales el driver.
Gracias, Calamity. ¿¡Hemos hablado alguna vez sobre el DVI!? ¡No tenía ni idea! De hecho, tenía en mi poder una X-1550 [ > ] --sin conexión VGA-- y compré la HD-4550 pensando que necesitaba sí o sí salida VGA por aquello que hablamos en el interno sobre la desaparición paulatina de la salida VGA... :_(
¿Sabes por casualidad si la X-1550 tiene limitaciones en los valores bajos del 'dotclock', o debería dar el mismo resultado que la HD-4550?
Y a todo esto, ¿por qué no vale el puerto VGA?
Apostaría a que la X1550 tiene limitaciones en cuanto a valores bajos de dotclock, no he probado esta tarjeta pero un usuario probó con la X1950 y efectivamente así era. Al parecer todas las "X" menos las más antiguas (x300, x600, etc.) parecen tener este problema, al menos bajo Windows. No obstante, con la nueva opción en VMMaker "dotclockmin" puede soslayarse este problema, al menos en Mame, duplicando la resolución horizontal (el resultado es indistinguible).
Respecto al DVI, primero hay que determinar si la conexión que tenemos DVI-I o DVI-D (es sencillo mirando el esquema de la conexión):
http://es.wikipedia.org/wiki/Digital_Visual_Interface
Para lo que nos interesa, el DVI-I es equivalente a una conexión VGA, dado que lleva incorporada la señal analógica. La única pega es tener que colocar el adaptador DVI-VGA que puede ser un poco aparatoso si tenemos poco espacio.
Por contra, la conexión DVI-D sólo lleva señal digital, por tanto no podemos conectar un monitor analógico a una de estas salidas.
Cuando hablábamos de la paulatina desaparición de la salida VGA, realmente en propiedad a lo que nos referíamos es a la extinción de la salida analógica (cualquiera que sea el conector utilizado), que cada vez tiene menos sentido con la generalización de las pantallas planas.
Respecto a la validez del puerto VGA, la cosa es interesante, y ha habido que investigar un poco para entender el problema, que sólo se presenta realmente con monitores arcade o TVs. Resulta que durante el inicio, Windows intenta determinar si tenemos monitores conectados a cada una de las salidas. Para ello, mide la resistencia en una de las patillas de la conexión (no puedo dar más detalles técnicos porque no entiendo nada de electrónica) o mejor aún solicita el EDID del monitor:
http://es.wikipedia.org/wiki/EDID
Lo que ocurre es que los monitores arcade no son detectados de este modo: Windows no los 'siente'. Cuando Windows no detecta ningún monitor, su comportamiento por defecto es desactivar todas las salidas menos una: la salida primaria (dispositivo primario).
Pues bien, en las tarjetas antiguas, el dispositivo primario resulta que era la conexión VGA. Por eso nuestros monitores arcade funcionaban bien aun sin ser detectados por Windows, siempre que los conectáramos a la salida VGA.
Pero en las tarjetas nuevas, invirtieron el orden de las salidas, de modo que la salida primaria por defecto es la DVI, y la secundaria la VGA. Por tanto, si arrancamos Windows con el monitor arcade conectado a la salida VGA, éste no será detectado y tendremos una pantalla en negro tras el arranque (el arranque no obstante sí podremos verlo). Esto no significa que la salida VGA no funcione, de hecho si conectamos un monitor de PC a la salida DVI y arrancamos así, podremos activar la salida VGA con un monitor arcade una vez entremos en Windows, pero no podremos mantener esta configuración para posteriores arranques si desenchufamos el monitor de PC (puesto que Windows entonces no detectará nada y volverá al comportamiento por defecto, desactivando la VGA).
Uoh... Empieza esto a tener una dimensión biológica. ¿Se acabará en algún lado? El día que intentemos poner todo en orden en un texto vamos a querer no haber nacido.
A ver si en un ratito este finde compruebo los drivers nuevos. Las salidas DVI de ambas tarjetas son DVI-I, por cierto.
Si alguien quiere una X-1550 PCI-E, la cambio por una Radeon AGP decentita... (Madrid).
(no obstante sí que podrás usar un LCD conectado a la salida VGA por si te hace falta durante la instalación de Windows, etc.)
¿Existe una manera de que NO "te haga falta"? Me doy cuenta de que es la primera vez que afronto el problema, acostumbrado únicamente a Arcade VGA. Estoy con la HD-4550 y no consigo ni ver el arranque sin que pierda enseguida la señal (que, deduzco, va a 480p --o más--). Cabe decir que instalé previamente el XP SP2 con otra gráfica y otro monitor y, aunque no instalé 'drivers', probablemente WIN lo hiciera por mí (...).
No lo pregunto tanto por acercar un monitor VGA para la instalación, sino por los posibles conflictos al tener en una salida el monitor VGA, en otra, la TV a sus 15 kHz. Quiero decir, hasta que instalo tus 'drivers', se usaría el VGA, y justo después, tras reiniciar, ¿ya puedo ('debo') esperar 480i y usar la TV?
¿Has probado esto para arrancar a 15 kHz?:
http://foromarciano.org/foro/thread/92/ … #post94249
¿Qué opinas?
¿No existe, de todos modos una manera más oficial o directa de que el arranque y la BIOS se muestren a 480i, como --imagino-- ocurre al usar la "salida de TV" de la gráfica? No parece sano estar fuera de frecuencia cada vez que arranquemos el equipo con el monitor de 15 kHz encendido...
En tu caso, lo más sencillo sería enchufar el monitor de PC para instalar los drivers parcheados, con la 4550 ya montada en el sistema. Asegúrate de tener el escritorio configurado a 640x480 antes de instalar los drivers, esto no es estrictamente necesario pero te aseguras de que tras instalar y reiniciar ya estarás emitiendo a 15Khz, dado que 640x480 es una de las resoluciones que el driver modifica. Por el contrario, las resoluciones nativas más altas no se modifican inicialmente, por tanto puedes seguir utilizando un monitor de PC a 31 KHz con toda normalidad seleccionando estas resoluciones más altas (de hecho yo tengo los mismos drivers en el ordenador del trabajo, sin ningún problema). No obstante te recomiendo que, una vez instalados los drivers, apagues el ordenardor y enchufes directamente la TV al conector DVI y desconectes el monitor de PC. De esta forma ya deberías tener 15Khz al entrar en Windows.
boot15khz es un proyecto muy interesante, aunque no se actualiza desde hace tiempo y no estoy seguro si funcionará con las tarjetas nuevas. Yo no lo he probado directamente, pero estuve leyendo acerca del tema porque me interesaba mucho hacer algo similar para grub, el menú de arranque de Linux. Me quedé con las ganas de comprobar si boot15Khz podía en efecto arrancar en 15Khz con esta tarjeta (HD4350), pero tras un frustrante experimento con grub, usando, creo yo, la misma técnica que boot15khz, decidí dar por imposible el asunto y vivir con ello (con el arranque en 31Khz, me refiero), algo que de todos modos no es nada preocupante siempre que no se deje demasiado tiempo puesto.
El apaño más sencillo, siempre que usemos conector jamma, es el jpac, que permite ver la imagen doble pero a mitad de frecuencia, pero ni siquiera el jpac da una imagen legible con las nuevas tarjetas (parece que los modos de vídeo de estas tarjetas usan por defecto una frecuencia mayor que en las tarjetas más antiguas).
Gracias, Calamity. ¿A qué llamas "tarjetas nuevas"? ¿A todas las PCI-E?
puedes seguir utilizando un monitor de PC a 31 KHz con toda normalidad seleccionando estas resoluciones más altas (de hecho yo tengo los mismos drivers en el ordenador del trabajo, sin ningún problema).
Interesante... ¿Es lo mismo con una Arcade VGA (AGP)? ¿La dejan tus 'drivers' apta para conectarla a 31 kHz? ¿Y los 'drivers' de Ultimarc, por curiosidad? Me resolvería un problema, en caso afrimativo.
No obstante te recomiendo que, una vez instalados los drivers, apagues el ordenardor y enchufes directamente la TV al conector DVI y desconectes el monitor de PC. De esta forma ya deberías tener 15Khz al entrar en Windows.
En realidad, lo que voy a hacer es trasladar el ordenador de habitación para hacer la instalación con un CRT VGA de 21'' que me acabo de agenciar y no he probado aún. Dos pájaros de un tiro. Así uso la misma salida, si es que importara.
Gracias, Calamity. ¿A qué llamas "tarjetas nuevas"? ¿A todas las PCI-E?
El que sean AGP/PCI-e no es lo relevante aquí sino la generación a la que pertenecen. Por tanto sabemos que la 9250 actúa de una forma (vga dispositivo primario), y las HD actúan al contrario, y entendemos que en un momento cierto pero indeterminado entre las dos familias se produjo el cambio.
Interesante... ¿Es lo mismo con una Arcade VGA (AGP)? ¿La dejan tus 'drivers' apta para conectarla a 31 kHz? ¿Y los 'drivers' de Ultimarc, por curiosidad? Me resolvería un problema, en caso afrimativo.
Resulta que la versión 6.5 (la que soporta la AVGA) restringe todos los modos salvo los de 15 Khz, que es lo mismo que hacían los drivers de Ultimarc. No obstante, puedes añadirle manualmente modelines a 31Khz sin ningún problema, con Winmodelines por ejemplo. En próximas versiones de VMMaker podrá hacerse todo esto de forma más flexible.
Ya tengo la HD-4350 con la última versión de los 'drivers' y la magia vuelve a funcionar... No he hecho nada práctico todavía, ni siquiera ejecutar Arcade OSD, pero los 480i están ahí como tienen que estar. Esto demuestra que no hace falta tener una tarjeta con doble salida para la instalación, por cierto, ni poner XP a 640 x 480 antes de instalarlos (cosa no tan inmediata).
Lo que yo aconsejo una vez instalados los 'drivers' de Calamity y antes de reiniciar ya con el monitor de 15 kHz conectado -- ejecutar Arcade OSD y seleccionar como 'desktop resolution' un modo de 15 kHz (480i). Hay que hacerlo a ciegas porque se irá de frecuencia tras seleccionarlo (y hay que establecer y confirmar), pero probando antes los pasos con un modo de 31 kHz, es muy fácil repetirlos a ciegas, así como cerrar el programa y WIN.
Una errata a corregir en el mensaje de cabecera:
Tarjetas soportadas por la versión 6.5
Debe poner "9.3", la segunda vez.
Y una duda solo tangencialmente relacionada a ver qué opinas, Calamity -- con una Radeon de 128 MB, ¿debería el 'graphics aperture size' del menú del 'chipset' estar a 128 MB? En los dos PC que tengo esto, están a 64, no sé por qué. ¿Y con la HD-4350 de 512 MB?
Estupendo, espero que haya sido fácil. Como irás viendo, esta versión basada en 9.3 sólo admite 120-128 modos. Si utilizas el método clásico con inis, verás que al admitir 128 modos frente a los 200 de la versión 6.5, hay un mayor número resoluciones que tienen que ser desechadas y sustituidas por otras al no caber en la lista. Puedes verlo en el archivo 'DropList.txt'. Normalmente la resolución alternativa seleccionada suele ser más o menos buena, aunque quizá en algún caso particular patine. Si es tu caso y el juego afectado es uno de tus imprescindibles, el procedimiento, como siempre, es poner el sistema como uno de los favoritos en el archivo MameMain.txt y volver a generar los modelines. Esto le dará más prioridad a la hora de la criba. Lógicamente habrá alguna otra que saldrá perdiendo con la operación, aunque con un poco de suerte sea la de un juego de mahjong.
Si llegado el momento consideras insuficiente la lista de modos y echas de menos demasiados, puede que te interese probar GroovyMame y olvidarte definitivamente de los .inis.
Y una duda solo tangencialmente relacionada a ver qué opinas, Calamity -- con una Radeon de 128 MB, ¿debería el 'graphics aperture size' del menú del 'chipset' estar a 128 MB? En los dos PC que tengo esto, están a 64, no sé por qué. ¿Y con la HD-4350 de 512 MB?
Realmente el valor 'aperture size' a lo que hace referencia es al tamaño de una especie de memoria virtual que usa la tarjeta cuando agota su propia ram, y se mapea en la ram normal del sistema. Por tanto, cuanta más ram tenga la tarjeta menos 'aperture size' será necesario. Es decir, que ese valor no ha de coincidir necesariamente con la ram de la gráfica sino que puede ser menor y es lo normal.
Muy fácil; gracias. Lo tienes todo muy bien explicado. La única cosa que echo de menos en el 'manual' es lo de cómo cambiar al modo de tablas estáticas para generar 'modelines', aunque imagino que pretendes orientar el asunto a las tablas dinámicas de forma definitiva (y yo mismo, por supuesto, lo probaré algún día).
Por curiosidad, ¿a qué responden los 'modelines' que se instalan por defecto? ¿Sigue estando vigente lo de añadir 'modelines' vía 'ResList' (que ¿se llama ahora "ReslList"? Da igual, ¿no?) y ejecución posterior de 'VMMaker'? ¿Podría así añadir modos de 31 kHz para la Arcade VGA (AGP), como 640 x 480 a 60 Hz progresivo? ¿El formato debe llevar el valor de refresco vertical deseado para que 'VMMaker' genere el más cercano (el de SFC / Super Nintendo no es 60.000000000 Hz, sino 60.098475521 Hz)?
Y luego queda que hablemos sobre la sincronización. Veo que aconsejas Triple Buffer pero en MAME FX 0.136, por ejemplo, los desajustes sonoros que se producen al desactivar la sincronización del audio son imperceptibles --con lo que yo he probado-- y te permiten olvidarte de Triple Buffering y V-Sync para siempre jamás. Esto es otro hilo; está claro, y también tengo pendiente hablar sobre el resto de emuladores bajo tus 'drivers'. Poco a poco.
Y gracias de nuevo. Sigo impresionándome con todo lo que ya has conseguido tú solo. Y soy difícilmente impresionable.
Muy fácil; gracias. Lo tienes todo muy bien explicado. La única cosa que echo de menos en el 'manual' es lo de cómo cambiar al modo de tablas estáticas para generar 'modelines', aunque imagino que pretendes orientar el asunto a las tablas dinámicas de forma definitiva (y yo mismo, por supuesto, lo probaré algún día).
Cierto, lo añadiré en cuanto pueda.
Por curiosidad, ¿a qué responden los 'modelines' que se instalan por defecto? ¿Sigue estando vigente lo de añadir 'modelines' vía 'ResList' (que ¿se llama ahora "ReslList"? Da igual, ¿no?) y ejecución posterior de 'VMMaker'? ¿Podría así añadir modos de 31 kHz para la Arcade VGA (AGP), como 640 x 480 a 60 Hz progresivo? ¿El formato debe llevar el valor de refresco vertical deseado para que 'VMMaker' genere el más cercano (el de SFC / Super Nintendo no es 60.000000000 Hz, sino 60.098475521 Hz)?
Los modelines que se instalan por defecto son los de la última versión de Mame, "normalizados" a 60 Hz cuando es posible, y calculados con unos valores de compromiso entre monitor arcade estándar y TV. Lo de llevar todos los refrescos a 60Hz es por ajustarlos a un valor estándar, no tiene más relevancia, ya que esa tabla de modos está pensada para ser dinámica, para usar directamente GroovyMame sobre ella, que ajustará el refresco de cada modo de vídeo según el juego. Por eso para usar el sistema clásico hay que recalcular los modos. Es por una cuestión práctica, más que nada, dado que bastantes usuarios de byoac están viniendo aquí a descargar los drivers, y entre que la información está en español y que el asunto de por sí tiene miga, pensé que sería lo más sencillo.
El sistema de añadir modelines desde ReslList sigue vigente, y como dices el refresco se introduce con decimales, es decir que si SNES el de es 60.098475521 (no lo sabía) puedes editar el valor para que lo calcule así. De todos modos difícilmente se conseguirá esa precisión, por la naturaleza granular del dotclock. De momento, el generador de modelines sólo trabaja con un rango fijo de frecuencia horizontal, por tanto eso que dices de añadir modos de 31 Khz no puede hacerse todavía, pero pronto será posible porque ya estoy probando el nuevo sistema para monitores multifrecuencia.
Y luego queda que hablemos sobre la sincronización. Veo que aconsejas Triple Buffer pero en MAME FX 0.136, por ejemplo, los desajustes sonoros que se producen al desactivar la sincronización del audio son imperceptibles --con lo que yo he probado-- y te permiten olvidarte de Triple Buffering y V-Sync para siempre jamás. Esto es otro hilo; está claro, y también tengo pendiente hablar sobre el resto de emuladores bajo tus 'drivers'. Poco a poco.
Éste es un tema central sobre el que me gustaría extenderme más. No lo he hecho porque, como todo esto, está en permanente revisión. Verás, en mi opinión es impensable una emulación que merezca la pena visualmente sin alguna forma de sincronización vertical. La cuestión es que la implementación normal no suele ser la mejor posible y genera problemas adicionales (input lag), especialmente la opción "triplebuffer". Por resumirlo, he sido defensor de "triplebuffer" hasta hace poco, pensando que el problema de input lag era probablemente un mito derivado de otros problemas diferentes (LCDs, USBs, etc.). Además, las opciones tradicionales para sincronización vertical, "waitvsync" y "syncrefresh" estaban rotas desde Mame v0.107 (sólo funcionaban si se activaba "throttle", lo que arruinaba el resultado). El caso es que investigando sobre el código de Mame, en GroovyMame hemos reparado dichas opciones ("waitvsync" y "syncrefresh"), de manera que "triplebuffer", con sus problemas asociados, ya no es necesario para nada, y además, ahora al combinarlas con la opción "multithreading", *creo* que hemos conseguido eliminar o reducir mucho el legendario problema de input lag asociado a la sincronización vertical. De todos modos aclaro que es una cuestión algo subjetiva, y que es más fácil detectarlo con controles tipo spinner, así que invito a quien quiera probarlo y tenga el ojo entrenado.
Discusión sobre el 'v-sync', aquí:
Hilo actualizado:
- Nuevo CRT_EmuDriver 1.2 basado en Catalyst 6.5 para Windows XP64
- Nuevo VideoModeMaker 1.3, con soporte para monitores multifrecuencia (beta).
Fantásticas noticias. Me recupera la antigua A-VGA, personalmente. Aunque tardaré en probarlo...
Hay una cosa, Calamity, que me desconcierta porque no sé si me estoy perdiendo algo -- los drivers solo para 15 kHz --no los "multisynch" en fase beta--, son aptos también para 31 kHz, de alguna manera, ¿verdad? Es decir, hay unos modos --"native" en gris, según Arcade OSD-- que subsisten al menos hasta que no se ejecuta Video Mode Maker --y me suena que están ahí también tras ejecutar el configurador, en mi antigua versión--. La prueba es que, de hecho, pude instalar los drivers en VGA e incluso tras reiniciar, el modo con el que se abrió fue el mismo que tenía previamente.
Esto querría decir --y abro paréntesis-- que es factible, dado que conseguir un [buen] monitor trifrecuencia es prácticamente imposible ya --y hablo por experiencia propia, aunque nunca sabes cuándo el mercado de 2a mano puede darte alguna sorpresa--, que el mismo ordenador pueda destinarse a dos CRT convencionales diferentes (TV RGB - monitor VGA) para sacar el partido debido a los juegos de 31 kHz --emulados pero también títulos para WIN--. Solo hay que seguir el proceso que describí arriba -- cambiar a un modo apto para el monitor de destino (si estás en 31 kHz, a uno de 15 kHz, y viceversa) mediante Arcade OSD, terminar el proceso a ciegas al perder la frecuencia, conectar al monitor de destino.
Lo que me sorprende es que esto pueda hacerse sin recurrir a la versión 'multisynch' de tus 'drivers'.
Otra cosa más -- ¿tienes el ATI Control Panel o algo similar instalado en tu equipo con la HD-4350? Me doy cuenta de que es lo que me permitía, entre otras cosas, cambiar la disposición del monitor con la antigua Arcade VGA, y no sé cómo hacerlo con la tarjeta nueva. ¿Existe un 'panel de control' para ésta que no entre en conflicto con tus 'drivers'? No me atrevo a instalar nada del CD de ATI, y no me acuerdo qué hice para tenerlo en la anterior...
La versión multisync que comentas, realmente hace referencia a la capacidad del generador de modelines VMMaker, para trabajar simultáneamente con varios rangos de frecuencia independientes. Esto es posible a partir de la versión 1.3.
En cuanto a los drivers en sí, son los mismos, es decir que lo que cambia es VMMaker, y si coges la versión 1.3 podrás usarla con los drivers anteriores sin problema. Tendré que aclarar todo este lío de las versiones en algún momento.
La capacidad de usar modos de 31 kHz está siempre presente de forma nativa en los drivers, y de hecho habría que desactivarla a propósito, cosa que ya no hago pese a que hay gente que lo preferiría. Por tanto siempre pueden usarse estos modos si tenemos conectado el monitor adecuado, lo que viene muy bien durante la instalación, etc.
No obtante, estos modos nativos vienen con sus márgenes y timing preestablecidos, por tanto no son muy útiles para la emulación. Lo interesante, y aquí es donde entra VMMaker 1.3, es generar modelines a distintas frecuencias, de forma que puedas disponer simultáneamente de modos a 15, 25 y 31 kHz. Pero estos modos generados por VMMaker, a diferencia de los nativos, aparecen en Arcade_OSD como modos "custom", que pueden ser editados por el usuario.
Lo que sigue no lo he probado, por las limitaciones de espacio y de hardware que tengo. Pero debe de ser perfectamente posible tener dos CRTs conectados simultáneamente, a cada una de las dos salidas VGA/DVI. En principio Mame permite utilizar indistintamente ambos monitores, por lo que podría configurarse para lanzase cada juego al monitor que queramos, activando modelines de 15/25/31 KHz según el caso. Otros emuladores no son tan versátiles y posiblemente haría falta trastear más. La única pega probablemente sea el engorro de activar cada vez la salida del monitor que no tenga EDID, pero éste es otro tema.
Respecto al panel de control, puedes instalarlo sin problemas, simplemente busca el de la versión 9.3 para que no tengas problemas de compatibilidad. Mientras sólo modifiques temas no relativos a las resoluciones personalizadas, no creo que tengas ningún problema. La descarga de la suite de ATI normalmente incluye drivers + CCC, yo lo que hago es ejecutar el archivo y cancelar la instalación. De esa forma en C:\ATI\Support deberían aparecer las carpetas para instalar cada cosa por separado.
Ya somos dos que nos hemos quedado sin monitor multifrecuencia, aunque no pierdo la esperanza.
En tu caso, yo no la perdería, ya que usas cabina. En el mío, necesitaba conseguir uno de esos con carcasa y conectores que tenía Hantarex. Demasiado necesitar. Un buen CRT de PC de 21'' da muy buen servicio, de todos modos, y tiene la ventaja de soportar muchos más modos por arriba.
El lío me lo hice yo solo por no leer y no recordar. Pero quizás sí es buena idea empezar a separar y numerar independientemente, si al final los 'drivers' no cambian.
Claro que la versión 'multisynch' tiene su sentido -- no quise decir que no ¡!. Aunque la verdad es que desconozco los 'modelines' exactos que usan los distintos sistemas de 31 kHz (NAOMI, etc.). Solo por los juegos de 24 kHz ya son necesarios. ¿Me pareció leer que Groovy MAME cambia los modos dinámicamente? Eso sería estupendo, aplicable incluso en 15 kHz únicamente (varios juegos de System 11 cambian de 224p a 448i a menudo, si no recurdo mal). La lástima es que no cuente con interfaz. Intenté probarlo pero lo dejé...
Lo que quería decir es que, si conserva el mero 640 x 480 x 60.00, la montaña de juegos de WIN al menos que se benefician es importantísima, y no necesitas otro PC, solo el monitor. Pero imagino que siempre será mejor usar la versión 'multisynch', claro. De hecho, habría que ir viendo juego por juego lo bien que sincronizan con la frecuencia vertical exacta de la Radeon nativamente -- muchos, particularmente de disparo, tiene opción v-synch. Ya desarrollaremos.
Tengo instalado ya el Catalyst Control Center, que llaman ahora, muchas gracias. Pero el bastardo no está diseñado para 640 x 480, por lo que se hace imposible aceptar cambios. Veremos qué se me ocurre. Quizás sería interesante añadir este tema en las instrucciones generales, aunque sea como apunte -- si se quiere voltear el monitor, no hay otro modo, a fin de cuentas.
Puedes poner una resolución de 512i líneas para el escritorio, yo lo tengo así, viene bien para trastear con menús y demás. No sé si será suficiente. De todos modos me interesa este tema, creo que instalaré el CCC para ver qué modifica exactamente en el registro para rotar el monitor, y quizá pueda implementarlo en Arcade_OSD para facilitar las cosas.
Respecto a GroovyMame, efectivamente permite que el juego cambie de modo de vídeo y regenera el modeline cada vez. Esto es necesario para muchos juegos de Sega (ga2, tantr, etc.) y otros sistemas. Ciertamente no cuenta con interfaz, salvo el menú que viene por defecto en las nuevas versiones de Mame. No obstante los parches podrían trasladarse a otros "mods" de Mame en un futuro. De todos modos me he acostumbrado a usar Mame desde línea de comandos y es una liberación, aunque lógicamente en la recreativa utilizo un frontend (AdvanceMenu).
Con 512 líneas tampoco hay suerte. En todo caso, parece que hay ciertos problemas de entendimiento entre el CCC y tu 'driver', porque al intentar cambiar valores de resolución sale en blanco. El CCC tiene un modo básico de configuración, apto para 480 líneas, que no te permite rotar escritorio por no reconocer la resolución del mismo, incluso en 640 x 480 x 60.00.
¿En qué momento cambia The Revenge of the Death Adder de resolución? ¿Hay otros uegos de System 32 que lo hagan?
¿Crees que el autor implementará una versión con interfaz, si se le pide? Podría convencer al autor de MAME UI 32-FX de que acogiera los parches, de todos modos. Es uno de los que se queja por los problemas de 'v-synch' del MAME oficial.
Con 512 líneas tampoco hay suerte. En todo caso, parece que hay ciertos problemas de entendimiento entre el CCC y tu 'driver', porque al intentar cambiar valores de resolución sale en blanco. El CCC tiene un modo básico de configuración, apto para 480 líneas, que no te permite rotar escritorio por no reconocer la resolución del mismo, incluso en 640 x 480 x 60.00.
Ya veo, pues tendré que comprobar esto (entiendo que estás usando el CCC 9.3).
¿En qué momento cambia The Revenge of the Death Adder de resolución? ¿Hay otros uegos de System 32 que lo hagan?
El juego al arrancar reporta como resolución 416x224, pero justo cuando aparecen las llamas de fondo, entonces es 320x224 y así es durante todo el juego. Esto ocurre con todos los juegos de system32 que he probado. En segac2 tenemos el problema inverso, reportan 256x224 pero el juego cambia a 320x224.
¿Crees que el autor implementará una versión con interfaz, si se le pide? Podría convencer al autor de MAME UI 32-FX de que acogiera los parches, de todos modos. Es uno de los que se queja por los problemas de 'v-synch' del MAME oficial.
No creo que Chris lo haga porque la prioridad es mantener los parches lo más sencillos posibles e independientes de la plataforma para que sirvan en Windows y Linux. Lo ideal sería que otros 'mods' de Mame adoptaran algunos de los parches, por ejemplo la nueva implementación de -syncrefresh y -triplebuffer son parches muy sencillos de portar. La parte más compleja es el generador de modelines, y aun así con algo de esfuerzo podría portarse.
Entiendo que entiendes bien. No he conseguido encontrar la verificación, pero es el del CD que viene con la tarjeta. Y no se parece en nada al ATI Control Panel apto para la Arcade VGA.
Con respecto a los juegos de System 32, si es solo el arranque, no parece que merezca mucho la pena preocuparse por ellos en lo de cambiar dinámicamente el modo. El C-2 de Sega estaba basado en Mega Drive, que, en efecto, contempla esos dos modos. Aunque la mayoría de los juegos emplean 320 x 224, muchos cambian puntualmente a 256 x 224. Ya lo hablaremos al abrir el hilo de la emulación de MD.
Para juegos que cambian de modo de forma más palpable hay que acudir a sistemas más modernos, como ST-V. Cotton 2 / Cotton Boomerang emplea el modo de alta solo para la presentación o los interludios. En System 11 y familia, creo que Strider Hiryu 2 hacía algo similar, y quizás algún Tekken. Lo que pasa es que sospecho que el 'driver' de este sistema está muy cojo en este sentido y les han colocado a todos los juegos el modo de alta en plan genérico sin más.
De todos modos, no es la parte que más me interesa de Groovy MAME personalmente, al contrario que el parche para corregir las opciones de sincronización. ¿Crees que yo mismo --que no tengo ni idea-- podría añadírselo al código de 32-FX, por ejemplo? El autor parece que se ha retirado indefinidamente.
(Una pena que no queráis hacer una interfaz para GM, por cierto. Se me escapa cómo podéis manejaros con línea de comandos. Va a suponer una barrera enorme para el usuario medio.)
Postback » Hardware del vídeo y emulación avanzada » Driver ATI Alternativo para CRT - Configuración automática para 15 kHz
Postback, 2005—2024