Nueva versión de WinModelines

Hola Jeroni. No las he revisado, pero las especificaciones de vídeo que vienen en el enlace que has puesto supongo que serán las mismas que éstas. Sobre lo de que la resolución horizontal sea múltiplo de ocho recuerdo que viene algo al respecto en el XFree86 Video Timings HOWTO (aquí). Copio y pego:

You need to round this figure to the nearest multiple of 8. This has to do with the VGA hardware controller used by SVGA and S3 cards; it uses an 8-bit register, left-shifted 3 bits, for what's really an 11-bit quantity. Other card types such as ATI 8514/A may not have this requirement, but we don't know and the correction can't hurt.

Por motivos logísticos todavía no he probado la nueva versión del WinModelines (más adelante te comento). No tengo monitor arcade, así que en este punto no puedo aportar mucho. Yo uso una TV muy antigua que no tiene modo de servicio. Hace bastante tiempo estuve ajustando los modos instalados por el Soft15, que si no recuerdo mal, son los que trae la ArcadeVGA. Pues bien, lo que me ocurría es que la imagen era estrecha y estaba algo desplazada hacia la izquierda. Para ensancharla traté de reducir los pórticos todo lo posible, pero el efecto era mínimo. Al final conseguí ensanchar la imagen reduciendo la frecuencia horizontal. Aunque no sé mucho del tema, esto tiene bastante lógica: si la velocidad del rayo es constante (es decir, no varía al cambiar de frecuencia), aumentando el periodo de línea aumenta también su longitud. Vamos, que sucede lo mismo que con el tamaño vertical. Supongo que la tele, siendo PAL, está ajustada para 15625 kHz y dado que los modos arcade son de mayor frecuencia (en algunos modos de la AVGA creo recordar que era bastante más de 15720 kHz, que supuestamente es el estándar) por eso me salía una imagen estrecha. No sé si las teles modernas disponen de algún ajuste automático de la anchura en función de la frecuencia, tal como parece que hacen los monitores de PC multisync. Y bueno, ignoro completamente lo que ocurre con los monitores arcade.

La versión anterior del WinModelines la probé en el PC de sobremesa, aunque no hice mucho más que comprobar que funcionaba. Te cuento... Dispongo de dos tarjetas ATI: una Radeon X300 de marca MSI en el PC y una Radeon Mobility 7500 en el portátil (un IBM Thinkpad T30). La cuestión es que en ambos casos usando el driver OEM (el driver suministrado por el fabricante; MSI e IBM respectivamente) el WinModelines no lo reconoce y muestra el mensaje de driver no soportado. Con la X300, si uso el driver descargado de la web de ATI el WinModelines lo reconoce sin problemas. Intenté probar lo mismo con el portátil, pero ATI ya no da soporte a la Mobility 7500 y no fui capaz de encontrar el driver apropiado. Los drivers del fabricante son el mismo de ATI, supongo que con ligeras modificaciones. Dichas modificaciones no creo que afecten al tema de los modos, al menos el Soft15 me funcionó bien con ellos. Las claves del registro correspondientes a ambos son las siguientes: X300.txt y Mobility7500.txt. Te comento todo esto por si ves que sería factible hacer más genérica la detección del driver, de manera que incluya a las versiones OEM. Claro, no sé si habrá este problema con todas las OEM, a lo mejor no.

Saludos.

Hola zektor

Los múltiplos de 8 me suponia eso, porque ajustando los valores la imagen se desplaza de 8 en 8 píxeles. Al grabar el modo no es necesario hacer el número múltiplo de 8 porque ya lo hace el driver cuando usa el modo, supongo que simplemente ignora los 3 bits menos significativos, pero lo que haré es forzar a que el valor mínimo sea 8 para que nunca lea 0.

Lo que comentas del tamaño es correcto, cuando más alta la frecuencia, más estrecha la imagen, siempre que el aparato no tenga alguna medida correctiva. El tamaño máximo dada una frecuencia es con el Márgen inicial a cero y el Márgen final el tiempo justo para que el haz vuelva al principio. Pero en una TV pueden aparecer problemas con esta configuración porque lo normal es que midan el nivel de negro durante los márgenes que indica la norma CCIR para compensar pérdidas y si hay vídeo, tomará un nivel de negro incorrecto y se oscurecerá el resto de la línea.

