126 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Hola Hitomi_Dyego, gracias por probarlo.

Lo primero que probaría es a reducir el número total de modos en el ini de VMMaker, ya que el parche para llevarlo hasta 200 es un poco "bruto" y ya ha dado algún problema interaccionando con Hyperspin. Haz la prueba de reducirlo a 50 ó 60 modos y vuelve a generar los modelines + inis, reinicias, y pruebas los juegos un rato a ver si tienes problemas. Bajar tanto el número de modos afectará bastante a la calidad de las resoluciones seleccionadas, pero para la prueba nos vale. Si sigues teniendo problemas tras hacer esto, entonces yo descartaría que sea un problema de drivers. La prueba definitiva es volver a los drivers convencionales de Ultimarc y ver si tienes problemsa. Lamentablemente he visto casos parecidos y siempre acababa siendo un problema de hardware: calentamiento de la tarjeta, problemas en el puerto AGP... espero que no sea tu caso.

Ir al foro: Hardware del vídeo y emulación avanzada

127 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

He actualizado el mensaje principal con novedades:

[05/10/2010][CRT_EmuDriver 1.1][VideoModeMaker 1.0][Arcade_OSD 1.0]

- Subsanado problema de instalación del driver en tarjetas diferentes a las Radeon 9200/9250, debido a un error en los archivos .inf

- Añadido soporte para Ati Radeon X1950 Pro (probado por ConanR)

- Modos de vídeo preinstalados para Mame v0.139

Esta nueva versión de CRT_Emudriver sólo es de interés para aquellos que tuvieran problemas instalando la anterior.

La versión 1.1 de CRT_EmuDriver corrige un error que impedía la instalación en la mayor parte de las tarjetas "publicitadas" como compatibles. Lo descubrí al adaptar el driver para dar soporte a la X1950. No obstante, con la X1950 hemos constatado que no soporta bajas resoluciones por la imposibilidad de utilizar "dotclocks" suficientemente bajos. Este problema puede ser común a muchas tarjetas, que si bien aceptarán el driver, no podrán mostrar correctamente las resoluciones bajas.

Por otra parte, hemos detectado problemas con la instalación en ciertos sistemas XP, como las versiones desatendidas (gracias a pakoto). Al parecer los drivers se instalan correctamente pero luego la funcionalidad Direct3D queda inhabilitada, lo cual se manifiesta en problemas de tearing en los juegos (no funciona vsync). Para comprobar el buen funcionamiento ejecutaremos "dxdiag" y en la pestaña "pantalla" todas las características de DirectX habrán de estar habilitadas. Por lo que hemos podido comprobar el problema acabó resolviéndose tras reinstalar el driver unas cuantas veces pasando primero el Catalyst Uninstaller, pero no tenemos una explicación válida salvo la sospecha de que los controladores que trae Windows instalados por defecto interfieren de alguna manera con los nuevos.

Saludos,

Calamity

Ir al foro: Hardware del vídeo y emulación avanzada

128 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

El centrado horizontal básicamente consiste en variar los tamaños relativos de FrontPorch (margen derecho) y BackPorch (margen izquierdo). El tamaño de estos márgenes se mide en "caracteres" (bloques de 8 píxeles, ¿te refieres a eso?), y esto no es un capricho, sino que viene impuesto por el hardware. Lo normal es que dichos márgenes no sean iguales, siendo típicamente mayor el BackPorch. Es por esto que normalmente tenemos más recorrido para desplazar la imagen hacia la izquierda que hacia la derecha. Por ejemplo, cuando la posición por defecto es "6/8", quiere decir que podemos desplazar la imagen a la izquierda 6 caracteres, y a la derecha sólo 2, siendo 8 caracteres la suma de FrontPorch+BackPorch, que podemos distribuir como queramos. No obstante, si reducimos los márgenes en exceso obtendremos una imagen cortada o distorsionada (los márgenes, a fin de cuentas, son necesarios).

También puede ocurrir que tengamos la imagen sólo ligeramente descentrada, y que el desplazamiento mínimo de un bloque de 8 píxeles resulte excesivo, sobre todo en resoluciones bajas. La solución pasa por aumentar en uno o dos caracteres uno de los márgenes, y luego volver a centrar la imagen con la opción correspondiente. Cuando hagamos esta operación, dado que estaremos cambiando el tamaño horizontal total de la imagen, es conveniente tener activada la opción "Lock Vfreq" (por defecto) para que el programa recalcule el timing del modo.

Los cambios se almacenan en el registro del Windows, en el apartado correspondiente al driver de vídeo. Por tanto se pierden si vuelve a instalarse el driver o a generarse los modos (mucho ojo). Todavía tengo que pensar en un sistema para poder guardar estos cambios para futuras instalaciones.

Como dices, sólo se enumeran y es posible editar los modos disponibles en el sistema en cada momento. Para generar nuevos modos hay que usar VideoModeMaker y reiniciar el sistema. De hecho me sigue sorprendiendo que este truco funcione y todavía debemos ser prudentes.

Ir al foro: Hardware del vídeo y emulación avanzada

129 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Hola Daicon-X, muchísimas gracias por probarlo.  Puedes modificar los modelines desde Arcade_OSD. Si ya tienes modelines anteriores puedes usarlos pero ten en cuenta que este programa redondea todos los valores x a múltiplos de 8. Con un poco de suerte puede servirte para tratar de apañar los modos que te fallan, o al menos determinar qué es lo que falla.

Si quieres volver a generar los modelines, hay una nueva opción en el ini que se llama "Iterations", si lo dejas a 0 quizá tengas menos modos problemáticos que en la anterior ocasión.

Ir al foro: Hardware del vídeo y emulación avanzada

130 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

He actualizado el primer mensaje con las novedades. He renombrado el "driver" como "CRT_EmuDriver" y al programa xml2ini como "VideoModeMaker", con objeto de que sea más explícita la función de cada uno.

La principal novedad es el programa Arcade_OSD, evolución del anterior Resviewer, que cuenta como principal atractivo con la capacidad de editar los modos de vídeo en tiempo real, para centrarlos en caso de que sea necesario, como si del OSD de un monitor de PC se tratara. Otras funciones son la de establecer el modo de vídeo del escritorio (en sustitución de Quickres), y medir con precisión el refresco vertical real de cada modo. Todas las funciones son manejables desde el joystick y los botones del panel de control de la recreativa (como alternativa a los cursores también puede utilizarse O, P, Q, A, qué recuerdos).

La documentación todavía es muy precaria. He dado prioridad a terminar las aplicaciones principales, para ir documentando posteriormente.

El "driver" no ha sido actualizado, sólo renombrado, por tanto quien tuviera instalada la versión 2.0 de los "Drivers Alternativos" no tiene que reinstalar los drivers. Las futuras actualizaciones probablemente sólo afecten a las aplicaciones VideoModeMaker y Arcade_OSD por lo que habilitaré descargas separadas.

Ir al foro: Hardware del vídeo y emulación avanzada

131 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Es estupendo leer eso. En breve sacaré la nueva versión con las novedades.

Ir al foro: Hardware del vídeo y emulación avanzada

132 Respuesta por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Gracias por las pruebas Recap. Entiendo que te funcionan los ajustes en tiempo real. Es un alivio.
Aclaro que la versión que ha probado Recap todavía no la he puesto para descarga, lo haré en breve.

Ir al foro: Hardware del vídeo y emulación avanzada

133 Respuesta por Calamity

