Recap, en efecto los gráficos están sobreescalados. En las resoluciones de 24 KHz, como de todas formas hay que usar entrelazado, que degrada significativamente la imagen, lo que hace el programa es generar una resolución virtual mayor que la original, con el refresco correcto, y se aplica hardware stretch. Para mi gusto, el resultado es mejor que manteniendo la resolución nativa, porque se atenúa bastante el parpadeo del entrelazado, a costa de un poco de nitidez. Además corrige la geometría, que en el caso de resoluciones de 24 KHz, al tener menos de 400 líneas obliga a ajustar la amplitud vertical. Esto también se aplica a los juegos verticales en monitor horizontal con resolución mayor de 288x. Ya comentaré más acerca de esto.

He estado haciendo pruebas y he sacado algo en claro acerca del HyperSpin (funciona si reducimos el número a 160 modos). He preparado una versión que soluciona algunos problemas. Mañana cuando tenga un hueco la subiré.

También he revisado los modos que mandó Daicon-X y creo que parte de los problemas de falta de líneas y deformaciones quizá se corrigieran aumentando el VerticalBlank, puede que 1000 sea excesivamente bajo. Los problemas de centrado, existen, y veré si puede hacerse algo al respecto. De todos modos la nueva versión será compatible con Winmodelines, lo que permitirá editar los modos para centrarlos.

Recap escribió:

No sé si puede interesarte lo que yo pueda obtener con mi TV, que parece comportarse de forma bastante distinta a la suya y ser bastante común para estas cosas, pero solo tienes que decirme qué necesitas exactamente y poco a poco...

Parece que el chasis de tu TV es más democrático que el de Daicon-X.

Pues sí, si tuvieras algún modo especialmente problemático sería interesante ver los datos de ese modo en ModeInfo.txt

Tendré que hacer unas pruebas para verificar todos los temas que hemos comentado.

Vaya, tienes razón, olvidaba que le puse una comprobación de versión por seguridad. Habría que editar el registro para que lo aceptase. Te prepararé una versión que sí que se instale en el 1.2. Pero es interesante lo del Hyperspin, creo tendré que revisar los drivers.

Lo de los modos no hace falta que los teclees todos por dios, con unos cuantos ejemplos sobra.

Ante todo muchas gracias por las pruebas, esta información es muy útil. Hubiera querido hacer pruebas yo mismo en una TV pero por desgracia no tengo ninguna a mano.

Por lo que comentas, parece que tu TV tiene algún tipo de ajuste automático del centrado que reacciona diferente en función de si la señal es PAL o NTSC, ¿podría ser? Como PAL/NTSC tienen márgenes distintos (según se ve en Winmodelines) parece que el televisor está preparado para centrar la imagen en ambos casos. Nosotros realmente no estamos creando modos PAL o NTSC, sólo buscamos una resolución y un refresco determinados, y en según que casos quedaremos cerca del estándar PAL/NTSC (50/60 Hz), por lo que la tele lo interpreta así y se ajusta. Como nosotros no tenemos en cuenta estos ajustes generamos los modos todos con los mismos márgenes y por eso los que caen cerca del PAL quedan desplazados... me pregunto si serviría de algo desactivar la opción "auto" que tiene algunas TVs en la entrada AV, para detectar el tipo de señal.

Si tuvieras esa lista con las pruebas que has hecho y los modos correspondientes (archivo ModeInfo.txt), me sería de tremenda utilidad (siempre que no tengas que teclearla a mano, tampoco quiero abusar, con unas cuantas me bastaría). Es para ver si los problemas se deben a algo concreto como frecuencia horizontal alta.

Aquí la cuestión está en ver si tu pantalla puede manejar con normalidad modos de entre 50 y 60 Hz, ¿lo has probado anteriormente con Winmodelines? En caso afirmativo el problema estaría en los modos que genera xml2ini, que por alguna razón no le gustan a tu TV.

Respecto al problema con el modo 640x480, puedes tener razón y que algo ocurra en el registro tras iniciar en Modo VGA. En la última versión del driver restringí todos los modos nativos para tener mayor número de modos personalizados disponibles, tengo que probar si eso puede haber provocado ese problema. Intentaré reproducir el problema y examinar el registro.