Lo bueno del generador de modos es que no nos tenemos que preocupar de estas cosas, porque siempre genera el modo que queremos con los tiempos correctos para el dispositivo y además todos los modos generados deberían tener los mismos, es decir se acabó eso de reajustar potenciómetros para cada modo.

Y referente a la detección de drivers OEM, no los detecta porque el valor ReleaseVersion no acaba en "-ATI". Todos los drivers de ATI acaban así, pero esas versiones OEM lo han cambiado por "-MSI" y en el otro lo han quitado. Supongo que si elimino esta validación no habrá problemas, a lo peor detectará driver ATI cuando no lo es :P

Saludos!

Muchas gracias, Jeroni. Entonces ya sé cual es la solución en mi caso concreto. Probé sustituyendo "-MSI" por "-ATI" en esa variable del registro y ¡funciona! . Mañana pruebo lo mismo con el portátil (ahora no lo tengo conmigo). Supongo que también funcionará. Lo cual sería genial porque lógicamente me resulta mucho más cómodo conectar a la tele el portátil que el PC. Sobre lo de modificar la detección del driver para hacerla más flexible, pues si es a costa de que sea menos fiable supongo que igual no compensa, no sé. Mañana edito este post para comentar lo del portátil .

Saludos y muchas gracias de nuevo.

Edito:

Ayer hice la prueba con el portátil. Añadí "-ATI" a la clave del registro y también funcionó . No dispuse de tiempo para mucho más. Por probar, instalé el modo de vídeo PAL que viene en el documento de modos, reinicié, puse un vídeo VOB PAL que tenía y... el vídeo se veía perfecto!!! . Y si digo esto es porque anteriormente solía usar un modo de 800x600 y en el reproductor de vídeo, el VLC, tenía que activar el desentrelazado porque si no se veía fatal (supongo que podía ser el efecto de escalar un vídeo entrelazado). En fin, una gozada. El WinModelines es una maravilla, pero es que el documento que lo acompaña no lo es menos. Un trabajo excelente, Jeroni .

Saludos.

Jeroni, perdona por la tardanza, he estado haciendo multitud de pruebas, te comento lo que he podido ver:

- Efectivamente, el driver virtualiza el modo cuando el margen inicial es insuficiente. Como han de ser múltiplos de 8, la diferencia mínima para que el margen inicial exista ha de ser 8. El único valor (horizontal) que no estoy seguro si ha de ser múltiplo de 8 es el total horizontal. Sería deseable que no tuviera esta restricción, porque eso limita mucho la precisión a la hora de ajustar el refresco vertical.
- Si genero el modo como comentabas (monitor arcade standard), le resto la longitud de pulso al margen inferior y le sumo 7 a los valores correctos del modeline, obtengo un modo que funciona bien, sin virtualización, pero que no cabe en la pantalla, por mucho que corrija los potenciómetros.
- Para obtener un modo que quepa en la pantalla, la suma del margen inicial + longitud de pulso + margen final ha de rondar los 14 us (13,5 para arriba). Esto contradice las especificaciones del manual de Hantarex, donde habla de un blanking horizontal de 12 us.
- En las especificaciones de Atari, el vertical delay es 11,9, que coincidiría con el manual de Hantarex. Esos datos de Atari chirrían un poco, porque si bien para la resolución estándar se cumple que 63,6 = 46,9 + 11,9 + 4,7, los datos para la resolución extendida no cuadran: 60,6 < 48,0 + 11,9 + 3,9. Así que yo no tengo claro si el sync pulse hay que incluirlo en el vertical delay o no.
- Los datos de Atari puede que contengan algún error, y aparecen copiados una y otra vez por internet. En esta página http://kirurg.org/emame/arcadetiming/ , el autor sugiere que posiblemente vertical delay = sync pulse + margen final. Eso se correspondería con lo que he observado en las pruebas con el monitor Hantarex, en donde los modos de la ArcadeVGA (que entran en la pantalla y quedan centrados) tienen una proporción entre margen inicial - long. pulso - margen final entorno a 2,0 - 5,0 - 7,0 a 2,5 - 4,7 - 6,8. Si bien he comprobado que mientras mantengamos la suma de estos tres valores entorno a 14, podemos bajar la longitud de pulso hasta 2,5, aunque no puedo garantizar que esto funcione en otros monitores.
- Nuevo jarro de agua fría: he encontrado el límite para el número de modos de vídeo personalizados que permite el driver. En la versión 4.3 (drivers ArcadeVGA) el número máximo de modos que podemos definir es de 40. En versiones posteriores del driver, dicho límite se incrementa solamente hasta 60 modos. Lo que cuenta no es el número de claves DALNonStandardModesBCD sino la suma total de modos que se definan en ellas. Esto es una gradísima putada ya que frustra en gran medida nuestro empeño por generar todos los modos y refrescos necesarios para el Mame y resto de emuladores. La única solución que se me ocurre pasa por hackear el driver.
- Tal como comentáis más arriba, los drivers que traen los ordenadores Dell también modifican la clave ReleaseVersión, en este caso cambian -ATI por -Dell. Deshaciendo el cambio se consigue hacer funcionar Winmodelines.