(15 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

WinX68kHighSpeed_eng - Full Screen Patcher (08/31/2010) - by Calamity

PURPOSE:

WinX68kHighSpeed v0.95 is a fantastic emulator of the Sharp X-68000 system. It can be set up to run full screen, but it uses a fixed resolution of 800 x 600, which cannot be changed through configuration options. The purpose of this *experimental* patch is to provide Winx68kHighSpeed emulator with the ability to change the screen resolution on the fly, depending on the native resolution requested by the game being emulated, thus achieving pixel-perfect results with no scaling.

Download WinX68kHighSpeed v0.95 - "Full Screen" [patch]

INSTALLATION:

- This patch only works with the English version of the emulator. It can be downloaded from its web: WinX68kHighSpeed v0.95

- Download WinX68kHighSpeed v0.95 - "Full Screen" [patch], unrar and place "WinX68k_patcher.exe" in the same folder where "WinX68kHighSpeed_eng.exe" is, then run "WinX68k_patcher.exe". A new executable will be produced, named "WinX68kHighSpeed_eng.fullscreen.exe".

- Before running this executable, make sure you have the necessary video modes available in your system. See VIDEO MODES section below.

- If the program crashes at start, rename or delete the old "winx68k.ini" so that a new config file is created.

SETUP:

- For good operation, "Display" MUST be set to "No Stretch". Then toggle "Full Screen" on/off as you wish.

- "BackBuffer" must be set to "System(to Video)", "Blit+Flip in Full Screen"

- To turn Vsync on, set "Full Screen" on first, then press F11 to show the menus, and in "BackBuffer" menu, select "Vsync", "on".

VIDEO MODES:

When set to full screen, the program will try to activate the current video mode used by the OS or the game being emulated. If the video mode is not present in the system, the program will crash. This makes necessary to define the correct modelines for the variety of video modes used by the different games. Here we provide a suggested list of modelines, ready for use with Winmodelines or other software (just for 15 KHz CRT monitor):

Modeline "256x224@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 224 244 247 282 -hsync -vsync
Modeline "256x240@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 240 252 255 282 -hsync -vsync
Modeline "256x256@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 256 260 263 282 -hsync -vsync
Modeline "320x224@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 224 244 247 282 -hsync -vsync
Modeline "320x240@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 240 252 255 282 -hsync -vsync
Modeline "320x256@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 256 260 263 282 -hsync -vsync
Modeline "384x224@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 224 244 247 282 -hsync -vsync
Modeline "384x240@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 240 252 255 282 -hsync -vsync
Modeline "384x256@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 256 260 263 282 -hsync -vsync
Modeline "512x224@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 224 244 247 282 -hsync -vsync
Modeline "512x240@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 240 252 255 282 -hsync -vsync
Modeline "512x256@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 256 260 263 282 -hsync -vsync
Modeline "512x512@55.6Hz 15.7KHz (56Hz)" 10.530 512 536 584 672 512 520 525 565 interlace -hsync -vsync
Modeline "640x480@60.1Hz 15.6KHz (60Hz)" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "768x512@55.5Hz 15.7KHz (55Hz)" 15.640 768 800 872 1000 512 520 525 565 interlace -hsync -vsync

It's important to remark that this list may not be complete: if a game happens to request for a missing resolution, while in full screen, the emulator will crash. However, you may find the problematic resolution out by running the emulator in windowed mode and getting a screenshot of the game, in order to "measure" the dimensions of the frame. Then you can produce your own modeline to support that mode, or report it to us so we can add it to this txt. Consider that some games may attempt to use several screen resolutions, not just one.

If you are using a multisync monitor, you can also replace some of the previous modelines for their 31 KHz versions.

Note that, for convenience, 640x480 is added for use as Windows desktop resolution.

At the moment, it may be a good idea to generate separate modelines for this emulator and all the others (Mame, etc.), so that the emulator does not accidentally choose the wrong video mode (same resolution with wrong refresh rate).

It's also important to state that we have assumed a refresh rate of 55.45 Hz for all the modes, which may not be correct (any information on video timings of the real machine is welcome).

USAGE WITH "ATI ALTERNATIVE DRIVER FOR CRT"

If you happen to own an ATI Radeon 9250 or any of its relatives, you may want to have a look at this modified (patched) Catalyst driver for 15kHz (have a look for details and supported ATI cards).

In order to use this emulator with the modified driver, just go to the folder of the driver package, backup the existing ResList.txt and replace it with this:

## Desktop ##

640 x 480 @ 30.000000 desktop

## X-68000 ##

256 x 224 @ 55.450000 x-68000
256 x 240 @ 55.450000 x-68000
256 x 256 @ 55.450000 x-68000
320 x 224 @ 55.450000 x-68000
320 x 240 @ 55.450000 x-68000
320 x 256 @ 55.450000 x-68000
384 x 224 @ 55.450000 x-68000
384 x 240 @ 55.450000 x-68000
384 x 256 @ 55.450000 x-68000
512 x 224 @ 55.450000 x-68000
512 x 240 @ 55.450000 x-68000
512 x 256 @ 55.450000 x-68000
512 x 512 @ 55.450000 x-68000
768 x 512 @ 55.450000 x-68000

Then run xml2ini.exe, restart Windows and you will have the video modes ready for use with the emulator. To revert the process, restore the old ResList.txt and repeat the operation.
All topics explained in the previous VIDEO MODES section are also valid here.

X-68000 - by Recap

It was only sold in Japan and its expansion suffered severly from the success of NEC's PC-88 and PC-98 series, far less expensive and with more models and options for the buyer, but Sharp's X-68000 computer, released as early as the first months of 1987 in its first version, was a true leap forward for the Japanese home computing scene thanks to its audiovisual capabilities, impossible to find then outside of some specific professional areas. The Motorola's 68000-based CPU, coupled with some powerful and versatile audiovisual chips, along with a RAM from 1 MB onwards and the controller connectivity features, made of it the game machine of the time -- not only it received a fair amount of extremely accurate ports of some of the best arcade titles (usually programmed by the original devs) or the most popular adventure games for adults from NEC's computers, it also got a pretty good catalog of original action games by both, professional companies and 'amateur' people.

You needed a multi-synch monitor (15 - 24 - 31 kHz) to run the X-68000 given the diversity of video modes it used. You''ll find that 31 kHz line-doubled 256 x 256 pixels (displayed 512 x 512) was pretty common game-wise. With luck, if the devs remembered to add it as an option, you could display these games at 15 kHz 256 x 240, therefore losing some 'natural' lines in the process but also getting rid of the 'fake high res' look. WIN X68k High Speed emulator allows a 'direct framebuffer (single scan) display' for these games, opening for us a brand-new field to 'reclaim' them and display them at their 'design', artifact-free resolution.

Ir al foro: Hardware del vídeo y emulación avanzada

134 Tema creado por Calamity

(15 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

WinX68kHighSpeed_eng - Full Screen Patcher (31/08/2010) - por Calamity

PROPÓSITO:

WinX68kHighSpeed v0.95 es un fantástico emulador del sistema Sharp X-68000. Puede ejecutarse en modo pantalla completa, pero utiliza una resolución fija de 800 x 600, que no puede modificarse mediante las opciones de configuración. El propósito de este parche *experimental* es dotar al emulador de la capacidad de cambiar la resolución de pantalla de forma dinámica, en función de la resolución nativa del juego emulado, consiguiendo así un resultado "pixel-perfect" sin ningún escalado.

Descargar WinX68kHighSpeed v0.95 - "Full Screen" [parche]

INSTALACIÓN:

- El parche funciona sólo con la versión inglesa del emulador. Puede descargarse desde su web: WinX68kHighSpeedv0.95.

- Descargar WinX68kHighSpeed v0.95 - "Full Screen" [parche] y descomprimirlo en la carpeta donde esté el ejecutable "WinX68kHighSpeed_eng.exe", y ejecutar "WinX68k_patcher.exe". Se generará un nuevo ejecutable llamado "WinX68kHighSpeed_eng.fullscreen.exe".

- Antes de usar este ejecutable, hay que asegurarse de que los modos de vídeo necesarios estén disponibles en el sistema. Ver la sección MODOS DE VÍDEO, más abajo.

- Si el programa se cuelga al iniciarse, renombrar o borrar el archivo "winx68k.ini" existente para que el emulador genere un nuevo archivo de configuración.

CONFIGURACIÓN:

- Para el buen funcionamiento, la opción "Display" DEBE asignarse a "No Stretch". Luego podrá activarse y desactivarse "Full Screen" según deseemos.

- "BackBuffer" debe asignarse a "System(to Video), "Blit+Flip in Full Screen"

- Para activar Vsync, activar primero "Full Screen", luego pulsar F11 para mostrar los menús, y después en el menú "BackBuffer", seleccionar "Vsync", "on".

MODOS DE VÍDEO:

Cuando se selecciona pantalla completa, el programa intentará activar el modo de vídeo actual usado por el S.O. o por el juego que se esté emulando. Si el modo de vídeo no está presente, el programa se colgará. Esto hace necesario definir los modelines correctos para la variedad de modos de vídeo usados por los diferentes juegos. Ésta es la lista de modelines que sugerimos, apta para usarse con Winmodelines u otro software (sólo para monitores CRT de 15 kHz ):

Modeline "256x224@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 224 244 247 282 -hsync -vsync
Modeline "256x240@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 240 252 255 282 -hsync -vsync
Modeline "256x256@55.5Hz 15.6KHz (55Hz)" 5.500 256 272 304 352 256 260 263 282 -hsync -vsync
Modeline "320x224@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 224 244 247 282 -hsync -vsync
Modeline "320x240@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 240 252 255 282 -hsync -vsync
Modeline "320x256@55.5Hz 15.7KHz (56Hz)" 6.630 320 336 368 424 256 260 263 282 -hsync -vsync
Modeline "384x224@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 224 244 247 282 -hsync -vsync
Modeline "384x240@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 240 252 255 282 -hsync -vsync
Modeline "384x256@55.5Hz 15.7KHz (56Hz)" 7.880 384 400 440 504 256 260 263 282 -hsync -vsync
Modeline "512x224@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 224 244 247 282 -hsync -vsync
Modeline "512x240@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 240 252 255 282 -hsync -vsync
Modeline "512x256@55.5Hz 15.6KHz (55Hz)" 10.520 512 536 584 672 256 260 263 282 -hsync -vsync
Modeline "512x512@55.6Hz 15.7KHz (56Hz)" 10.530 512 536 584 672 512 520 525 565 interlace -hsync -vsync
Modeline "640x480@60.1Hz 15.6KHz (60Hz)" 12.990 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "768x512@55.5Hz 15.7KHz (55Hz)" 15.640 768 800 872 1000 512 520 525 565 interlace -hsync -vsync

Es importante aclarar que esta lista no pretende ser completa: si un juego solicita un modo de vídeo no contemplado, estando a pantalla completa, el emulador se colgará. No obstante, podemos averiguar cuál es la resolución problemática ejecutando el juego con el emulador en modo ventana, y sacando una captura de pantalla para "medir" las dimensiones del cuadro. Luego podemos generar nuestro propio modeline para dar soporte a esta resolución, o reportárnoslo para añadirlo a este txt. Hay que tener en cuenta que algunos juegos pueden intentar cambiar varias veces de resolución durante su desarrollo.

Si se usa un monitor multifrecuencia, pueden sustituirse algunos de los modelines anteriores por sus equivalentes a 31 KHz.

Por conveniencia, se ha añadido el modo 640x480 para usarlo como resolución del escritorio de Windows.

Por el momento, es mejor generar los modelines para este emulador por separado, no mezclándolos con los de Mame y otros emuladores. De esta forma evitamos que el emulador elija accidentalmente un modo de vídeo equivocado (con la misma resolución pero diferente refresco).

Es importante comentar que hemos asumido un refresco vertical de 55.45 Hz para todos los modos, lo cual puede no ser correcto (cualquier información acerca del refresco nativo de la máquina real es bienvenida).

USO CON "DRIVER ATI ALTERNATIVO PARA CRT"

Si se tiene una tarjeta ATI Radeon 9250 o similar, puede ser interesante echar un vistazo a este driver Catalyst modificado (parcheado) para 15 kHz (en el enlace: información adicional y tarjetas ATI soportadas).

Para usar este emulador con el driver modificado, simplemente hay que hacer una copia de seguridad del archivo ResList.txt, en la carpeta de configuración del driver, y sustituirlo por esto:

## Desktop ##

640 x 480 @ 30.000000 desktop

## X-68000 ##

256 x 224 @ 55.450000 x-68000
256 x 240 @ 55.450000 x-68000
256 x 256 @ 55.450000 x-68000
320 x 224 @ 55.450000 x-68000
320 x 240 @ 55.450000 x-68000
320 x 256 @ 55.450000 x-68000
384 x 224 @ 55.450000 x-68000
384 x 240 @ 55.450000 x-68000
384 x 256 @ 55.450000 x-68000
512 x 224 @ 55.450000 x-68000
512 x 240 @ 55.450000 x-68000
512 x 256 @ 55.450000 x-68000
512 x 512 @ 55.450000 x-68000
768 x 512 @ 55.450000 x-68000

Después ejecutamos xml2ini.exe, reiniciamos Windows y ya dispondremos de los modos de vídeo necesarios para usar este emulador. Para revertir el proceso, restauramos el anterior ResList.txt y repetimos la operación.

Todas las demás consideraciones hechas en la sección anterior "MODOS DE VÍDEO" son también válidas aquí.

X-68000 - por Recap

Sólo fue comercializado en Japón y su expansión se vio enormemente limitada por los estándares de NEC -- PC-88 y PC-98, mucho más asequibles y accesibles, pero el ordenador Sharp X-68000, lanzado en su primera versión en los primeros meses del 87 como sucesor del X-1, fue un auténtico hito tecnológico para la informática doméstica nipona, con unas posibilidades audiovisuales impensables fuera de los ámbitos profesionales. Su procesador central basado en el 68000 de Motorola, una RAM a partir de 1 MB y sus poderosos y versátiles chips gráficos y sonoros (sin olvidar sus opciones base para conexión de controladores) le permitieron convertirse en la máquina de juegos del momento, destinataria, no ya de un buen número de conversiones extremadamente fieles de algunas de las mejores máquinas recreativas (trasladadas, muchas veces, por los propios autores originales) o de los más populares 'adventure games' para adultos desde los ordenadores de NEC, sino de un importante catálogo de originales principalmente de los géneros de acción, tanto por expertas manos profesionales como procedentes del ámbito 'amateur'.

Se empleaba con monitores multifrecuencia (15 - 24 - 31 kHz) dado el enorme rango de modos de vídeo del que era capaz. Uno de los modos más usados en su catálogo de juegos fue el de 256 x 256 puntos con doble muestreo a 31 kHz (512 x 512 puntos), que, si había suerte y los desarrolladores se habían acordado de implementarlo en el programa como opción, se transformaban en 256 x 240 a 15 kHz, perdiendo, eso sí, algunas líneas en el proceso. El emulador WIN X68k High Speed permite la ejecución de los juegos originalmente con doble muestreo tal y como la generaba el 'framebuffer' (con muestreo único), lo que abre las posibilidades de 'recuperar' estos títulos a su resolución de diseño, limpios de artefactos por 'hardware'.

Ir al foro: Hardware del vídeo y emulación avanzada

135 Tema creado por Calamity

(225 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

[CRT_EmuDriver 1.2 (para Ati Radeon 9250 y otras)]
+
[VideoModeMaker 1.3c]
+
[Arcade_OSD 1.3b]

Abrimos este hilo para dar cuenta de las novedades que vayan surgiendo en torno a la modificación o parcheo del driver Catalyst de ATI (versiones 6.5 y 9.3), con objeto de mejorar algunas de sus prestaciones relacionadas con los modos de vídeo de baja resolución y su aplicación a la emulación en general.

Se trata de un proyecto de carácter experimental, orientado a usuarios con experiencia previa en emuladores, especialmente Mame, para uso en ordenadores dedicados a la emulación y monitores CRT de baja resolución (15 kHz).

El objetivo es obtener una señal de vídeo lo más fiel posible a la del sistema emulado, que nos permita ajustar la acción del juego a la tasa de refresco vertical original (vsync) para lograr scrolles suaves y fluidos.

Existen dos versiones paralelas, una basada en Catalyst 6.5, destinada a tarjetas antiguas, y otra basada en Catalyst 9.3 para tarjetas más nuevas. Hay tarjetas que son soportadas simultáneamente por ambas versiones, por tanto será decisión del usuario escoger una o la otra, teniendo en cuenta que la versión 6.5 para XP32 soporta el mayor número de modos de vídeo (200), mientras que las demás versiones están limitadas a 120 modos de vídeo.

ACTUALIZACIÓN: Descargar VideoModeMaker 1.3c + Arcade_OSD 1.3b

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 6.5) para WIN-XP32 + VideoModeMaker 1.3 + Arcade_OSD 1.2
Descargar CRT_EmuDriver 1.2 (basado en Catalyst 6.5) para WIN-XP64 + VideoModeMaker 1.3 + Arcade_OSD 1.2
Tarjetas soportadas por la versión 6.5: Ati Radeon 7000, 7200, 7500, 8500, 9000, 9100, 9200, 9250, 9500, 9550, 9600, 9700, 9800, X300, X550, X600, X700, X800, X850, X1300, X1600, X1800, X1900, X1950, ArcadeVGA 9200/9250, etc. (ver Nota 1)

Descargar CRT_EmuDriver 1.2a (basado en Catalyst 9.3) para WIN-XP32 + VideoModeMaker 1.3 + Arcade_OSD 1.2
Descargar CRT_EmuDriver 1.2a (basado en Catalyst 9.3) para WIN-XP64 + VideoModeMaker 1.3 + Arcade_OSD 1.2
Tarjetas soportadas por la versión 9.3: Ati Radeon 9500, 9550, 9600, 9700, 9800, X300, X550, X600, X700, X740, X800, X850, X1050, X1200, X1300, X1550, X1600, X1650, X1800, X1900, X1950, HD 2350, HD 2400, HD 2600, HD 2900, HD 3200, HD 3300, HD 3400, HD 3410, HD 3450, HD 3550, HD 3570, HD 3600, HD 3610, HD 3690, HD 3730, HD 3750, HD 3800, HD 3830, HD 3850, HD 3870, HD 4230, HD 4250, HD 4350, HD 4550, HD 4570, HD 4580, HD 4650, HD 4670, HD 4730, HD 4750, HD 4800, HD 4850, HD 4870, HD 4890, etc. (ver Nota 1)

Si bien todas las pruebas se realizaron inicialmente con la tarjeta ATI Radeon 9250 AGP, por su popularidad en el mundo de la emulación, ahora estamos utilizando la ATI Radeon HD 4350 PCIe como base de pruebas para la versión 9.3. En negrita aparecen marcadas las tarjetas que hemos podido probar directamente y que funcionan al 100%.

En la carpeta de descarga encontraremos lo siguiente:

- El driver propiamente dicho (subcarpeta .\Driver), preconfigurado para emitir vídeo a 15 kHz inmediatamente tras su instalación, sin necesidad de software adicional, con hasta 200 modos de vídeo diferentes.

- VideoModeMaker (VMMaker.exe), es una utilidad de configuración que nos permitirá personalizar la lista de modos de vídeo disponibles (modelines) de acuerdo con nuestras necesidades, así como configurar correctamente el emulador MAME (cualquier versión que soporte XML) para asignar los modos de vídeo particulares de cada juego / sistema de forma automática. El configurador no trabaja con modelines precalculados, sino que los genera para cada situación, en función de parámetros editables por el usuario.

- Arcade_OSD (Arcade_OSD.exe) es una utilidad que, usada junto a CRT_EmuDriver, permite probar y editar de forma segura los modos de vídeo (modelines) generados por VideoModeMaker, permitiendo diversos ajustes, como el centrado horizontal y vertical y edición de márgenes, en tiempo real (sin necesidad de reiniciar para comprobar los resultados), así como medir la tasa de refresco real de cada modo.

El proyecto se encuentra en fase de desarrollo y pruebas. Esto hilo se irá actualizando con la publicación de los avances que realicemos.

[Tabla estática vs tabla dinámica vs tabla mágica]

VideoModeMaker soporta tres modos de funcionamiento, según queramos generar una tabla de modos de vídeo estática, dinámica o mágica. Esta función se controla desde la variables "ModeTableMethod_XML" y "ModeTableMethod_custom", que se aplican a los modos de vídeo obtenidos de MAME.xml y ReslList.txt, respectivamente.

La tabla de modos dinámica está pensada para usarse con GroovyMAME.
La tabla de modos mágica está pensada para usarse con GroovyMAME + Hyperspin.
Para cualquier otra versión de Mame, usaremos la tabla estática.

La tabla de modos estática respeta la resolución y el refresco original de cada modo de vídeo. La desventaja es que esto genera cientos de modos de vídeo diferentes por lo que hay que reducir la lista para que no se supere la capacidad del driver de vídeo.

La tabla de modos dinámica respeta la resolución pero ignora el refresco, asignándole el más cercano posible a 60 Hz. Luego GroovyMAME recalcula cada modo de vídeo con el refresco correcto para el juego seleccionado, en tiempo de ejecución. Esto reduce drásticamente la tabla de modos de vídeo requerida eliminando duplicidades.

La tabla de modos mágica ignora la resolución horizontal y el refresco, y sólo conserva la resolución vertical, produciendo de este modo resoluciones "comodín" del tipo 1234x. Luego GroovyMAME genera el modeline correcto en tiempo de ejecución, siendo el resultado indistinguible del método anterior, con la ventaja de que redicimos increíblemente la cantidad de modos de vídeo necesarios. Mediante este método podemos generar todas las resoluciones y refrescos necesarios para emular correctamente la totalidad de los juegos de MAME a partir de unas pocas decenas de modos de vídeo (los necesarios para definir correctamente la resolución vertical). Este método es de carácter experimental, por lo que puede fallar en determinados sistemas.

Una configuración típica para GroovyMAME sería:
ModeTableMethod_XML = 1 (ó 2, si usamos Hyperspin)
ModeTableMethod_Custom = 0
GenerateInis = 0

Una configuración típica para MAME convencional sería:
ModeTableMethod_XML = 0
ModeTableMethod_Custom = 0
GenerateInis = 1

[Catalyst Control Center]
Para el uso habitual, es suficiente con instalar el driver. No obstante, ciertas funciones, como la rotación del escritorio, sólo se pueden activar mediante el Catalyst Control Center (CCC). Éste puede descargarse de la web de AMD.

La versión 6.5 ya no está soportada por AMD, no obstante la versión 6.11 es totamente equivalente, por lo que descargaremos esta. Lo que haremos es iniciar la instalación del paquete y cancelarla cuando nos pregunte. De esta forma podremos entrar en "C:\ATI\Support\6-11-pre-r300_xp-2k_dd_ccc_wdm_38185\ACE" e instalar solamente el CCC.
Catalyst 6.11 Software Suite

Para la versión 9.3, puede descargarse individualmente el CCC de la página de AMD (ir a "Option 2 - Individual Downloads", Catalyst Control Center):
Catalyst Control Center 9.3 - XP32
Catalyst Control Center 9.3 - XP64

------------------------------------------------------------------------------------------------------------------------------------------

[Historial de versiones]

[16/06/2012][VideoModeMaker 1.3c][Arcade_OSD 1.3b]

- [VideoModeMaker] Procesamiento de XML adaptado a MAME v0.146 (reportado por genius77).

- [VideoModeMaker] Nuevo listado de modos de vídeo para emulación (ReslList.txt). Selección realizada por Recap.

- [VideoModeMaker] Nuevo listado de sistemas principales para MAME (MameMain.txt). Selección realizada por Recap.

- [VideoModeMaker] Selección de sistemas principales basada en el nombre de la rom.

- [VideoModeMaker] Nueva opción "Only List Main", que permite listar únicamente los modos de vídeo de los sistemas incluidos en MameMain.txt

- [VideoModeMaker] Nueva opción "YresRound", permite asignar un factor de redondeo para la resolución vertical, racionalizando la tabla de modos.

- [VideoModeMaker] Opciones ModetableMethod, XresMin, YresMin y YresRound independientes para MAME y tabla "custom", permite utilizar criterios diferentes para filtrar las resoluciones de MAME y las de la tabla ReslList.txt, optimizando la tabla de modos.

- [VideoModeMaker] Creación automática de tabla de modos "mágica" (ModeTableMethod_XML/custom = 2). Crea una tabla de resoluciones comodín, del tipo 1234 x (yres), lo que permite reducir enormemente la tabla de modos de vídeo. Esta opción sólo puede utilizarse junto con GroovyMAME, en concreto para sortear un "bug" del frontend Hyperspin, que no se inicia si el número de modos de vídeo disponibles en el sistema excede de cierta cifra.

- [VideoModeMaker] Mejoras importantes en la generación de tabla de modos para monitores multifrecuencia.

- [VideoModeMaker]/[Arcade_OSD] Añadido soporte para polaridad de sincronismos.

- [Arcade_OSD] Soporte para múltiples monitores. La opción "Attach OSD to current monitor" permite seleccionar el monitor activo al desplazar la ventana del programa al monitor correspondiente.

- [Arcade_OSD] La opción "Lock unsopported modes" bloquea los modos de vídeo que Windows considera que NO son soportados por nuestro monitor. ATENCIÓN: Windows sólo puede determinar las características de un monitor a partir de la información contenida en el EDID de dicho monitor. Los monitores arcade y los televisores CRT no tienen EDID, por lo que Windows mostrará todos los modos de vídeo como si estuvieran soportados, incluyendo aquellos que son potencialmente peligrosos. Por tanto esta opción no puede usarse para filtrar los modos no soportados. Su función es la opuesta: desbloquar aquellos modos de vídeo que Windows pudiera considerar como no soportados, en aquellos monitores que dispongan de un EDID válido, bajo la responsabilidad del usuario.

[29/08/2011][CRT_EmuDriver 1.2a][VideoModeMaker 1.3][Arcade_OSD 1.2]

- Añadido soporte para la Radeon HD 4890 (la tarjeta más potente soportada hasta el momento)

[16/04/2011][CRT_EmuDriver 1.2][VideoModeMaker 1.3][Arcade_OSD 1.2]

- Nueva versión basada en Catalyst 6.5 para Windows x64

- [VideoModeMaker] Nueva versión 1.3, soporte para monitores multifrecuencia (beta).

[06/03/2011][CRT_EmuDriver 1.2][VideoModeMaker 1.2][Arcade_OSD 1.2]

- Nueva versión basada en Catalyst 9.3 para Windows x64

- [VideoModeMaker] Nuevas opciones VerticalAspect, ModeTableMethod, DotClockMin, AnyCatalyst (ver VMMaker.ini para más detalles).

- [Arcade_OSD] Subsanado problema que impedía conservar los cambios aplicados al modo de vídeo del escritorio de Windows.

[24/12/2010][CRT_EmuDriver 1.2][VideoModeMaker 1.1][Arcade_OSD 1.1]

- Nueva versión basada en Catalyst 9.3

- VMMaker implementa nuevo sistema de etiquetado de modos en la versión 9.3, para diferenciar modos de vídeo con refrescos similiares. Se basa en utilizar tres cifras enteras para denominar el valor del refresco vertical, por ejemplo 320x256@55.5Hz se etiquetaría como 320x256_555. Esto debe tenerse en cuenta a la hora de configurar los emuladores, no obstante VMMaker genera los inis para Mame correctamente con el nuevo sistema. Se puede volver al sistema de etiquetado anterior (consistente en incrementos sucesivos de xres) estableciendo VFreqLabelx10 = 0 en VMMaker.ini.

- VMMaker implementa mejoras en el generador de modelines, de forma que la temporización del monitor puede establecerse con mayor precisión (nuevas variables VFrontPorch, VSyncPulse, VBackPorch en VMMaker.ini)

- Subsanado problema con Arcade_OSD y DDraw en Catalyst 9.3

- Subsanado problema con Arcade_OSD al mostrar la temporización de modos entrelazados.

[05/10/2010][CRT_EmuDriver 1.1][VideoModeMaker 1.0][Arcade_OSD 1.0]

- Subsanado problema de instalación del driver en tarjetas diferentes a las Radeon 9200/9250, debido a un error en los archivos .inf

- Añadido soporte para Ati Radeon X1950 Pro (probado por ConanR)

- Modos de vídeo preinstalados para Mame v0.139

[08/09/2010][CRT_EmuDriver 1.0][VideoModeMaker 1.0][Arcade_OSD 1.0]

- Primera versión completa.

[Notas]

Nota 1: Si bien el driver soporta multitud de modelos de Ati, no todos ellos son programables para mostrar bajas resoluciones, o sólo pueden mostrar algunas. Esto es debido a que muchas tarjetas no pueden trabajar con valores de "dotclock" por debajo de cierto límite. La solución para estas tarjetas consisten en fijar un valor mínimo para el "dotclock" en VMMaker.ini. Para ello editaremos el valor "DotClockMin", recomendándose empezar por 7.5, e ir incrementando si es necesario. Haciendo esto, se duplicará la resolución horizontal en las resoluciones bajas. El resultado, en Mame, es indistinguible.

Nota 2: Se recomienda usar la utilidad Catalyst Uninstaller antes de instalar el driver, para eliminar del sistema cualquier resto de software de Ati. Lamentablemente, ciertos conflictos con drivers anteriores presentes en el sistema pueden producir problemas a la hora de reinstalar nuevos drivers. Por ello se recomienda desinstalar manualmente los controladores Ati de Microsoft para que Windows trae instalados por defecto.

También es recomendable la consulta de este hilo, donde a lo largo del desarrollo diferentes usuarios hemos ido acumulando experiencias y pruebas.

[Agradecimientos]

A Jeroni Paul, creador de Winmodelines, programa que sirvió de inspiración y laboratorio de pruebas y sin el cual nada de esto habría sido posible.

A Recap, por su implicación con el proyecto, ayuda con las pruebas y la selección de los principales sistemas.

A Chris Kennedy, por su impagable trabajo en Switchres / GroovyMame / GroovyArcade.

Agradecimientos especiales a los "beta-testers": Daicon-X, pakoto, ConanR, etc.

------------------------------------------------------------------------------------------------------------------------------------------

[Versiones anteriores]

(enlaces obsoletos)

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 9.3) para WIN-XP32 + VideoModeMaker 1.3 + Arcade_OSD 1.2

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 9.3) para WIN-XP64 + VideoModeMaker 1.3 + Arcade_OSD 1.2

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 6.5) para WIN-XP32 + VideoModeMaker 1.2 + Arcade_OSD 1.2

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 9.3) para WIN-XP32 + VideoModeMaker 1.2 + Arcade_OSD 1.2