En cualquier caso el configurador tambien funciona en la versión 1.2 del driver, sólo hay que tener la precaución de configurarlo para un número máximo de modos de 178. Sería interesante saber si con la versión 1.2 te funciona bien el Hyperspin, incluso tras utilizar el configurador. En tal caso tendría que revisar eso de restringir los modos nativos porque parece que da problemas.

Para retocar las resoluciones que se ven mal, de momento sólo lo puedes hacer manualmente, cogiendo el listado de modos y con Winmodelines sacrificar los modos que se solapan y editar los otros :(

Cuando tenga un hueco actualizaré ResViewer para que permita editar el modeline, y así permitir reajustes (y también eliminaré el tiempo de espera al probar modos ;). También investigaré si es posible sacar los modos en un formato que no genere problemas a Winmodelines.

Te reitero el agradecimiento por tus pruebas.

Saludos

Puedes probar con Mame las resoluciones pero creo que es más directo con el otro método, en fin, como te aclares mejor. Tarda un poco en salir porque calcula el refresco vertical, ya lo cambiaré para que se calcule sólo a petición del usuario y así tarde menos. No pasa nada porque al monitor le llegue una frecuencia no soportada.

Cuando reinicias en modo VGA para rescatar la configuración gráfica, para poder seleccionar las resoluciones mediante quickres hay que entrar previamente en propiedades de pantalla y cambiar la calidad de color a 32 bits, sólo entonces se carga el driver y puedes trastear con las resoluciones. Windows no sobreescribe el registro. Seguramente se te ha quedado activado un modo de 4 bits de color o algo raro. Mira que he hecho miles de pruebas y nunca me ha pasado eso que cuentas, y ya lo del menú de servicio del TV es de poltergeist.

Creo que te estás confundiendo con lo del Hyperspin, el que quickres filtre las resoluciones de 16 bits no significa que no estén disponibles, simplemente no las muestra en el menú por comodidad. Lo que ocurrirá es que Hyperspin lo tienes configurado con una de las antiguas resoluciones de la ArcadeVGA, como 640x288 o alguna de esas extrañas que no tienen sentido y que ya no existen en el nuevo sistema. Prueba a seleccionar una de las casi 200 nuevas resoluciones para ese programa.

Lo normal es que las resoluciones habituales para juegos horizontales se vean bien, lo que ocurre es que el programa trata de generar resoluciones para los juegos verticales rotados, y ahí es donde apura al límite la frecuencia horizontal disponible para sacar el máximo posible de resolución vertical. Esos modos son los que te fallarán. Si utilizas el monitor rotándolo para juegos verticales, como Recap, has de seleccionar la opción MonitorHorizontal = 0, con lo que esas resoluciones rotadas no se generarán y no tendrás problema.

Si tienes la paciencia de probar esos cambios antes de rendirte y volver a la versión anterior te estaré agradecido.

Daicon-X, las resoluciones no las pruebes con Mame, usa el programa ResViewer que adjunté específicamente para esto.

Verás, todas las pruebas están hechas en un monitor CGA, por eso yo he estirado los rangos de frecuencia al máximo de lo que permite mi monitor, dado que cuanta más frecuencia horizontal admita mayor es la resolución vertical que se consigue para un mismo refresco. Esto es fundamental para sacar los juegos verticales de 256 líneas a 60 Hz con el monitor horizontal. Por lo que cuentas, tu TV no se traga esas frecuencias (nada que no estuviera previsto), por tanto tienes que modificar los rangos de frecuencias en xml2ini.ini. Prueba a cambiar HfreqMax a un valor algo menor, por ejemplo:

    HfreqMin = 15.625
    HfreqMax = 16.200

La clave está en ver qué características tienen los modos que no te funcionan, para determinar cuál es la causa, y solucionarla. Sería útil que pegaras los modelines que no te funcionan, y qué problema asociado tienen.

Una forma de conseguir mayor resolución vertical manteniendo la frecuencia horizontal baja es reducir el valor VerticalBlank, dado que seguramente la TV con su circuitería más moderna pueda completar en retorno vertical en menos tiempo que el monitor arcade. Por tanto, te sugiero que reduzcas también este valor.

Entiendo que puede ser un poco frustrante ya que esto no es instalar y listo. Por eso no quería publicar esto prematuramente sin tener una interfaz gráfica que lo haga más intuitivo. Creo que juega en contra nuestra la circuitería de tu TV, que parece un poco quisquillosa. Pero la idea es que gracias a estas pruebas puedan establecerse unas configuraciones válidas para diferentes pantallas.

Respecto a las resoluciones de 16 y 32 bits, siguen existiendo las dos, pero parcheé quickres para que sólo sacara las de 32 bits, ya que el listado duplicado era enorme y poco operativo, además no vi razón para mostrar las de 16 bits. Si no te carga el HyperSpin será porque lo tienes configurado para una resolución que ya no existe, de las antiguas de la ArcadeVGA. Prueba a asignarle una de las nuevas.

Me alegro de que te funcione Daicon-X. Ahora se te habrán generado varios archivos txt con información sobre los modos. En ModeInfo.txt tienes el timing de cada modo. Te sugiero que mires en este archivo los modos que mejor se te adapten a la pantalla, y trates de reproducir la configuración para los demás usando los parámetros correctos en xml2ini.ini. Por desgracia el sistema no está pensado para retocar los modos individualmente, si bien en un futuro se podrá implementar directamente desde el programa ResViewer. La cuestión es que prioricé la obtención de refrescos casi exactos antes que clavar geometría, debido a que contaba con que se utilizarían los potenciómetros o el menú de servicio para el ajuste fino, especialmente para la amplitud vertical, tal como se hacía con las placas y monitores arcade.

Respecto a la pregunta de Recap, en efecto la versión que tienes contiene el mismo fallo, solo que no se ha manifestado porque generas los modos para monitor giratorio, con lo cual resulta un menor número de resoluciones y no se desbordaba en programa al rebasar los 512 modos. Esta tarde actualizaré el pack con el xml2ini corregido.

Vale, acabo de probar con el Mame Plus! XT 0.136 y el programa termina de forma anormal, hay algún fallo, luego os cuento.

Edito: En efecto, había un error en xml2ini.exe, ya que estaba limitado a 512 resoluciones de entrada y con esta versión de Mame salían 524, por eso el programa terminaba sin actualizar nada. Lo siento mucho.

Descárgate de aquí la versión corregida, y sustitúyela por la que tienes.

Qué raro, parece que xml2ini no te está actualizando el registro. ¿Puedes pegar aquí el modeline que tienes para 640x480@60? ¿Has comprobado si al ejecutar xml2ini cambiando los parámetros se modifican los modelines (desde Winmodelines)?

Una prueba que puedes hacer es desinstalar y volver a instalar el driver, que ya debe haberse actualizado con los nuevos modos, de esta forma sí que debería funcionar...

Daicon-X escribió:

Yo recuerdo que por ejemplo, a 640x480@60 poniendo en Winmodelines a la izquierda 5,5 y la derecha 5, reiniciaba y uala, la pantalla comprimida por los laterales.

Entiendo que el programa xml2ini te está actualizando el registro, fíjate si la salida por pantalla de programa es similar a esta:

------------------------------------------------
xml2ini - version 0.1 - por Calamity - 2008/2010
------------------------------------------------
Controlador de video compatible encontrado!

Generando Mame.xml...

Mame v0.129 (Jan  8 2009)

Importando resoluciones de Mame.xml...

Se han encontrado 451 resoluciones diferentes.

Generando modos... se han encontrado 102 modos redundantes.
Reduciendo lista de modos... 153 modos descartados.
Se han generado 196 modelines.

Generando driver...

        1 archivos copiados.

Almacenando modos en registro...

Finalizado. Pulse cualquier tecla...

Por otra parte, debí comentarte que simultáneamente hay que editar los valores de FrontPorchMin y BackPorchMin que representan los valores mínimos aceptables de FrontPorch y BackPorch (el programa tratará de obtener los valores de arriba pero no siempre lo consigue, especialmente en resoluciones bajas, si se queda por debajo de los mínimos entonces incrementa los valores del modeline, pero eso puede ocasionar que nos vayamos muy por encima de lo buscado, por eso se le pone el límite inferior).

Estos valores generan modos equivalentes a los de Winmodelines con márgenes 5,5 y 5 en TV NTSC, prueba con ellos:

    FrontPorch = 4.42
    SyncPulse = 4.7
    BackPorch = 7.94

    FrontPorchMin = 4.30
    SyncPulseMin = 4.2
    BackPorchMin = 7.70

Recap escribió:

Sin duda. ¿La única manera es conociendo las propiedades y verificando en el XML, uno a uno?

Supongo que sí, yo he descubierto unos cuantos por accidente, y es una historia porque al final se acaban generando resoluciones innecesarias.

A ver Daicon-X, el problema es mío porque colgué el programa sin explicar bien cómo funcionaba. Te pido de momento que dejes de lado nuestro querido Winmodelines, que se está enredando el hilo y como ya te he comentado no es compatible con el sistema de etiquetas que usa xml2ini.

El programa xml2ini no sólo configura Mame sino que genera de una tacada y de forma automática los modos que necesitamos, a partir de las resoluciones indicadas en ResList.txt (consolas) y el xml de Mame, que combina en la tabla de modos definitiva.

Los márgenes que se asignan a todos los modos se regulan modificando los parámetros de xml2ini.ini, y ejecutando xml2ini.exe para volver a generar todos los modos. Si tienes overscan puedes empezar por aumentar los márgenes inicial y final (valores FrontPorch = 2.0 y BackPorch = 8.0, por ejemplo), volviendo a ejecutar xml2ini para recalcular todos los modos, y luego reinicias. Así vas jugando con los valores hasta que tengas los óptimos de tu monitor.

Así conseguiras que casi todos te salgan bien, aunque la perfección no es posible dado que los valores de los modelines van a saltos de 8 en 8, y el sistema está pensado para ser ajustado posteriormente con potenciómetros/menú de servicio.

Algo lei sobre el tema creo que en Marcianitos. Entonces qué me recomiendas hacer? elimino la linea del Winmodelines? Es que hasta que no quite las 8 o 9 lineas repetidas no me permite editar las modelines, y claro, al usar un Televisor sin posibilidad de ensanchar/estirar la imagen por el menú estoy sin poder avanzar.

Ahora mismo no sé que hacer -_-

¿Qué le ocurre exactamente a la imagen? ¿Overscan? ¿Descentrado? Sin saberlo no puede sugerirte qué cambios realizar en la configuración.

No debe usarse Winmodelines para editar los modos generados por xml2ini, por los problemas comentados. Además el generador de modos que lleva xml2ini es diferente, los modelines calculados con este programa no deberían editarse luego sino recalcularse con los nuevos márgenes, para garantizar que el refresco vertical no se altera.

La idea es corregir la geometría usando exclusivamente el generador de modos del configurador xm2lini, y no tocar luego los modos. Para ello están los parámetros del timing del monitor del archivo de configuración xml2ini.ini.

Daicon-X escribió:

Entonces que solución le ves? cambiarle el valor que yo quiera? es raro que si viene incluida en los drivers me marque como repetida

Es normal que pase, se solucionaría si Winmodelines tomase las etiquetas del registro y las conservase al actualizar, pero las ignora. Le di muchas vueltas para hacer compatible el etiquetado de los modos con Winmodelines pero sin ese cambio no es posible. El configurador, de momento, no está pensado para que los modos sean editados, sino para generarlos las veces que sea necesario variando los parámetros.

Daicon-X escribió:

Esto sería un ejemplo, el primer error que me indica Winmodelines,

Modeline "256x224_53,7Hz 15,6KHz (54Hz)" 5.110 256 264 288 328 224 248 251 290  -hsync -vsync   
Modeline "256x224_54,0Hz 15,7KHz (54Hz)" 5.150 256 264 288 328 224 249 252 291  -hsync -vsync 

Si elimino el parentesis de la etiqueta Winmodelines ya no me lo reconoce como error, me imagino que tambien funcionara si le cambio el valor por otro , por ejemplo 55. La duda que tengo es si es una simple etiqueta para nosotros, es decir para tener diferenciadas las modelines, y el registro esa etiqueta no la toma en consideración, da igual lo que ponga, lo importante son los otros valores. Perdonad mi ignorancia pero es que todo esto es nuevo para mi.

Sí, es una simple etiqueta para diferenciar los modos, no afecta a la resolución real.

Las etiquetas se solapan por que ambas son 256x224@54. Si quitas el paréntesis, creo recordar que cuando se produce solape, Winmodelines usa para el refresco una etiqueta que esté libre, por ejemplo 55. Como xml2ini la que había etiquetado previamente como 257x224@54, y los .inis hacen referencia a esta etiqueta y no a la otra, entonces habría problemas.

Daicon-X escribió:

osea que si modifico el ini lo puedo arreglar de golpe?.

Sí, cuando encuentres los valores óptimos para tu pantalla todos los modos se generarán con ellos. Dijiste que los márgenes del modo TV NTSC de Winmodelines te iban bien, podrías mirar en las opciones avanzadas de este programa qué márgenes y pones los valores en el archivo xml2ini.ini

Daicon-X escribió:

Bueno, ya tengo los Drivers instalados. He mirado con el Winmodelines los modelines instalados de los drivers y a la hora de modificar la resolucion 640x480 me indica que en el modo 25 hay una etiqueta de refresco duplicada

Winmodelines al actualizar el registro vuelve a renombrar las etiquetas de los modos, entonces se produce el problema de que los modos con refresco muy similar se solapan. El truco que usa el configurador para nombrar esos modos es incrementar sucesivamente la etiqueta de la resolución horizontal, sin modificar la definición interna del modeline, a efectos de que el driver pueda almacenarlos como modos distintos. El problema es que ese etiquetado se pierde al utilizar Winmodelines (sería estupendo que el programa tomase los valores para la etiqueta desde el texto entrecomillado, tal como ya hace con la etiqueta del refresco, así se solucionaría esto).

De momento, para modificar la geometría de los modos puedes probar a modificar los parámetros del timing del monitor en el .ini del configurador. Los valores FrontPorch/FrontPorchMin y BackPorch/BackPorchMin controlan los márgenes inicial y final, puedes incrementarlos o modificarlos para centrar la imagen. Luego vuelves a generar los modos y todos mantendrán en lo posible esos márgenes (aunque no serán exactamente iguales). La idea es no tener que modificar los modos individualmente.

Recap,

Por el listado de modos que has puesto veo que efectivamente lo tienes bien configurado como "monitor giratorio". Con esa opción se activa "ror 1" (rotación a la derecha) para las roms verticales, para la visualización a pantalla completa. Por lo que dices al girar el escritorio, Mame ya rota la imagen, entonces la opción "ror 1" en el .ini de cada rom sobraría, ¿puede ser eso? (habría que ver si suprimiendo "ror 1" se soluciona). En ese caso tendré que añadir una opción al configurador, ya que en principio no conté con que se girase el escritorio, y ciertamente tiene lógica hacerlo.

Cuando tenga algo de tiempo escribiré unas instrucciones más detalladas. El sistema está lejos de ser perfecto. Por ejemplo, hay roms cuya resolución reportada en el xml de Mame es incorrecta y no coincide con la real, entonces el configurador genera y asigna esa resolución incorrecta. Recuerdo que Elaphe comentó en algún lado algo de esto. Estaría bien tener una relación de las roms mal reportadas para poder corregirlas en el configurador.

Saludos!

Dado que veo bastante interés en el tema voy a sacar una primera beta del configurador junto a la nueva versión del driver. De momento y a falta de un enlace definitivo se puede descargar de aquí:

Driver Ati Alternativo 2.0 + Configurador (Beta)

El configurador no está tan pulido como hubiera querido y no tiene interfaz gráfica, aunque para una primera prueba es bastante sencillo de utilizar, siguiendo las instrucciones que he incluido. Luego todo puede configurarse editando el .ini del programa.

Serán muy útiles las pruebas que cada cual pueda hacer, ya que mis recursos en cuanto a monitores para probar son limitados. Todas las pruebas se han realizado en monitores Hantarex 9110, así que estoy especialmente interesado en saber si funciona bien en TVs. En principio, los problemas que menciona Daicon-X deberían poderse solucionar editando los parámetros del timing del monitor que aparecen en el archivo xml2ini.ini del configurador. Además, será interesante saber cuáles son los rangos válidos de frecuencias tanto horizontal como vertical, a la que los diferentes modelos de pantalla son capaces de sincronizar. De esta forma podríamos establecer una lista de configuraciones óptimas para diferentes modelos, que permitieran exprimir las posibilidades de cada uno.

He incluido el programa ResViewer, que realicé para probar cada resolución de forma segura, sin asignarla al escritorio.

He eliminado todas las referencias a la AVGA para evitar problemas a partir de ahora, ya que el proyecto está orientado de forma genérica a las Ati (antiguas).

Espero que funcione y no de muchos problemas.

Saludos,

Calamity

Recap escribió:

Seguro... Muchas gracias. ¿Tienes pensado publicar una versión con algunos modos añadidos?  : )

