101

(34 respuestas, enviadas el English talk)

Nice thread :)

I can't really be objective at all with La Abadía del Crimen after all the time I spent with it, both playing and disassembling it. I can agree with people that complain about its playability to some point, however the game itself is so magnetic that the somewhat twisted controls become a secondary matter.

Here are some of the sketches that Juan Delcán made for the game:

http://computeremuzone.com/fichas/a/BocetosAbadia.pdf

At the time he was studying architecture, which becomes obvious once you have a look at his designs. This is the only videogame he worked at. As far as I now he did his career in USA as creative for the NBC channel.

Recap escribió:

Suena raro, dado el rigor habitual de esta gente. Intentaré enterarme, a ver. ¿Es Groovy MAME para WIN?

Sí, hay ejecutables para Windows y Linux:

http://mario.groovy.org/GroovyMame/

Recap escribió:

La problemática del 'throttle' me era totalmente ajena, la verdad. Y no la acabo de entender. Esa opción sirve para que MAME limite la velocidad de ejecución al 'timer' original y no use todo el rendimiento que nuestra CPU permite, ¿no es cierto?

Exacto.

Recap escribió:

¿Por qué el hecho de desactivarla le hace a MAME ajustarse al 'timer' de la tarjeta de vídeo? ¿Es solo gracias al 'triple buffer'?

Al desactivar 'throttle', Mame corre a todo lo que da la CPU, pero si activamos 'triplebuffer', la sincronización vertical que incorpora esta opción hace que Mame ajuste de nuevo su velocidad al refresco de la tarjeta gráfica.

Recap escribió:

¿Y no hay una manera de que sea sin TB? Y Wait for V-Sych / Synch to Monitor Refresh, ¿deberían funcionar sin 'throttle'?

Tal como está programado en la versión oficial de Mame, no: 'waitvsync y syncrefresh sólo funcionan si simultáneamente activamos 'throttle'. Permíteme Recap que pegue un fragmento del código de Mame donde se ve a las claras que este comportamiento es parte del diseño:

...de osd\windows\ddraw.c

    // sync to VBLANK
    if ((video_config.waitvsync || video_config.syncrefresh) && window->machine().video().throttled() && (!window->fullscreen || dd->back == NULL))
    {
           [--- aquí va el código para esperar el retrazado vertical---]
    }

Basta con eliminar lo que pongo en negrita para devolver el funcionamiento esperable a 'syncrefresh' y 'waitvsync', con o sin 'throttle'. Este es uno de los parches que incorpora GroovyMame.

Recap escribió:

¿Por qué no han arreglado esto oficialmente, de ser así, después de tantas versiones?

Puede que simplemente no lo consideren un problema, y prefieren que quien quiera sincronización vertical elija  la ruta de 'triplebuffer'.

En cuanto tenga tiempo iré ampliando el tema. Por cierto, gracias por el artículo, muy recomendable, y aclara ciertas cuestiones que enlazan con esto.

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).

Gracias por abrir el nuevo hilo, Recap.

Recap escribió:

Es curioso que nunca haya notado hipos o problemas similares con MAME FX 0.136 sin activar T. Buffer o Wait for V-Synch. Vamos, que el Synch to Monitor ['Graphic Card'] Refresh me funciona perfectamente --tan perfectamente como con MAME FX 0.106-- con una generosa variedad de juegos. Creo recordar que Super Contra --a toda pantalla-- me daba algún fallo, pero lo tengo que confirmar.

Hipos, haberlos, haylos.

Por lo que puede deducirse viendo el código de Mame, 'syncrefresh' y 'waitvsync' son exactamente la misma cosa, es decir que es indiferente activar uno u otro.

El problema es que Mame sólo hace caso de estas opciones cuando, simultáneamente, activamos 'throttle' (por eso digo que estan "rotas"). Con la opción 'throttle' se activa, básicamente, un bucle de retardo, que tiene como propósito ajustar la velocidad de la emulación a la original de la placa pcb. Para ello, utiliza el reloj de nuestra cpu.