Descargar CRT_EmuDriver 1.2 (basado en Catalyst 9.3) para WIN-XP64 + VideoModeMaker 1.2 + Arcade_OSD 1.2

Descargar CRT_EmuDriver 1.1 (para ATI 9250 y otras) + VideoModeMaker 1.0 + Arcade_OSD 1.0

Ir al foro: Hardware del vídeo y emulación avanzada

136 Respuesta por Calamity

(9 respuestas, enviadas el English talk)

Eboshidori escribió:

It's not a question of width (space) but time. The old name for chassis is "time base", because all you do is drive the electron gun in time. There is no space data, unlike flat fixed res' screens. That's one of the major difference between CRT and every other display technologies. That's why we talk about frequencies for CRT, because "resolution" isn't enough to clearly describe the capacity of a tube.

So, as the scan frequency increase, the line duration decrease. You also have a slight difference between PAL (64µs) and NTSC (63,55 µs). Every dynamique geometric distortion is a matter of delay added to the signal.

Although, as you state, all the information to build a modeline is of time nature (that's what we talk about "timings" of a video mode), being the speed of the electron beam a constant value, the shorter (in time) the scanline is, the narrower (in space), the resulting picture will be (in absence of a compensating mechanism). I am positive of this fact as I observe it all the time, and has lead me to look for a way to compensate it.

To explain it with an example: if you adjust an arcade monitor so that a resolution of 320x240@60Hz (15.625 kHz) fits perfectly within the screen frame, then if you keep the adjustment and show a resolution of 320x256@60Hz (16.700 kHz) you will have big borders on the sides of the picture (in fact, as we also keep the vertical refresh rate, the time for the extra lines of vertical resolution have to come from somewhere -- from those borders!).

However, I'm not saying that this has to do with voltage differences, it was just a suggestion for searching.

Eboshidori escribió:

I noticed a fading for very "out-standard" resolutions, but from top to bottom, not from left to right, and no color tinted. Some resolutions were stable and readable, but only the first few lines were bright, all the other were darker and darker.

I think I have seen that effect also, but the one I mean is different, constant on the whole picture, as when te contrast potenciometer is too high.

Eboshidori escribió:

From what I saw, you have different results with the same frequency (same resolution), depending on the driver (or lack of it). But yeah, maybe different drivers use different pixel clocks and porshs to display the same thing, so at the end of the digital>analog conversion on the graphic card, you can have various voltages. Remember that this conversion is always a weak point in many electronics (except high-end products). For now I don't really know much about the subject.

When you tested the same resolution in different drivers I assume your samples also had the same vertical refresh. If finally it turns out to be a 'feature' of the digital-analog conversion, then there is not much we can do...

Ir al foro: English talk

137 Respuesta por Calamity

(9 respuestas, enviadas el English talk)

Eboshidori escribió:

So, you made a hack to allow more different resolutions at a time. But do you know why all different resolutions can produce different voltage levels at the VGA output ?

I don't know if this has to do with voltages at all, but I do have noticed a difference in intensity of colours depending on the resolution, specifically on the horizontal frequency of the video mode. I had associated it to the fact that, as you increase the horizontal frequency, the width of the scan lines gets reduced (a single line at 15.625 KHz is 64 µs long, the same line at 16.200 KHz becomes 62 µs), so the video gets more concentrated in the middle of the screen, burning the colors. Even if the constrast had been adjusted for video modes around 15 KHz, you could see how the colors faded to the right with a blue shadow as you change to video modes with higher horizontal frequency.

As I said, I can't figure if this could have any relationship with voltages, but reading your post I remembered this curious effect. It's also true that horizontal frequency for a given resolution may vary from a driver to another, as the timings will probably be different. It would be good to check if voltage differences have to do with horizontal frequency variations or any other feature of the modeline.

Eboshidori escribió:

In general way, digital electronics tend to be much simpler to design, they have a more regular behavior than analog one. So, on older analog chassis, you often find very wide tolerances on timings, porshs, frequencies. In digital ones, especially because they are designed according to very few broadcast signals (and not video games :P ), you tend to have very few room for your non-standard signals.

So, you are confirming my fear that these modern chassis may not be flexible at all for proper emulation. However, I will try to find a workaround for these users, problably including a manual set up of modelines.

Ir al foro: English talk

138 Respuesta por Calamity

(9 respuestas, enviadas el English talk)

Hi Eboshidori,

I highly appreciate your technical posts on CRTs. I am currently working on a software to get the best possible results from ATI videocards on CRTs by extending the regular driver capabilities, by means of a simple hack that allows more resolutions to be used at the same time (regular driver only has space for 60 modes). However, the main part of this soft is the little program that calculates the required modelines depending on some initialization values. You may have seen the project in this thread:

http://postback.geedorah.com/foros/view … 23&p=3

While the modelines produced by the program have been succesfully tested on my arcade monitor (Hantarex 9110) and Recap's Trinitron set, I still have to find a proper explanation for the behavior observed by Daicon-X on his tv, a Bluesky 21". In order to avoid you the translation of the whole thread, I would say that this chassis has a "non-linear" behavoir, with seemingly random results from subtle changes in the input modeline, specially around 57 Hz. The most obvious problem appears as a block of lines displaced to the left on the bottom of the picture.

I lack the electronics knowledge to give an explanation. I've read that modern CRTs use chips for signal processing. How could these chips affect the results? Is it possible that these chips are hardcoded to filter PAL/NTSC signals and do not know exactly what to do with non-standard timings? Or should all chassis accept via SCART any proper RGB signal provided that the timings are good, whatever the refresh is? (and obviously, using an horizontal frequency within the monitor range).

Ir al foro: English talk

139 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Hola,

Pegote, sin conocer las especificaciones del Hantarex que mencionas, sólo podemos especular. En cualquier caso, como ha comentado Recap, tanto si te decantas por la conexión RGB-HV como por la SCART, no creo que tengas mayores problemas para hacerte con un cable ya fabricado. Para la conexión VGA-SCART específicamente, hay gente que los fabrica y envía por un módico precio. Ten en cuenta que los VGA-SCART que venden en tiendas de electrónica *no sirven* para nuestros propósitos, porque están pensados únicamente para uso en proyectores.

También estoy de acuerdo con Recap en que posiblemente sólo acepte señales de 15,7 KHz, al menos por la entrada SCART.

En cuanto a la pregunta de Recap sobre los monitores trifrecuencia, lamentablemente no dispongo de ninguno para hacer pruebas. Estuve dándole vueltas al asunto de adaptar el "configurador" para estos monitores. El caso es que desconozco si el comportamiento de los monitores trifrecuencia es continuo para todo el rango de frecuencias que admiten (15,7/25,00/31Khz), o por contra (como intuyo que de hecho ocurre) funcionan a saltos, es decir, admitirían frecuencias cercanas a 15,7, también cercanas a 25,00 ó 31,00 Khz, pero no frecuencias intermedias, por ejemplo 18,00 Khz. Si lo primero fuera cierto bastaría con seleccionar el rango completo de frecuencias válidas en el "configurador" y quizá algún otro ajuste menor para hacerlos funcionar, pero me temo que esto no es así, y habría que ir a un enfoque distinto: considerar tres intervalos independientes de frecuencias, como si fueran tres monitores diferentes, cada uno con su rango útil de frecuencias. Este es el enfoque que usa AdvanceMame. Para ello sí que tendría que modificar sustancialmente el "configurador".

Como decía, el problema es que no tengo material para hacer pruebas. Por tanto, me preocupa liberar un programa que sea potencialmente peligroso sin haber hecho las pruebas oportunas. Especialmente, después de leer que hay monitores delicados que sólo aceptan ciertos modos de vídeo y que se dañan realmente, como este Pentranic:

http://www.starcab.net/ressources/docs/ … _29CGAVGA.

... el cual solo aceptaría estos tres modos:
560x240 CGA 15Khz
640x350 EGA 24.5Khz
640x480 VGA 31.5Khz

Una vía alternativa es modificar el "configurador" para generar soluciones ad hoc, de forma manual, el la que establezcamos los modelines específicos que queremos y la frecuencia deseada.

Saludos,

Calamity

Ir al foro: Hardware del vídeo y emulación avanzada

140 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Nixie, el creador de Winmodelines, ha sacado la versión 1.6, que según comenta en retrovicio ya permite manejar lo que llama resoluciones virtuales, es decir, se independiza la etiqueta de registo, de los valores de resolución en sí. Por ejemplo, podemos guardar variantes muy próximas de una resolución así: 320x240@60, 321x240@60, 322@240@60, etc (el sistema de "etiquetado" que usamos en xml2ini) sin que se solapen, como ocurría antes. Es una gran noticia, porque aunque xml2ini ya era compatible con Winmodelines, sólo lo era parcialmente, ahora ya podrán coexistir sin mayor problema.

Por lo demás, sigo trabajando en ampliar las opciones de xml2ini y Resviewer, espero tener pronto ya algo más presentable.

Saludos,

Calamity

Ir al foro: Hardware del vídeo y emulación avanzada

141 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Recap escribió:

¿Así que, si uno quiere--pongamos--desplazar levemente la imagen a derecha sin tocar el servicio, el modo más rápido es...?

Si te refieres a desplazar todos los modos hacia la derecha, la forma de hacerlo es aumentar el tamaño del margen izquierdo. Para ello hay que volver a generar los modos con xml2ini, aumentando los valores por defecto de BackPorch y BackPorchMin, por ejemplo a 8.0 y 7.8 respectivamente. Se puede ir probando a incrementarlos hasta dar con el punto.

Lo que ocurre con los ajustes horizontales es que son más bruscos que lo que nos gustaría. La razón es que, internamente las tarjetas de vídeo trabajan con "caracteres", que son un bloque de 8 píxeles. Entonces los saltos van de 8 en 8 píxeles, por eso son más bruscos cuanto más baja es la resolución horizontal.

En la vertical podemos ajustar con más precisión, porque las medidas se cuentan por líneas sueltas. La pega es que no podemos ajustar la amplitud sin recurrir a potenciómetro/menú-servicio.

Ir al foro: Hardware del vídeo y emulación avanzada

142 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Muchas gracias a los dos por los comentarios.

Sin estar seguro al 100%, creo que los problemas que comentaba de Daicon-X se deben a una pretendida mejora que introduje en el generador de modos, que para cada modeline calcula al menos 5 posibles combinaciones y se queda con aquella que devuelve un refresco vertical más exacto. Por esa razón algunos modos que podrían representarse con 15,7 KHz aparecen con 15,9 KHz, y parece ser que son los problemáticos. Quisiera introducir la opción de calcular los modos con un algoritmo más sencillo que evitara ese incremento en la frecuencia horizontal, a costa de sacrificar algo de precisión en el refresco vertical. ¿Entonces te ha ido bien simplemente poniendo la opción MonitorHorizontal = 0? ¿Consigues ver ahora sin problemas los modos a 57 Hz y demás?

Recap, a tu pregunta, comentarte que estoy detrás de conseguir algo muy interesante. Se trata de poder retocar las propiedades de los modos (centrado, geometría, etc.) en tiempo real, sin reiniciar el equipo, de forma definitiva. Una vez generados los modos con xml2ini, desde Resviewer, simplemente seleccionando un modo, se podrá desplazar a derecha o izquierda, arriba y abajo, mientras lo visualizamos en pantalla, y salvar los cambios. Algo parecido a lo que fue AdvanceMame. Todavía es algo experimental y no sé si funcionará en todos los sistemas.

En cuanto tenga algo de tiempo publicaré los avances.

Ir al foro: Hardware del vídeo y emulación avanzada

143 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Lo del Hyperspin debe ser porque al editar los modos con Winmodelines estás generando más de 160-161 modos, en ese momento el Hyperspin ya no arranca. En el xml2ini se limita el número de modos a la hora de generarlos, pero si luego se añaden más, aparece el problema.

Seguiré investigando tus modelines a ver si sacamos algo en claro.

Saludos y gracias

Ir al foro: Hardware del vídeo y emulación avanzada

144 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Daicon-X escribió:

Probé lo de la modeline (256x240@57,5) que me dijiste y nada, no funcionó, se veía igual.

Precisamente, se trataba de comprobar que NO funcionaba. Ese modo estaba generado con Winmodelines, por tanto el problema parece que es general.

Daicon-X escribió:

Lo que está claro es que ninguna resol a @57 la veo bien, las otras la inmensa mayoría se ven perfectas, salvo que a menos @ la imagn cada vez está mas desplazad hacia la izquierda o que se comen una linea o dos por arriba e incluso falta un trozo por la parte derecha de la última línea de la imagen (ejemplo 304x240@60).

El que la imagen se desplace a la izquierda es corregible. Cuando dices que faltan líneas por arriba, ¿sabes si faltan realmente o puedes hacer que aparezcan mediante el menú de servicio?.

La clave del asunto parece estar en los problemas con los modos de 57 Hz, modos que están a medio camino entre el PAL y el NTSC, ahora te cuento.

Daicon-X escribió:

Comprobando modeline a modeline he visto que hay resoluciones a @56 que se ven bien y en otras @56 que sale el defecto gráfico. Y en el caso de @57 en unas modelines el defecto grafico es mas acusado que en otras. Yo creo que el televisor si puede con cualquier modo per me imagino que habrá que cambiar algo de ini del xml2, encontrar los límites del tv supongo.

Me interesa mucho mucho que me pases uno de esos modelines de @56 que se ven bien.

Verás, he repasado concienzudamente los modelines que has ido poniendo aquí, desde aquellos que pasaste al principio. Cada vez tengo más claro que no se trata de un problema habitual de timing, que se pueda solucionar aumentando márgenes verticales, horizontales, longitudes de sync pulse, etc. Tampoco parece que el límite de frecuencia horizontal esté influyendo, porque has pasado modos a 15,7 KHz que tienen el problema, y esa es una frecuencia horizontal normalísima. Es más, en condiciones normales cabría esperar cambios en la imagen proporcionales a los cambios en los valores del modeline, y por lo que parece observas cambios bruscos o saltos que no se corresponden con ninguno de los parámetros del timing.

Creo que el chasis de tu TV está interfiriendo activamente en la imagen. Tengo la impresión que el chasis tiene alguna especie de procesador digital que espera únicamente señales PAL o NTSC, y las discrimina por un criterio basado en el número total de líneas. Los modos que caen en medio de los dos estándares, parece que la TV no sabe muy bien qué hacer con ellos, aunque esto es sólo una teoría. Podemos tratar de engañar al TV manteniendo el número de líneas de un modo que sí funcione, y variando la frecuencia de refresco. Para ello hay que forzar la frecuencia horizontal, y precisamente los modos intermedios 57-58 Hz son los más difíciles de cubrir ya que nos van a exigir frecuencias seguramente fuera de rango. Podrías probar estos modelines en sustitución de los otros que has puesto:

Modeline "320x240@50.0Hz 15.8KHz (50Hz)" 6.950 320 352 384 440 240 269 272 316 -hsync -vsync
Modeline "320x240@54.0Hz 15.7KHz (54Hz)" 6.890 320 352 384 440 240 256 259 290 -hsync -vsync
Modeline "320x240@56.0Hz 16.2KHz (56Hz)" 7.140 320 352 384 440 240 253 256 290 -hsync -vsync
Modeline "320x240@57.5Hz 16.7KHz (57Hz)" 7.330 320 352 384 440 240 249 252 290 -hsync -vsync
Modeline "320x240@57.6Hz 16.7KHz (58Hz)" 7.340 320 352 384 440 240 247 250 290 -hsync -vsync
Modeline "321x240@58.0Hz 15.5KHz (58Hz)" 6.820 321 352 384 440 240 246 249 266 -hsync -vsync
Modeline "320x240@59.6Hz 15.6KHz (60Hz)" 6.880 320 352 384 440 240 243 246 262 -hsync -vsync

Suerte y ya me cuentas.

Ir al foro: Hardware del vídeo y emulación avanzada

145 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Una información valiosísima, luego te comentaré algo de lo que creo que puede estar pasando. En cualquier caso, te pregunté anteriormente algo que es de crucial importancia: ¿has conseguido visualizar bien algún modo de 57 Hz en tu TV? No me refiero a estos sino a uno generado por otros medios, bien sea con Winmodelines, o como sea. Es decir, ¿estás seguro de que tu TV puede representar esos modos?

Ir al foro: Hardware del vídeo y emulación avanzada

146 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Muchas gracias.

Por los modelines que pasas parece que el problema no tiene nada que ver con la longitud del sync pulse como pensaba. ¿Has observado si las resoluciones que tienen el problema son las que tienen una frecuencia horizontal de 15,9KHz para arriba? Si es así, la solución estaría en limitar el valor HfreqMax = 15.800 y volver a generar los modos.

Para desplazar los modos hacia la izquierda has de incrementar los dos valores horizontales de en medio en el mismo valor (siempre múltiplos de 8). Los pongo entre corchetes:

Modeline "640x480_60,0Hz 15,8KHz (60Hz)" 13.990 640 [[708 777]] 888 480 481 483 525 interlace -hsync -vsync

Ir al foro: Hardware del vídeo y emulación avanzada

147 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Muchísimas gracias por las capturas.

Yo haría pruebas con un modo en concreto, por ejemplo el 257x240@57

Si calculo los modos con el timing de tu monitor:

    VerticalBlank = 1280
   
    FrontPorch = 4.42
    SyncPulse = 4.7
    BackPorch = 7.94

    FrontPorchMin = 4.30
    SyncPulseMin = 4.2
    BackPorchMin = 7.70

Me sale este modeline:

Modeline "257x240@57.5Hz 15.9KHz (57Hz)" 5.580 257 280 304 352 240 249 252 276 -hsync -vsync


Winmodelines genera este otro:

Modeline "256x240@57,5Hz 15,8KHz" 4.916 256 265 288 312 240 250 253 274  -hsync -vsync   

(Prueba a sustituirlo a ver si éste funciona: donde pone 256 has de poner 257 para que no haya conflicto con las etiquetas).

Si tienen el mismo problema, vuelve al generado por xml2ini y juega con los valores verticales, por ejemplo desplazando relativamente el sync pulse, el segundo y tercer valor de los verticales, incrementándolos en el mismo valor (con esto se desplaza la imagen verticalmente):

Modeline "257x240@57.5Hz 15.9KHz (57Hz)" 5.580 257 280 304 352 240 250 253 276 -hsync -vsync

Si no notas cambio, aumenta la longitud del sync pulse, para ello incrementas el tercer valor vertical respecto al segundo:

Modeline "257x240@57.5Hz 15.9KHz (57Hz)" 5.580 257 280 304 352 240 250 254 276 -hsync -vsync

Así sabremos si tiene algo que ver con los valores verticales.

Saludos

Ir al foro: Hardware del vídeo y emulación avanzada

148 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

Hola Daicon-X,

Me alegro de que te haya funcionado. Respecto al problema con los modos que no están a 60Hz, ¿has probado con éxito algún modo con ese refresco, generado por ejemplo con Winmodelines? Es decir, ¿estás seguro que tu TV es capaz de representar esos modos? En caso afirmativo, sería útil contar con ese modeline para examinar qué es lo que puede estar fallando.

Es que el que un modo salga desplazado puede ser normal y se corrige fácilmente, pero eso de que salga desplazada sólo la parte inferior ya es más extraño. Sé que es una faena pero si fuese posible contar con una captura de la pantalla quizá podría ver qué está pasando. ¿Ves diagonales de retorno sobre la imagen?

Ir al foro: Hardware del vídeo y emulación avanzada

149 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

He subido la versión corregida del driver más el configurador, el enlace de descarga sigue siendo el mismo:

Driver Ati Alternativo 2.0 + Configurador (Beta)

No he cambiado el número de versión ya que los cambios son principalmente depuración de errores. Las novedades son las siguientes:

- Opción "RotatingDesktop", que le indica al configurador que el escritorio se rota simultáneamente con el monitor, para que la orientación de los juegos verticales sea correcta (Recap, en tu caso tendrás que activar simultáneamente MonitorHorizontal = 0 y RotatingDesktop = 1 )

- He limitado de partida el número de modos a 160, dado que de esta manera no se producen conflictos con HyperSpin. Luego puede incrementarse con cautela el número de modos hasta 200 (creo que esta será la cifra definitiva). La cuestión es que el incremento de número de modos desde los 60 originales se consigue con mediante un hackeo poco ortodoxo del driver (parece que la memoria del driver se sobreescribe en alguna zona al ampliar la tabla de modos). En condiciones normales no he experimentado problemas con los programas que uso, pero es cierto que el HyperSpin no arranca. Hasta que esclarezca la causa de esto recomiendo limitar los modos a 160 si se encuentra algún problema.

- También he limitado de partida la frecuencia horizontal a 16,20 KHz, que parece que no da problemas con los Tvs convencionales. Luego el usuario puede probar a subir la frecuencia un poco, hasta encontrar el límite del monitor, ya que con ello se consigue mayor resolución vertical manteniendo los refrescos originales. En el caso del Hantarex 9110 he comprobado que el límite está entre 16,60 y 16,70 KHz.

- El driver es compatible con todas las tarjetas que soportaba el Catalyst 6.5 (todas las Ati que había por entonces):  Ati Radeon 7000, 7200, 7500, 8500, 9000, 9100, 9200, 9250, 9500, 9550, 9600, 9700, 9800, X300, X550, X600, X700, X800, X850, X1300, X1600, X1800, X1900, HD 2400, etc.

- ResViewer mejorado, la medición del refresco vertical no se activa automáticamente.

- El etiquetado de modos es compatible con Winmodelines, de forma que pueden retocarse los modos después de generarlos, para centrarlos, corregir geometría, etc.

Agradezco enormemente las pruebas que habéis realizado. En concreto soy consciente de los problemas de geometría que comentó Daicon-X, y veré que puede hacerse. Por cierto que si pruebas la nueva versión, no olvides copiar la configuración del timing que te funcionó, salvo el VerticalBlank que lo dejaría en 1280). Respecto al problema con el modo 640x480, he hecho pruebas y creo que pudo deberse a que las versiones anteriores del driver restringían todos los modos nativos. La nueva versión restringe todos salvo el modo 640x480.