Espero que te sea útil.

Saludos!

Calamity

Originalmente publicado por Jeroni Paul

Lo que comentas del tamaño es correcto, cuando más alta la frecuencia, más estrecha la imagen, siempre que el aparato no tenga alguna medida correctiva.

Por cierto, cuando he estado viendo todo esto, hay una duda que no he podido aclarar: ¿varía la duración del blanking horizontal en función de la frecuencia horizontal?

Por lo que he entendido la velocidad del haz es constante, y para aumentar la frecuencia horizontal (que quepan más líneas horizontales por segundo), lo que hacemos es estrechar el recorrido horizontal que describe éste por la pantalla, de ahí que se estreche la imagen al aumentar la frecuencia ¿Estoy en lo cierto?

En ese caso, el retorno del haz también sería más corto al aumentar la frecuencia. ¿No debería entonces acortarse el blanking horizontal proporcionalmente, aunque sea poco? ¿O debe mantenerse constante, por ser un valor fijo?

Saludos,

Calamity

Originalmente publicado por Calamity

- Efectivamente, el driver virtualiza el modo cuando el margen inicial es insuficiente. Como han de ser múltiplos de 8, la diferencia mínima para que el margen inicial exista ha de ser 8. El único valor (horizontal) que no estoy seguro si ha de ser múltiplo de 8 es el total horizontal. Sería deseable que no tuviera esta restricción, porque eso limita mucho la precisión a la hora de ajustar el refresco vertical.

OK, entonces pondré el mínimo de 8 píxeles.

Originalmente publicado por Calamity

- Si genero el modo como comentabas (monitor arcade standard), le resto la longitud de pulso al margen inferior y le sumo 7 a los valores correctos del modeline, obtengo un modo que funciona bien, sin virtualización, pero que no cabe en la pantalla, por mucho que corrija los potenciómetros.

Hmmm... Vale, por lo que comentas el retorno en estos monitores es realmente lento, así parece que los valores que ya tenía eran más buenos que estos otros.

Originalmente publicado por Calamity

- Para obtener un modo que quepa en la pantalla, la suma del margen inicial + longitud de pulso + margen final ha de rondar los 14 us (13,5 para arriba).

Entonces los valores que tiene el winmodelines son buenos: 0 + 4.7 + 11.9 = 16.6.

Originalmente publicado por Calamity

Esto contradice las especificaciones del manual de Hantarex, donde habla de un blanking horizontal de 12 us.

No he leído el manual pero si no da más datos como otros que he visto, estamos en las mismas: ¿incluye este tiempo el tiempo de pulso o no?

Originalmente publicado por Calamity