¡Pero nosotros no queremos que esto sea así! Al contrario, nuestro propósito es programar el reloj de la tarjeta gráfica de manera que sea éste el que temporice la emulación. Si 'throttle' está activo, tendremos, en la práctica, dos relojes tratando de temporizar el juego. Por muy bien que los sincronicemos, siempre habrá una pequeña diferencia entre el periodo de ambos. Podrán caminar al unísono durante bastantes frames, pero al cabo de cierto tiempo, uno no podrá alcanzar al otro, y se perderá un frame por el camino.

El problema es más o menos evidente dependiendo del juego y de si la frecuencia efectiva del modeline que hemos calculado está por encima o por debajo de la buscada. En cualquier caso, el problema existe. Y la forma de solventarlo es desactivando 'throttle'.

Por suerte, al contrario que 'syncrefresh' y 'waitvsync', 'triplebuffer' sí que funciona aunque desactivemos 'throttle'. Con esta configuración, Mame sólo hara caso del reloj de nuestra tarjeta de vídeo, y el resultado es que la velocidad de emulación se ajustará automáticamente a la de nuestra tarjeta, obteniendo scrolles perfectos.

Pero aunque visualmente conseguimos la perfección, por desgracia trasladamos el problema al audio, que sigue tratando de mantener la velocidad original. Si utilizamos modelines bien calculados, normalmente esto no se nota, ya que la diferencia es muy pequeña. Pero no siempre podremos obtener un modeline que reproduzca la velocidad original, debido a la limitación que impone nuestro monitor. El caso típico es el de los juegos verticales rotados, que tengan más de 240 líneas. En este caso el desfase entre el refresco obtenido, y la velocidad original es muy grande, y los problemas con el audio serán muy molestos.

Para solucionar este problema, SailorSat realizó el célebre parche 'soundsync', que incorpora CabMame. Con 'triplebuffer', 'soundsync' y 'nothrottle' tendríamos pues la combinación ganadora.

Pero, desgraciadamente, 'triplebuffer' parece añadir un tercer problema: input lag (retardo en la respuesta de los controles).

Hasta aquí, este es el resumen de la problemática con las versiones existentes de Mame.

Recap escribió:

No sabía que Groovy MAME era obra tuya también (¡!). ¿¡Dónde lo guardas (y lo discutes)!? ¿Se puede usar para la modalidad de 'tablas estáticas'? Si has conseguido devolverle a MAME la forma de sincronizar pre 0.107 (o hacer que Wait for V-Synch no introduzca retardo), sospecho que se va a hacer tremendamente popular en cuanto se corra la voz.

No, no es obra mía, sólo colaboro con algunos de los parches. El creador es Chris Kennedy (bitbytebit), él es el que mantiene el proyecto y programa todo el código. Todo esto ha surgido en los últimos meses alrededor del proyecto Switchres/GroovyArcade/GroovyMame. La información está muy desperdigada principalmente por estos hilos:

http://forum.arcadecontrols.com/index.p … c=107255.0
http://forum.arcadecontrols.com/index.p … c=110905.0
http://forum.arcadecontrols.com/index.p … c=106405.0
http://forum.arcadecontrols.com/index.p … c=107620.0

Luego sigo...

Recap escribió:

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.

Recap escribió:

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.

Recap escribió:

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.

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.

Recap escribió:

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.

Recap escribió:

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.

Recap escribió:

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.

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).

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).

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.

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.

Hitomi_Dyego escribió:
Hitomi_Dyego escribió:

Llevo un tiempo probándolo y tengo un problema de reinicios

El problema aparece al ratito de cargar una rom. El juego se inicia, se ve perfectamente, y en menos de un minuto el ordenador se reinicia. Parece que el tiempo hasta el reinicio depende del juego