Por supuesto. Ahora lo que toca es seleccionar los modos que van a ser necesarios, y cuáles pueden ser redundantes, para generar los modelines correspondientes y meterlos en el driver.

Recap escribió:

Me asusta un poco lo de que nunca se tienen valores exactos con esta tarjeta, etc. ¿Sugerirías que siempre que se use MAME y un "modeline" en teoría presente en los "drivers" establecer la opción "Sync. with Monitor Refresh"?

Creo que no es un problema de esta tarjeta en concreto sino más bien de la forma en que trabajan todas las tarjetas vga desde las primeras hasta las actuales. La información que se le pasa a los registros de CRTC se codifica en "caracteres", no en píxels. Estos caracteres tienen 8 píxels de ancho. Esto limita la precisión de las frecuencias resultantes, aunque podemos aproximarnos lo suficiente. Estamos tratando de imitar la salida de vídeo de las placas jamma con un hardware completamente diferente.

En respuesta a tú pregunta, creo que sí, lo mejor sería buscar un modo con un refresco que similar al buscado (con una diferencia de unas décimas de Hz bastaría) y aplicar el Syncrefresh, de todos modos todavía tenemos que experimentar con este tema.

Saludos,

Calamity

Hola, perdón por el retraso en responder...

Recap escribió:

La primera, que te olvidas del "tiempo de recuperación". Si realmente se "dibujaran" las 264 líneas, no habría margen para que el haz de electrones retornara a su posición de inicio para empezar un nuevo muestreo. Dicho de otro modo, lo que llamas "líneas de blanking" (264 - 240) no serían en realidad "líneas", sino "tiempo", que, simplemente, se computa en "líneas" para establecer la velocidad total del CRT, esto es, por mera nomenclatura.

Tienes razón en parte, en efecto el retorno del haz está contabilizado dentro de esas líneas de "blanking", y hay que entenderlas como "tiempo", es decir, sabiendo los milisegundos que tarda el monitor en retornar arriba, traducimos ese tiempo a un número equivalente de líneas. Entonces, de esas 24 líneas, p.e. 3 corresponderían al retorno del haz, y las 21 restantes se repartirían en los márgenes superior e inferior, y estas sí que son líneas reales, que hay que entenderlas como tales, porque el haz en efecto recorre la pantalla, solo que la señal de vídeo está desactivada.

Recap escribió:

La segunda, que no es verdad (diría) que MAME deje 16 líneas negras al ejecutar un juego de 224 líneas. Lo sé porque cuando ejecuto ZSNES (sí, hay una versión para que no te estire la imagen; ya pondré el enlace), que también centra la imagen, esas 16 líneas se hacen MUY evidentes. De todos modos, intentaré comprobar esto un día de éstos, no sea que vaya a tener la culpa el modo de servicio.