- En las especificaciones de Atari, el vertical delay es 11,9, que coincidiría con el manual de Hantarex. Esos datos de Atari chirrían un poco, porque si bien para la resolución estándar se cumple que 63,6 = 46,9 + 11,9 + 4,7, los datos para la resolución extendida no cuadran: 60,6 < 48,0 + 11,9 + 3,9. Así que yo no tengo claro si el sync pulse hay que incluirlo en el vertical delay o no.

La idea es que la resolución extendida no es para monitores estándares, se supone que esa resolución es para monitores algo mejorados y con ellos se puede conseguir más líneas. Aunque otra cosa es que la diferencia sea tan pequeña que llegue a funcionar en uno de estándar. La verdad no sé si la idea original de los que lo definieron es esta pero yo me lo he tomado así, igual que el Medium y el VGA20.

Originalmente publicado por Calamity

- Los datos de Atari puede que contengan algún error, y aparecen copiados una y otra vez por internet. En esta página http://kirurg.org/emame/arcadetiming/ , el autor sugiere que posiblemente vertical delay = sync pulse + margen final.

Esto contradice lo de más arriba, es lo que te sugerí al restar la longitud de pulso del márgen final y me comentabas que te da una imagen demasiado ancha.
margen final = vertical delay - sync pulse
Lo correcto según dicho más arriba seria vertical delay = margen final.

Originalmente publicado por Calamity

Eso se correspondería con lo que he observado en las pruebas con el monitor Hantarex, en donde los modos de la ArcadeVGA (que entran en la pantalla y quedan centrados) tienen una proporción entre margen inicial - long. pulso - margen final entorno a 2,0 - 5,0 - 7,0 a 2,5 - 4,7 - 6,8. Si bien he comprobado que mientras mantengamos la suma de estos tres valores entorno a 14, podemos bajar la longitud de pulso hasta 2,5, aunque no puedo garantizar que esto funcione en otros monitores.

Ops, estos te van bien y los otros no caben?? No entiendo nada. Estos tienen un tiempo de retorno bastante inferior a los generados, prácticamente igual al que te sugerí al restar los valores, y me comentabas que no te cabía la imagen. ¿Como puede ser que te vayan bien?

Originalmente publicado por Calamity

- Nuevo jarro de agua fría: he encontrado el límite para el número de modos de vídeo personalizados que permite el driver. En la versión 4.3 (drivers ArcadeVGA) el número máximo de modos que podemos definir es de 40.

Exacto, en base a estas limitaciones decidí crear WinModelines, al darme cuenta que tanto ATI como NVidia tienen límites, decidí que fuera el usuario quien pusiera los modos que le interesaran para lo que quisiera hacer. A parte que la idea era generalizarlo para cualquier dispositivo, no solo 15kHz.

Originalmente publicado por Calamity

En versiones posteriores del driver, dicho límite se incrementa solamente hasta 60 modos. Lo que cuenta no es el número de claves DALNonStandardModesBCD sino la suma total de modos que se definan en ellas.

En la Catalyst 6.11 el límite para cada DAL... es de 20, el más bajo que conozco, pero numerándolos de 20 en 20 se pueden poner más de 40. No he comprobado si el límite es 60, tampoco puedo probar todas las versiones del driver, cada usuario descubirá por si mismo el límite de su driver. Por esta razón aconsejo siempre cuando hay problemas para poner en marcha el invento poner un modo probado, uno solo y hacer pruebas con él. En principio 40 modos debería funcionar en todas las versiones, luego en otras puede que más. Pero son muchos modos, ¿tanta variedad hay de refrescos especiales en los juegos? Si es así, la solución pasa por borrar e insertar estos especiales cuando se quiera cambiar de juego.

Originalmente publicado por Calamity

- Tal como comentáis más arriba, los drivers que traen los ordenadores Dell también modifican la clave ReleaseVersión, en este caso cambian -ATI por -Dell. Deshaciendo el cambio se consigue hacer funcionar Winmodelines.

Quitaré esta validación ya que ni NVidia ni Matrox ni 3Dfx tienen este valor por lo que no entra en conflicto con los otros drivers soportados. Puede ser que algun driver raro salga como ATI, mala suerte (no funcionará, no os hagáis ilusiones :P ).