Parece que ya está solucionado. Al reinstalar los drivers y ejecutar el VideoModeMaker 1.1 de nuevo no me fijé en que tenía puesto GenerateXML = 0 ; Generar XML de Mame (sólo es necesario hacerlo la primera vez). Fue cambiarlo a 1 y ¡ya no tengo ningún problema!.

De nuevo, muchas gracias Calamity por hacer que podamos disfrutar de nuestra afición en condiciones óptimas.

Me parece extraño que eso haya resuelto el problema, de todos modos me alegro de que te funcione.

En breve me pondré con el último driver que planeo parchear, la versión 6.5 para XP-64.

Tienes razón, he editado el principal.

Respecto a las versiones de Direct-X para X64, pienso que la situación de este sistema es la misma que la de XP32. La única razón para preferirlo es que gestiona mejor el hardware moderno, por ejemplo para usar más de 3GB de memoria. Francamente no sabría decirte a partir de qué generación de micros es recomendable, entiendo que cualquier AMD64 / Intel 64 debería beneficiarse de esta tecnología.

Mi experiencia con este sistema es tan breve como un día, próximamente iré haciendo pruebas con diferentes emuladores para sacar conclusiones. De hecho la versión de Mame que he estado probando es la de 32 bits. Se dice que la versión de 64 bits de Mame tiene un salto importante en cuanto a rendimiento. El resto de programas de 32 bits que he ido probando no daban problemas.

También quisiera comentar que la versión de VMMaker y Arcade_OSD que traen estos drivers es nueva (1.2), en cuanto tenga un momento actualizaré los paquetes de los otros drivers. Estoy traduciendo la documentación a inglés, para darle más difusión.

Me encuentro en el dilema de mantener la preconfiguración actual de los drivers, orientada a tablas de modos de vídeo estáticas, y configuración de juegos mediante inis, o hacerlo como en el nuevo paquete que he subido, donde se ha preconfigurado directamente con una tabla de modos dinámica (es decir, que para su correcto funcionamiento necesita utilizarse junto con Switchres / GroovyMame). Realmente la cuestión está en cómo redactar la documentación, si haciendo énfasis en un método u otro, dado que el driver es el mismo y sólo es necesario cambiar la opción ModeTableMethod y GenerateInis de VMMaker para que opere de cualquiera de las dos maneras.

De hecho estoy pensando que quizá sería conveniente que abriera un hilo nuevo sobre Switchres / GroovyMame, dado que me parece que va a ser el método definitivo, al menos para Mame.

Actualizo el post principal para colgar la nueva versión de prueba de CRT_Emudriver 1.2 basada en Catalyst 9.3 para Windows x64 (XP64). En esta ocasión hemos conseguido que el driver acepte hasta 127 modos personalizados. Si supera las pruebas de estabilidad, proximamente intentaremos parchear Catalyst 6.5 para XP64, para dar soporte a las 9250 y similares.

Parece que Windows x64 puede ser el sistema operativo más adecuado para la emulación a medio plazo. Es totalmente compatible con los métodos habituales de modos de vídeo personalizados que usamos en XP32, y a la vez permite aprovechar el hardware actual.

Hola Daicon-X,

La versión basada en Catalyst 9.3 que hay colgada debería de funcionar bien con la HD 4850, aunque no la he probado será similar en funcionamiento a la HD 4350 aunque mucho más potente. Ten en cuenta que estos drivers son para XP 32bits. Dado que mucha gente se está moviendo a XP 64bits, tengo pensado parchear también los drivers para este sistema, aunque en este caso va a ser bastante más difícil y no sé si conseguiré que funcione. Respecto a Windows 7, creo que este sistema va a ser impracticable a medio plazo y no intentaré nada para él.

Vaderman,

Me alegro de que funcione, espero poder seguir añadiendo mejoras en cuanto tenga algo de tiempo.

Vaderman,

Me temo que tu HD 3650 es sólo parcialmente compatible: es una de las que no admite valores de "dotclock" bajos. La mejor referencia que tenemos es el hilo de tarjetas gráficas compatibles con Soft-15Khz:

http://community.arcadeinfo.de/showthre … #post95668

Ahí aparece una tarjeta muy similar a la tuya, la HD 3450, con la nota de que sólo admite valores de dotclock por encima de 7.12 MHz, lo que coincide exactamente con lo que observas. El dotclock (o pixelclock) es el número de puntos por segundo que arroja la tarjeta en un determinado modo de vídeo. Por ejemplo, si coges estos dos modelines:

Modeline "320x240@60.0Hz 15.7KHz (60Hz)" 6.640 320 336 368 424 240 241 244 261 -hsync -vsync
Modeline "352x240@60.1Hz 15.7KHz (60Hz)" 7.390 352 368 408 472 240 241 244 261 -hsync -vsync

... el primero tiene un dotclock de 6.64 MHz (el primer valor del modeline), y el segundo de 7.39 MHz. En la HD 3450, sólo funcionaría el segundo, que tiene un dotclock mayor que 7.12 MHz.

Puedes conseguir forzar algunos modelines para aumentar el dotclok aun manteniendo la resolución. El truco está en incrementar el tamaño de los márgenes. La desventaja es que la imagen resultante quedará algo encogida. Por tanto, cuanto menor sea la resolución, más márgenes tendrás que añadirle, hasta que llegue un punto que no sea aceptable. Puedes utilizar Arcade_OSD para hacerlo. Selecciona un modo que no te funcione, por ejemplo 320x240. En vez de entrar con P1, entra con P2, para editar el modo sin activarlo a pantalla completa. Entra en Horizontal geometry/H back porch, y aumenta ese valor. Eso aumentará el margen izquierdo (luego podrás centrar la imagen con H center). Para probar los cambios hay que pulsar P1, pero no lo hagas hasta que veas que el valor dotclock está por encima de 7.12 MHz. Cuando tengas el modo ajustado, sal al menú anterior y graba los cambios. Si tu TV acepta subir la frecuencia horizontal un poco (creo que la Sony lo admite) puedes probar a aumentar los márgenes verticales en vez o además de los horizontales. En caso de que actives un modo que no sincronice, puedes salir pulsando ESC o simplemente P2 para salir del modo a pantalla completa sin dejar el menú actual.