Quiero seguir mejorando ResViewer para que permita editar los modos directamente. Incluso estoy viendo la posibilidad de editar la geometría de los modos en tiempo real, sin necesidad de reiniciar, al estilo de AdvanceMame, aunque todavía son experimentos.

Sobre lo que comenta Recap, de que modos muy parecidos exhiben comportamientos distintos, hay que tener en cuenta que para una misma resolución horizontal, el número de líneas en vertical puede ser muy variable para generar diferentes refrescos verticales. Esto hace que los márgenes puedan quedar descentrados en según que modos, si bien el algoritmo del programa intenta dejarlos centrados (al menos así ocurre en el Hantarex).  Luego está la posibilidad de que los TVs realicen algún tipo de auto-ajuste que tire por tierra los cálculos realizados, esto es algo que no he podido comprobar.

Ir al foro: Hardware del vídeo y emulación avanzada

150 Respuesta por Calamity

(139 respuestas, enviadas el Hardware del vídeo y emulación avanzada)

En teoría (no lo he probado), puede utilizarse el configurador tal cual para generar modos para monitores trifrecuencia, variando los parámetros de configuración. Habría que aumentar el valor ActiveLinesLimit, que por defecto está a 288, al valor que necesitemos. Este parámetro controla qué número de líneas progresivas puede representar el monitor. También habría que aumentar el valor HfreqMax, hasta la frecuencia horizontal que necesitemos.

Ir al foro: Hardware del vídeo y emulación avanzada