¿A qué te refieres con que se hacen muy evidentes? Según entiendo yo, la única forma en que Mame puede dibujar 224 líneas en una pantalla con 240 líneas de resolución, sin estirar la imagen, es dejando 16 líneas negras. Desde el punto de vista del usuario, la única diferencia apreciable que podría existir entre esta solución, y la alternativa de generar un modo de vídeo con 224 líneas reales, es en el nivel de brillo de los márgenes. Si el nivel de brillo está demasiado alto, la parte de los márgenes generada por software (las 16 líneas que deja Mame) se verá ligeramente más clara que el negro real de los márgenes, donde la señal de vídeo está apagada. De hecho esta diferencia es la que se usa para calibrar el nivel de brillo, haciendo que el negro de ambos márgenes coincida. Si el modo tuviera 224 líneas reales, al no haber una parte de los márgenes generada por software, sólo tendríamos un gran margen de un negro uniforme. Espero haberme explicado.

Recap escribió:

Si te decides a ir sacando una versión del "driver" con unos cuantos modos añadidos, házmelo saber. A mí y a alguno más nos va a venir muy bien al menos para muchos meses.

He conseguido superar la limitación del número de modos de vídeo, ahora pueden conseguirse hasta 200, con este número ya podremos empezar a hacer algo más serio. Tenéis la información aquí:

http://www.marcianitos.org/foro/showthread.php?t=14323

Saludos,

Calamity

No sé si te sigo, aquí. Si con "líneas totales" te refieres a las presentadas en pantalla, entonces, según lo que dices, 16 líneas deberían ser negras en un juego de 224. Y esto, mientras que lo noto al ejecutar, por ejemplo, SNES 9 X, con los juegos de, pongamos, CP-S en MAME no se da...

Las líneas totales (que definen la frecuencia vertical) son la suma de las líneas activas + líneas de "blanking". Las líneas de blanking están presentes en todos los crts y generan unos márgenes, arriba y abajo de la imagen. Por ejemplo, el modo 320x240 de la ArcadeVGA usa 240 líneas activas y 24 líneas de blanking. Por tanto las líneas totales son 264. Cuando usamos este modo en Mame para un juego de 320 x 224, el emulador centra las 224 líneas dejando, como dices, 16 líneas negras. El resultado es exactamente el mismo que si generásemos un modo nativo de 320 x 224 para ese juego, ya que, para mantener la misma frecuencia vertical, nos veríamos obligados a transferir esas 16 líneas sobrantes a la zona de blanking, de forma que el total siguiera siendo 264. Es por eso que la ArcadeVGA no viene con modos de 224 líneas.

El problema es que algunos emuladores no saben muy bien que hacer con esas líneas extra. Por ejemplo el Kega Fusion las pinta de un color próximo al del resto pantalla... yo preferiría que las dejase negras. El Zsnes, en cambio, lo que hace es estirar la imagen hasta cubrir todas las líneas, distorsionando la imagen. Puede que exista alguna opción para eliminar estos comportamientos indeseables.