Este problema con los dotclocks bajos no sé si se debe a una limitación real del hardware o más bien está forzado por los drivers. La cuestión es interesante, porque en Linux tenemos el código fuente de los drivers que vienen directamente de AMD, y parece que en efecto, según la tarjeta, se utilizan unos límites inferiores para el dotclock u otros, y parece que esto se pueda cambiar. Si resulta ser un problema del software, entonces sería teóricamente posible desbloquear estas tarjetas para las resoluciones inferiores, parcheando los drivers, aunque para eso tendríamos que tener claro cómo funciona el asunto, probablemente probándolo antes en Linux (para este fin puede ser útil una de las distribuciones que se descargan aquí: http://groovyarcade.sourceforge.net/). Aún así, encontrar el la parte a parchear en Catalyst sería como buscar una aguja en un pajar.

Entiendo que ya estás manejando sin problemas las opciones de rotación de monitor dentro de VMMaker.ini y lo que quieres es cambiar la orientación del propio escritorio. Para esto sí que es necesario que instales el panel de control de ATI y lo hagas desde ahí, y aunque no soy partidario de mezclar dicho panel de control ya que podría interferir con los ajustes que hace el propio VMMaker, es cierto que para acceder a funciones como esa sí que es necesario. Tienes que instalar la versión correcta que coincida con el driver que tienes, por eso te daría problemas la que instalaste, que es más antigua. Busca pues en la web de ATI la versión que viene con Catalyst 6.5 o 9.3, según la versión de CRT_Emudriver que has instalado.

He actualizado el primer mensaje con la nueva versión basada en Catalyst 9.3.

Este fabricante sí que la monta con puerto AGP:

http://www.hisdigital.com/un/product2-498.shtml

En cualquier caso, podemos actualizar la máquina, pero si queremos sacar partido a las funciones que comentaba, tenemos que quedarnos con el viejo Windows XP de 32 bits, al menos por ahora. Personalmente esto no me supone problema alguno, pero quizá lo sea para quien pretenda ejecutar programas de última generación o aprovechar las cpus de 64 bits. Además hay que tener en cuenta que la última versión de DirectX que soportará Windows XP es la 9.0c:

http://msdn.microsoft.com/en-us/library … Windows_XP

Por tanto, todas aquellas funciones que vayan apareciendo en las nuevas versiones de DirectX quedarían, en principio, fuera de nuestro alcance en Windows XP. Es la historia de siempre, cuando los sistemas empiezan a estar realmente maduros para hacer cosas interesantes con ellos, ya han sido desplazados por las nuevas versiones.

En efecto la tarjeta que estoy probando es PCI-E, en una placa relativamente reciente, de todos modos hay versiones AGP de estas tarjetas, aunque no sé por cuánto tiempo. Y, en cualquier caso, esto es algo que no influye en absoluto para la funcionalidad que buscamos ni para las utilidades con las que trabajamos, dado que el driver es genérico para ambos sistemas.

Quisiera actualizar brevemente el hilo para comentar algunas novedades que creo que pueden ser de interés. Recientemente hemos hablado de la necesidad de migrar hacia hardware más moderno que nos permita montar equipos aceptablemente potentes destinados a emulación. Llevaba tiempo queriendo experimentar con la última generación de tarjetas ATI que hasta el momento ha soportado plenamente los monitores arcade, esto es, la familia ATI HD4000, dado que gracias a SailorSat, autor de Soft-15KHz, sabemos que a partir de las HD5000 no se ha conseguido la compatibilidad con monitores arcade (o en general aquellos que no tienen EDID) por los procedimientos habituales. En este momento estoy haciendo pruebas con la tarjeta HD4350 y una nueva versión de los drivers basada en Catalyst 9.3, que he parcheado para resolver los problemas habituales, básicamente la limitación de 60 modos personalizados y el problema tradicional de doublescan forzado para los modos 320x y 400x. Ahora mismo dispongo de una versión plenamente funcional, que espero colgar en cuanto tenga listos ciertos cambios en VMMaker para trabajar con el nuevo sistema de "etiquetado" de modos que se hace necesario en esta nueva versión. No obstante he de decir que esta vez nos quedamos lejos de obtener los 200 modos que soportaba la versión basada en Catalyst 6.5, y debemos conformarnos con una cifra más modesta, en torno a 134-137 modos. De todos modos, veremos que esto no será un problema en el futuro próximo, como explicaré después.

Como Recap sabe, llevo tiempo pensando en una nueva forma de trabajar con modos de vídeo, para prescindir, al menos parcialmente, de tablas de modos precalculadas y generar los modelines de forma dinámica y transparente al usuario. Hasta ahora, los programas utilizados para instalar modelines (Soft15Khz, Winmodelines, o VMMaker) necesitan reiniciar el sistema para que los cambios sean efectivos. No obstante, es posible, al menos para las tarjetas ATI, modificar los datos de un modo concreto, de manera que los cambios sean efectivos instantáneamente, sin reiniciar el equipo, siempre (ojo), que el modo original ya se encontrara instalado en el equipo con anterioridad. Por ejemplo, si instalamos un modo genérico con resolución 320x240, podríamos modificarlo posteriormente para cubrir toda la casuística de refrescos verticales que podamos necesitar asociados a esa resolución, ajustando el modo 320x240 al refresco deseado justo antes de ejecutar el emulador, sin necesidad de reinciar el equipo. Una demostración práctica de esa propiedad ya está incluida en el programa Arcade_OSD. De hecho, el centrado y edición dinámica de modos es justo eso: nos permite ver los cambios en el modo en tiempo real. Esta propiedad no parece estar documentada en ninguna parte, por ello decidí introducirla con prudencia hasta comprobar que efectivamente funciona de forma estable, dado que era algo demasiado bueno como para darle bombo y que quedara en un fiasco. En este momento estoy haciendo pruebas con la modificación dinámica de modos tanto en Catalyst 6.5 como en 9.3, y parece funcionar sin problemas en ambos, por lo que de momento quedarían cubiertas tanto las Radeon antiguas como las nuevas (hasta la familia HD4000 incluida). Así que ha llegado la hora de explotar esta propiedad hasta sus últimas consecuencias.

La nueva versión del driver que dará cobertura a las nuevas Radeon permitirá, como decía, un máximo de 134 modos. No obstante, en el momento en que se aplique la nueva técnica dinámica, ese número de modos debe ser más que suficiente, ya que cada uno de los modos o resoluciones de base permitirá a su vez generar innumerables refrescos. Para sacar partido de dicha técnica, será necesario utilizar una especie de cargador de emuladores, un pequeño programa que prepare el modo de vídeo que vamos a usar justo antes de lanzar el emulador.

En este momento estoy colaborando con Chris Kennedy, en el foro BYOAC, en el desarrollo de Switchres, un programa que cumplirá esta función y otras muchas. En el desarrollo se han integrado las funciones y métodos para cálculo de modelines que utilizo en VMMaker, generalizándolas para varios rangos de frecuencia, para dar cobertura también a monitores multifrecuencia. En concreto, hemos probado con el WG D9800, que sin entrar a juzgar la calidad de su electrónica, al menos en cuanto a funcionalidad sí que parece que podría ser el monitor definitivo para emulación que alguna vez hemos postulado. El hilo en cuestión es este:

http://forum.arcadecontrols.com/index.p … c=106405.0

No obstante, el grueso del proyecto es la adaptación del sistema Linux para dar soporte a monitores arcade. De forma que Switchres sería una aplicación utilizable en ambas plataformas. El interés del sistema Linux reside en que, al tener disponible el código que accede al hardware de vídeo, en principio y con tiempo parece posible realizar cualquier cosa imaginable. De hecho el soporte para modos dinámicos que se conseguirá en Linux, una vez resueltos los problemas existentes, será genuinamente dinámico, a diferencia de Windows, donde tendremos que mantener una tabla de modos sobre la que actuar. Si bien el manejo de este sistema está fuera del alcance del usuario medio de Windows, la idea por el momento es obtener una distribución live-CD, de forma que cualquiera pueda probarlo simplemente arrancando desde un CD. En cualquier caso, el desarrollo conjunto aportará información y mejoras para ambos sistemas.

Como dice Recap, intentaría confirmar que el problema sólo ocurre en Mame, incluso probaría con alguna otra versión de Mame, preferiblemente una más antigua, por descartar que el problema sea del emulador.

También sería interesante comprobar que Direct3D está funcionando correctamente. Para eso ejecutas "dxdiag", y en la pestaña "Pantalla", en el cuadro "Características de DirectX", compruebas que todo está habilitado. Si no es así, puede deberse a un problema en la instalación del driver de vídeo.

Y lo más importante, lo primero que comprobaría es la temperatura de la CPU, más si es un barebone. Justo cuando se te reinicie pulsa la tecla que toque para entrar en la BIOS y comprueba la temperatura. Si se calienta el micro no mires más.

Espero que puedas solucionarlo.

Hitomi_Dyego escribió:

Me acabo de dar cuenta que mi tarjeta es PCI...

¿Es una 9250 PCI?

Hitomi_Dyego escribió:

De todas formas he hecho las pruebas y le da lo mismo 60 que 200, se reinicia sin cesar. Lo que parece funcionar es pasar el VMMaker e inmediatamente despues iniciar el Mame. Lo he probado durante un rato y ha funcionado sin problemas.

Es raro esto que dices, el VMMaker sólo almacena unas claves en el registro, no hace nada más, no debería influir.