Originalmente publicado por Calamity

- Por cierto, cuando he estado viendo todo esto, hay una duda que no he podido aclarar: ¿varía la duración del blanking horizontal en función de la frecuencia horizontal?

Yo asumí que para cambios pequeños no influiría mucho, el tiempo de blanking afecta en el tamaño horizontal de la imagen, cuanto más pequeño, más ancha la imagen, pero si el cambio es muy pequeño seguramente no lo llegues a apreciar (digo yo...). Siendo muy puristas se debería corregir en el mismo porcentaje que la variación de frecuencia, pero los monitores y TV de este tipo no es que admitan variaciones muy grandes de frecuencia como para que llegue a hacerse notar (todo esto bajo mi opinión, claro). En cambio los monitores multifrecuencia de PC que admiten muchas frecuencias sí que se ha de calcular, y eso es lo hace el "Monitor VESA" con las fórmulas GTF.

Gracias!

Hola Jeroni, quise sintetizar el tema porque no tenía tiempo, lamento haber enredado el asunto, verás como realmente hablamos de lo mismo.

Originalmente publicado por Jeroni Paul

Entonces los valores que tiene el winmodelines son buenos: 0 + 4.7 + 11.9 = 16.6.

Son buenos en total (la suma) aunque algo elevados, con 14 us, como te digo, sobra. La clave es la forma en que hay que repartir los márgenes inicial y final.

Originalmente publicado por Jeroni Paul

No he leído el manual pero si no da más datos como otros que he visto, estamos en las mismas: ¿incluye este tiempo el tiempo de pulso o no?

El manual te lo puedo pasar, de todos modos no aclara mucho, da 12 us para el blanking horizontal y 1 ms para el vertical (aquí sí que especifica que el flyback es 0,7 ms). De la longitud del pulso horizontal no dice nada

Una posible explicación es que en efecto el pulso horizontal esté incluido en los 12 us de blanking horizontal... peeero que la electrónica de la Ati necesite generar ese margen inicial adicional de 2 us por alguna razón (como tú sugerías),

Originalmente publicado por Jeroni Paul

Ops, estos te van bien y los otros no caben?? No entiendo nada. Estos tienen un tiempo de retorno bastante inferior a los generados, prácticamente igual al que te sugerí al restar los valores, y me comentabas que no te cabía la imagen. ¿Como puede ser que te vayan bien?

Vale, aquí no me expliqué bien. Resulta que seguí paso por paso lo que me pediste que probara. Resté 4,7 al margen final, por tanto quedó 0,00 / 4,7 / 7,2. Entonces generé el modo, y luego retoqué el modeline añadiendo 7 a los valores HHI y HHF (pero no HHT). El problema es que la suma es 11,9 (insuficiente). Para que quepa el modo, también hay que incrementar HHT, de forma que la suma de pulsos y márgenes ronde los 14 us.

Originalmente publicado por Jeroni Paul

La idea es que la resolución extendida no es para monitores estándares, se supone que esa resolución es para monitores algo mejorados y con ellos se puede conseguir más líneas.

Lo que ocurre con esto es que, al contrario de la TV en la que tenemos los estándares PAL y NTSC, perfectamente definidos, en el mundo arcade necesitamos infinidad de modos y refrescos, que difícilmente se van a ajustar la corsé de los datos de Atari. Sin ir más lejos, mi monitor, que es de los corrientillos de resolución estándar (aunque en el manual comentan la mejora de haber reducido el tiempo de flyback para permitir más líneas), puede sacar perfectamente 256 líneas a 60 Hz si subo la frecuencia horizontal a 16,7. Eso incluso excedería los límites del Arcade Extended (16,5 y 53Hz). No quiero con esto pretender que apañes el programa para toda la casuística de los modos arcade, simplemente comentarte que el 99% de los modos para este uso tendrán que realizarse con la opción Personalizada.

Como desgraciadamente no disponemos de la documentación necesaria, no podemos más que basarnos en estas comprobaciones empíricas, y una buena base pueden ser los modos de la ArcadeVGA, que teóricamente deben de funcionar en multitud de monitores arcade diferentes.