No pretendía quitarle méritos, sino alertar de los deméritos, que parece se olvidan siempre. No tengo nada en contra de él, pero, al contrario de lo que hace gente como tú, él _cobra_ por sus inventos.

Completamente de acuerdo en esto.

El proyecto de incorporar nuevos modos y refrescos en la ArcadeVGA ha sufrido un revés inesperado: resulta que los drivers de Ati limitan el número de modos personalizados a 40. Soluciones... veo pocas y malas. Probablemente hackear el driver... pero no sé si será funcionará. Seguiremos informando.

Saludos,

Calamity

Recap,

Gracias por el apoyo, espero que el proyecto sea viable, aunque aún me quedan bastantes pruebas por hacer. Respecto a tu pregunta, comentarte que el método de los modelines en las ati parece tener una limitación intrínseca en cuanto a la precisión del refresco, dado que el dotclock de la tarjeta se define mediante el registro en valores que son múltiplos de 10KHz, y esto se traduce en un refresco vertical que suele estar 0,1 Hz por encima o por debajo del valor que buscamos. Creo que en esto no podemos afinar más. Sin embargo, tengo la esperanza de que si conseguimos acercarnos lo suficiente a la frecuencia original del juego, al activar el triplebuffer y el syncrefresh, el juego se nos ajustará perfectamente al refresco... Y esa diferencia de unas décimas de Hz creo que no deberían apreciarse...

Saludos

Recap,

Respecto a la posibilidad de añadir modelines a la ArcadeVGA, ya tienes en el foro de Marcianitos una nueva versión de Winmodelines que sí que es capaz de trabajar con la ArcadeVGA.

Por otra parte, he preparado un nuevo driver no oficial para esta tarjeta, mediante el cual y en sucesivas versiones, espero poder incorporar más variedad de resoluciones y refrescos verticales, para que los juegos vayan como dios manda. De momento, el driver instala todas las resoluciones de la ArcadeVGA más una nueva de 384x256x55Hz, específicamente pensada para los R-Type, Dragon Breed, Legend of Hero Tonma...

Saludos,

Calamity