Originalmente publicado por Jeroni Paul

Exacto, en base a estas limitaciones decidí crear WinModelines, al darme cuenta que tanto ATI como NVidia tienen límites, decidí que fuera el usuario quien pusiera los modos que le interesaran para lo que quisiera hacer. A parte que la idea era generalizarlo para cualquier dispositivo, no solo 15kHz.

De hecho yo pretendo también usar Winmodelines para mi futuro HTPC, y librarme de la ponzoña del Powerstrip.

Originalmente publicado por Jeroni Paul

En la Catalyst 6.11 el límite para cada DAL... es de 20, el más bajo que conozco, pero numerándolos de 20 en 20 se pueden poner más de 40. No he comprobado si el límite es 60, tampoco puedo probar todas las versiones del driver, cada usuario descubirá por si mismo el límite de su driver.

He desensamblado varias versiones del Catalyst, y tengo localizado el punto donde se le pasa el parámetro del número de modos a buscar. Precisamente la 6.11 busca 60 modos. Podría probar a incrementar ese valor, pero como el driver trabaja con una organización de memoria "estática", esto haría que se sobreescribieran otras zonas de la memoria... ya veré qué puede hacerse.

Lo que pasa es que si te excedes en el número de modos el programa devuelve el error de "modo no soportado". Hasta que descubrí el problema me volví loco pensando que se trataba de un error en la definición del modeline.

Originalmente publicado por Jeroni Paul

En principio 40 modos debería funcionar en todas las versiones, luego en otras puede que más. Pero son muchos modos, ¿tanta variedad hay de refrescos especiales en los juegos? Si es así, la solución pasa por borrar e insertar estos especiales cuando se quiera cambiar de juego.

Pues sí, para cada resolución suele haber diversos refrescos. Yo creo que hará falta al menos el doble, ya veremos. En algunos casos podremos agrupar varios modos en uno equivalente. Pero la ArcadeVGA ya trae unos 30 modos, y con los 10 restantes lo tenemos difícil. De todos modos esto no debe preocuparte.

Originalmente publicado por Jeroni Paul

Siendo muy puristas se debería corregir en el mismo porcentaje que la variación de frecuencia, pero los monitores y TV de este tipo no es que admitan variaciones muy grandes de frecuencia como para que llegue a hacerse notar

Hombre, era más una cuestión de curiosidad que otra cosa. El rango de frecuencias que acepta mi monitor, por ejemplo, abarca 1 KHz, regulable con el potenciómetro de frecuencia horizontal. Es decir, si lo regulo para que pille los modos de 16,7 KHz, dejará de sincronizar los modos por debajo de 15,7 KHz (putadilla porque los modos de la bios de la ArcadeVga parece que trabajan a menos de 15,7, y deja de verse bien el arranque de la bios). Entonces, 15,7 / 16,7 * 4,7 = 4,42 us, que como dices no es una diferencia significativa, más teniendo en cuenta que con los redondeos a múltiplos de 8 la precisión no da para tanto.

Bueno, eso era todo, saludos!

Calamity

Perdonad la interrupción: sois la hostia.
Ya, ahora sí podeis seguir, máquinas.

Originalmente publicado por Calamity

Hola Jeroni, quise sintetizar el tema porque no tenía tiempo, lamento haber enredado el asunto, verás como realmente hablamos de lo mismo.

No te preocupes, con todo esto seguro que conseguimos que funcionen nuestros inventos

Originalmente publicado por Calamity

Son buenos en total (la suma) aunque algo elevados, con 14 us, como te digo, sobra. La clave es la forma en que hay que repartir los márgenes inicial y final.

Pero es que el repartir los márgenes afecta solo en el centrado de la imagen, no en su tamaño. Me comentabas que no cabe la imagen: ¿se sale de ambos lados o solo de uno? ¿Tienes control para centrarla en el monitor?

Originalmente publicado por Calamity

Una posible explicación es que en efecto el pulso horizontal esté incluido en los 12 us de blanking horizontal... peeero que la electrónica de la Ati necesite generar ese margen inicial adicional de 2 us por alguna razón (como tú sugerías),

No creo que en esas especificaciones confiaran en que la electrónica generaria ese márgen. Parece como que el monitor no cumple con sus especificaciones. O a lo mejor y quizá más probable, la ATI no se ajusta a los modos, es decir a lo mejor realmente solo se aproxima al modo pero no lo sigue del todo. Cuando tenga algo de tiempo, intentaré mirar con el osciloscopio los sincronismos de esos modos a ver si realmente el tiempo es el que debería y si cumple con los márgenes que se le dicen.

Originalmente publicado por Calamity

Vale, aquí no me expliqué bien. Resulta que seguí paso por paso lo que me pediste que probara. Resté 4,7 al margen final, por tanto quedó 0,00 / 4,7 / 7,2. Entonces generé el modo, y luego retoqué el modeline añadiendo 7 a los valores HHI y HHF (pero no HHT). El problema es que la suma es 11,9 (insuficiente).

Bueno, ahí hemos llegado a un punto algo inusual. Tanto los modos de Atari como las especificaciones del monitor señalan 12us y sin embargo el monitor no llega con ese tiempo. Algo hay, pero claro, que lo diga el manual del monitor y luego no funcione no es algo que pueda corregir en el winmodelines.

Originalmente publicado por Calamity

Lo que ocurre con esto es que, al contrario de la TV en la que tenemos los estándares PAL y NTSC, perfectamente definidos en el mundo arcade necesitamos infinidad de modos y refrescos, que difícilmente se van a ajustar la corsé de los datos de Atari. No quiero con esto pretender que apañes el programa para toda la casuística de los modos arcade, simplemente comentarte que el 99% de los modos para este uso tendrán que realizarse con la opción Personalizada.

La idea es que simplemente modificando la frecuencia en el generador y con los mismos datos debería funcionar bien (o casi), además con la facilidad de ir modificando la frecuencia y ver cuantas líneas se consiguen y así poder hallar un buen compromiso entre las dos frecuencias y la resolución vertical. Pero si los datos no van bien ni siquiera con sus frecuencias nominales, es que hay otro problema.

Originalmente publicado por Calamity

Como desgraciadamente no disponemos de la documentación necesaria, no podemos más que basarnos en estas comprobaciones empíricas, y una buena base pueden ser los modos de la ArcadeVGA, que teóricamente deben de funcionar en multitud de monitores arcade diferentes.

Recuerdo que tuviste problemas con algunos modos de la ArcadeVGA en el vertical. Eso debe significar que hay monitores que tienen un retrazado más rápido que otros, a pesar de tener quizá las mismas especificaciones.
Por otro lado, una avería común en los circuitos de deflexión es por el desgaste de condensadores electrolíticos y causa que el retrazado sea más lento. En los televisores viejos no es raro ver líneas de retorno en la parte superior de la imagen, muy similares a las que tenías. Con eso no quiero decir que sea ese tu problema, pero sí poner sobre la mesa este hecho.

Originalmente publicado por Calamity

He desensamblado varias versiones del Catalyst, y tengo localizado el punto donde se le pasa el parámetro del número de modos a buscar. Precisamente la 6.11 busca 60 modos. Podría probar a incrementar ese valor, pero como el driver trabaja con una organización de memoria "estática", esto haría que se sobreescribieran otras zonas de la memoria... ya veré qué puede hacerse.

Estás hecho un crack
No creo que se pueda mover ese área de memoria, pero con un poco de suerte no sea nada importante lo que hay ahí. Jupe, me estás animando a intentar desensamblar los de la Rage para ver porqué ignoran los modos que se le meten :P ... otro día...

Originalmente publicado por Calamity

Lo que pasa es que si te excedes en el número de modos el programa devuelve el error de "modo no soportado". Hasta que descubrí el problema me volví loco pensando que se trataba de un error en la definición del modeline.

Sí, esto debería estar mejor documentado, pero no tengo mucho tiempo para nada...

Saludos!

Buff!!Estoy flipando.....Sois grandes, todo por la comunidad marciana...
Un saludo!!