Dudas altamente tecnicas sobre "lightguns"

Hola, yo no tengo ni idea, pero a mí me pasa algo similar. Yo tengo la Lightphaser de MS, y la Justifier de MD.
Las dos pistolas las he probado en la misma consola, una MD1 con mod de Hz y región. Además con un flashcart Everdrive.
La pistola de la MS es mucho más precisa que la de MD.
No puedo jugar a los mismos juegos con ambas.

En el caso de MS, estoy casi seguro que he jugado a 50hz, y en el caso de MD a 60Hz. De todas formas a ver si pruebo entre hoy y mañana.
La TV es la misma, y el cable de vídeo igual, ya que juego desde la MD.

A ver si pruebo la el juego de MD a 50Hz.

Yo tenía (bueno tengo, pero sin crt ya no sirve de nada ), una compatible con la G-con de psx y tenía un cacharro que se conectaba a la salida de video. Yo jugaba indistintamente a juegos pal y ntsc y nunca noté ese tembleque que dices. Eso sí, una vez la conecté a una TV de un amigo que emitía a 100hz y se volvía loca.

@Sema81
Podrías decirme el modelo de la pistola que mencionas?

Supongo que la respuesta será que si, pero igualmente lo pregunto: ¿Tu consola es/era PAL? Me imagino que estaba modificada/chipeada, ¿incluia eso un mod de video? La verdad es que no tengo ni idea de en que consistía, dado que de aquella ni tenia PS1 ni entendia de ninguna cuestion tecnica, pero, me consta que hay mods de PS1, tanto independientes como integrados en el "chip pirata" que hacen algo a la salida de video para evitar el problema de la imagen en blanco y negro en muchas TVs de la epoca con los juegos importados. No se si el chip que tiene una de mis PS1 de segunda mano tiene eso, pero creo que no. Alguien sabe en que consistian esos PAL-mods de PS1? Que hacian exactamente? Cambiaban la codificacion de color, la frequencia de la portadora, los pulsos de sincronizacion...?

Lo que mencionas de la TV a 100/120Hz es esperable, si xD

Respecto a mi problema de "tembleque" y desviación... Realmente no resulta del todo injugable, pero es decepcionante y me gustaría poder solucionarlo.

@radorn Pues exactamente es esta:



La psx era el modelo segundo, el que tenía puerto paralelo pero ya no tenía las salidas rca detrás. En cuanto al chip poco te puedo decir, yo solo sé que funcionaba, pero ni idea de qué le hacía a la consola. Eso sí, necesitaba un cable rgb para ver los juegos ntsc a color, si no se veían en blanco y negro. De otras cosas más técnicas poco te puedo ayudar.

radorn escribió:1. Las frecuencias de refresco vertical y horizontal se definen por la frecuencia de los pulsos de sincronizacion presentes en las areas "no visibles" de la señal, y, aparte de la diferencia en su periodicidad (60/15750 o 59.97/15734.x para NTSC y 50/15625 para PAL) resulta que tambien tienen diferente POLARIDAD. No estoy seguro del todo de como funciona esto, pero creo que, basicamente, la señal tiene un nivel cero o nominal, y los pulsos de sincronizacion son positivos o negativos con respecto a ese nivel nominal. Las polaridades no son iguales entre NTSC y PAL. Es posible que la señal que produce la PS1 PAL funcionando a 60Hz no tenga la polaridad propia de NTSC si no que mantenga la de PAL, confundiendo a la pistola

Todo correcto menos lo de la polaridad: la señal de video en banda base tiene la misma polaridad en NTSC y en PAL: el pulso de sincronismo horizontal "baja" de nivel, de modo que su base es la tensión más baja. Lo que pasa es que en NTSC-M (la norma americana), en negro no es el nivel de blanking como en PAL, sino que el negro tiene cierto voltaje.
Lo de la polaridad a lo mejor te refieres al burst de sincronismo de color, que efecdtivamente, en PAL va cambiando entre 45º y 135º para alternar de fase y corregir las desviaciones de portadora de color, corrección que NTSC no tiene.

radorn escribió:2. Frecuencia de la portadora de color y codificacion de la señal. Dado que tanto NTSC como PAL son sistemas de color compatibles con blanco y negro, la señal basica es en blanco y negro, y "encima" se le añade una subseñal de color, encajada a una frecuencia determinada: 3.58MHz para NTSC y 4.43Mhz para PAL. Si el aparato receptor acepta color, la señal es separada y decodificada. Además de la frecuencia a la que es modulada, esta señal de color está codificada de forma diferente.
Para asegurar la sincronizacion entre la emisora de TV y el receptor, al principio de cada linea, detras del pulso de sincronizacion horizontal, se transmiten unos cuantos ciclos de la frecuencia de la portadora de color. Esto se llama "colorburst".

Sí, pero hay un fallo: la modulación del color en ambos casos es en cuadratura, por tanto es la misma modulación. Lo que cambia es el nivel de normalización del color U y V.

radorn escribió:Cuando he intentado hacer capturas de mi PS1 PAL corriendo a 60Hz con juegos NTSC, me he encontrado con que mi capturadora no tiene ningun modo apropiado para decodificar esta señal. El unico modo en el que CASI parece color, es modo "PAL-M"; O sea, que la tarjeta encuentra la portadora de color a 4.43MHz e intenta decodificar como si fuera color PAL, pero en vez de una imagen a color como es debido, obtengo "hannover bars", lineas alternas de color verde amarillento y violeta claro. Mi conclusion es que la codificacion de color es NTSC, pero la portadora es a 4.43MHz como si fuera PAL. Es posible que la pistola detecte el colorburst de 4.43Mhz y determine que la señal es PAL y, por tanto, intente traducir las posiciones de pantalla como si la señal fuese 50Hz y 625 lineas, cuando, realmente son 60Hz y 525 lineas.

Efectivamente hay modos mixtos: hay un modo PAL-M con 60Hz y 525 líneas con la subportadora de color cerca de donde la tiene NTSC pero con la alternancia de fase PAL, y PAL-M que es lo contrario, con 625 líneas y 50Hz pero con subportadora de color NTSC (sin alternancia de fase).

radorn escribió:3. Como resultado de la frecuencia de sincronizacion horizontal, la DURACION de una linea en NTSC y PAL es diferente. 64microsegundos exactos en PAL y 53.algo en NTSC. Si la pistola, como creo, determina la frecuencia de video mediante algun metodo diferente al de sincronizarse con los pulsos (o sea, los que explico arriba, detectando la polaridad de los pulsos o la frecuencia del colorburst) y estos le dan una informacion incorrecta, eso podría explicar tanto la falta de precision como el desvio hacia los lados.

En fin, todo esto es muy tecnico y especulativo por mi parte. Si alguien sabe del tema, que no dude en explicarmelo.
Pero, sobre todo... Que soluciones tengo a mi alcance? Yo preferiría jugar versiones NTSC de los juegos, principalmente por los 60Hz y lo de las barras negras. Tendré que comprarme versiones NTSC de las consolas o hay alguna solucion alternativa? O quiza todo esto son pajas mentales mias? Las pistolas que no usan entrada de video, no deberían verse afectadas por esto, pero, estarán limitadas a un formato concreto?

Venid a mi, expertos!

Bastante probable que el origen de tu problema sea exactamente ése. Las pistolas solían funcionar de esta forma:

1- El tubo catódico empieza a dibujar un campo (field) de la imagen en pantalla
2- La consola lanza un contador vertical y otro horizontal que lleva el control de en qué punto ha de estar el haz del tubo catódico, pero no está sincronizado a él; esto quiere decir que cuando empieza el field, pone los contadores a 0, cuando pasan 64 us (si es PAL) o 63,55 (si es NTSC) incrementa el contador vertical y resetea el horizontal.
3- Cuando apuntas con la pistola a la tele de tuvo, su sensor de luz da un máximo de luminosidad cuando el haz pasa justo por delante, momento en el que la consola determina los valores del contador vertical y horizontal para saber dónde está apuntando en pantalla.
4- Si la consola PSX que tienes es PAL, incrementará los contadores cada 64us, y se resetearán en una línea diferente, porque el campo dura 312/313 líneas en PAL, pero dices que tu juego es NTSC-U, por lo que quizá el polling que está haciendo para leer los contadores es incorrecto. También puede ser que, al ser NTSC, espere encontrar valores del contador vertical en el rango 0 a 262 (ya que cada campo tiene 262 o 263 líneas alternativamente), pero realmente el contador en PAL llega hasta 312/313 y el código NTSC del juego podría malinterpretar valores fuera del rango.
Pero probablemente el error esté en que la consola PAL la tienes modificada para sacar juegos a 60Hz, por lo que los contadores se resetean a frecuencia PAL (el horizontal cada 64us y el vertical cada 40 ms) pero la imagen que está saliendo es NTSC, por lo que nunca llega a coincidir dónde está el contador interno con la posición real del haz en el tubo catódico.

Y creo que esto no tiene solución, puesto que el hardware de la PSX es el que es, y dudo que se pueda hacer incrementar estos contadores a otra frecuencia diferente.

@magno
1: Con lo de la polaridad no me referia a la alternancia de fase de color PAL, no. Me referia a la polaridad de los pulsos de sincronizacion, que, segun me pareció leer una vez en algun sitio, tenian diferente polaridad en PAL y en NTSC. Pero no es un dato que tenga seguro, asi que si tu dices que no es asi, me lo creo. Suponiendo, pues, la teoria de la diferente polaridad de los pulsos segun formato, imaginé que podría ser usado por la electronica de la pistola como un indicador mas "barato" para determinar PAL o NTSC que contar la frecuencia de los pulsos, y que una señal no estandard podría causar confusión. Tambien habia leido algo de que el los pulsos verticales y horizontales suelen ser de polaridad diferente para diferenciarlos mejor, pero quiza no sea cierto.

2: Respecto a lo de la modulacion de los componentes UV, hasta tanto no llego. Unicamente me refería a que si decodificas PAL o NTSC como el formato opuesto los colores salen mal, especialmente debido a que uno tiene alternancia de fase y el otro no, lo cual explica las hannover bars que me salen en la capturadora cuando conecto la PS1 PAL con juego NTSC, que, por eliminacion, debe de producir algun tipo de señal de 60Hz con color NTSC en portadora de 4.43MHz, combinacion aparentemente no soportada por mi capturadora (Bt878) o DScaler (me ofrece PAL-BDGHI, NTSC-M, SECAM, PAL-M, PAL-N, NTSC-J, NTSC-50, PAL-60, y PAL-NC)

3: Respecto al proceso de funcionamiento que mencionas: Las pistolas GunCon y compatibles (las cuales son el caso que nos ocupa) aparte del cable que va al puerto de mandos en la consola, tienen tambien un cable que conecta la pistola directamente a la salida de video compuesto. Esto parecería sugerir que, de una forma u otra, la señal real de video es utilizada para sincronizarse con el tubo de imagen, y no confiar solamente en una aproximacion que la CPU de la consola pueda hacer, como parece sugerir tu proceso. Hay otras muchas pistolas que no tienen entrada de video directa y si deben hacer lo que dices tu, pero ese no parece ser el caso del "estandar" GunCon, no?
De las PS1 en las que probé todo esto en su momento, una venia con un chip "pirata", pero no creo que le haga nada al video, y las otras 2 estaban totalmente "virgenes", cargando el juego con el truco del cambiar discos al vuelo. Lo se porque las abri para limpiar (las cosas de segunda mano suelen venir muy guarras), y en las que digo que estan virgenes no habia ni chips ni cables puenteando nada; las placas sin tocar.
Tu mencion de que "probablemente el error esté en que la consola PAL la tienes modificada para sacar juegos a 60Hz" no tiene aplicacion ninguna cuando hablamos de PS1. Quizá estés pensando en Saturn, de la que no entiendo demasiado, pero creo que hay que modificar la consola para establecer el modo de video. En PS1, hasta donde yo se, igual que en N64, el modo de video lo establece el software. Cosas como la codificacion de color o la frecuencia de la portadora ya son otra cuestion: La N64 tiene color y portadora fijos, determinados por el DAC, y la PS1, por lo que he podido ver, parece tener la portadora fija, pero el tipo de color configurable(?), y de la Saturn ni idea.

Si tu conclusion final fuese acertada (que no digo que no lo sea, pero me suscita dudas), con todo eso de los contadores internos y las enormes diferencias entre ellos y el tubo... No deberia ser la imprecision mucho mas dramatica? No se, con tales desfases creo que cada vez que yo disparase, el tiro deberia acabar en cualquier lado de la pantalla, pero la imprecision no es dramatica como eso. Simplemente tiene un tembleque/jitter un poco exagerado al rededor de la zona a la que apunto, y que una vez calibrado el centro de la pantalla, el tiro se va algo mas a los lados de lo que deberia.

Esta es mi teoria:
1: La pistola recibie la señal de video compuesto no estandar (NTSC-443, por lo que parece) que la PS1 PAL produce al poner un juego NTSC.
2: Intenta determinar el formato usando algun indicador "facil", por ejemplo, la frecuencia del colorburst. Esto le indica, erroneamente que la señal es PAL.
3: Recibiendo la señal de video directamente, detecta los pulsos H y V, que le indican cuando empiezan los campos y lineas. Con cada pulso resetea un contador interno que cuenta "ticks". Estos serían de duracion fija, habiendo mas en una linea PAL (64us) que en una linea NTSC (~53us)
4: Cuando empieza una linea, empieza a contar ticks, y e informa de la posicion cuando detecta la luz, numero de linea desde el ultimo H-sync y numero de tick desde el ultimo V-sync
5: El proceso de calibrado está, creo, para corregir el retraso que introduce el proceso de decodificado del video compuesto, y, asi, tener una referencia de cuanto hay que corregir los valores.
(Probad a hacer lo siguiente: Conectad un DVD por SCART a una TV de tubo por un conector que acepte compuesto y RGB, y, en los menus del DVD, intentad cambiar el formato de salida entre compuesto/CVBS y RGB. En mi caso, con una TV trinitron, cuando cambio de RGB a CVBS en el DVD, la imagen, aparte de degradarse, se mueve ligeramente hacia la derecha, porque decodificar el croma debe introducir algo de retraso y la TV debe retrasar luma un poco para que coincida con croma)

Digamos que una linea NTSC dura 1000 ticks y una linea PAL dura 1200. El Centro nominal de la pantalla en NTSC podria ser el tick 275 y en PAL el 700. Este centro se convertiria en un punto 0 en un sistema relativo, NTSC teniendo posiciones entre -425 y +425 y pal de -500 a +500. Una vez calibrado el centro de la pantalla, apunto justo a medio camino entre el centro y la izquierda. La pistola registra 450ticks. Como la pistola cree que el video es PAL, resta 700 (el centro de la pantalla) a los 450, dando una posicion de -250, que si el video fuera realmente PAL, quedaría a un cuarto del plano horizontal de la imagen visible. Pero a 60Hz el 25% de la horizontalidad estaría en -212.5, y -250 queda mas hacia la izquierda. Esto parece coincidir con lo que experimento en la practica.
El tema de la precision podría explicarse si consideramos que la pistola, detectando PAL mediante el colorburst, espera el pulso H-sync cada 64us, pero le llega cada 53us, provocando una cierta inestabilidad.

Como siempre, todo esto son teorias mias que no tengo medios para probar, pero parece encajar mejor con lo que experimento que lo que tu has explicado. Claro que tambien podría equivocarme...

Me pregunto si se podría usar uno de esos circuitos de separacion de sincronizacion y darle a la pistola una señal C-Sync pura en vez de compuesto. Eso podría eliminar el problema de la mala deteccion por colorburst o impedir que la pistola funcione si quiera...

AÑADO: No se cuan fiable será la informacion, pero recordemos que @Sema81 con su P7K dice que no notó ninguno de los problemas que yo menciono al jugar juegos NTSC con consola PAL. Quizá esa pistola determinaba PAL o NTSC con otro metodo mas fiable y por tanto, no da posiciones PAL cuando el modo de video es NTSC... O quiza los problemas estaban ahi igualmente pero Sema81 no se dió cuenta xDD ahora que no tiene CRT ya no podemos confirmar nada...
En fin, en algun momento tendre que volver a hacer pruebas y usar juegos PAL tambien...

radorn escribió:3: Respecto al proceso de funcionamiento que mencionas: Las pistolas GunCon y compatibles (las cuales son el caso que nos ocupa) aparte del cable que va al puerto de mandos en la consola, tienen tambien un cable que conecta la pistola directamente a la salida de video compuesto. Esto parecería sugerir que, de una forma u otra, la señal real de video es utilizada para sincronizarse con el tubo de imagen, y no confiar solamente en una aproximacion que la CPU de la consola pueda hacer, como parece sugerir tu proceso. Hay otras muchas pistolas que no tienen entrada de video directa y si deben hacer lo que dices tu, pero ese no parece ser el caso del "estandar" GunCon, no?

La verdad es que el proceso que te he comentado de los contadores y tal es como funcionaban las pistolas en la época del Spectrum, NES y SNES, no conozco las de PSX y no sabía que iban conectadas también al video compuesto. En ese caso sí debe de usar el video para sincronizarse como sugieres.

radorn escribió:De las PS1 en las que probé todo esto en su momento, una venia con un chip "pirata", pero no creo que le haga nada al video, y las otras 2 estaban totalmente "virgenes", cargando el juego con el truco del cambiar discos al vuelo. Lo se porque las abri para limpiar (las cosas de segunda mano suelen venir muy guarras), y en las que digo que estan virgenes no habia ni chips ni cables puenteando nada; las placas sin tocar.
Tu mencion de que "probablemente el error esté en que la consola PAL la tienes modificada para sacar juegos a 60Hz" no tiene aplicacion ninguna cuando hablamos de PS1. Quizá estés pensando en Saturn, de la que no entiendo demasiado, pero creo que hay que modificar la consola para establecer el modo de video. En PS1, hasta donde yo se, igual que en N64, el modo de video lo establece el software. Cosas como la codificacion de color o la frecuencia de la portadora ya son otra cuestion: La N64 tiene color y portadora fijos, determinados por el DAC, y la PS1, por lo que he podido ver, parece tener la portadora fija, pero el tipo de color configurable(?), y de la Saturn ni idea.

No me refería a modificación física, sino que la PSX está funcionando en modo PAL pero el video esté saliendo en modo NTSC; desconozco cómo se pueden cargar juegos NTSC en una PS1 PAL, pero me parece sorprendende que todo se haga por software, me parece como muy "avanzado" para la época de PS1. En concreto me refiero a que el reloj maestro para generar el video es diferente en PAL y NTSC y la diferencia entre ellos suele ser unas fracciones con números primos muy jodidas para sacar un factor común como para que un PLL pueda ser programado por software y cambiar de una frecuencia a otra. Eso se hace hoy día con la gorra, pero metidos en el contexto de PS1 me parece bastante sofisticado y más sabiendo de dónde viene el hardware de la PSX.
Pero desconozco los entresijos del proceso de cambiar una PS1 PAL a una NTSC.

radorn escribió:Si tu conclusion final fuese acertada (que no digo que no lo sea, pero me suscita dudas), con todo eso de los contadores internos y las enormes diferencias entre ellos y el tubo... No deberia ser la imprecision mucho mas dramatica? No se, con tales desfases creo que cada vez que yo disparase, el tiro deberia acabar en cualquier lado de la pantalla, pero la imprecision no es dramatica como eso. Simplemente tiene un tembleque/jitter un poco exagerado al rededor de la zona a la que apunto, y que una vez calibrado el centro de la pantalla, el tiro se va algo mas a los lados de lo que deberia.

No, no, realmente el desfase sería poquísimo porque los contadores se suelen resetear al principio de cada frame, con lo que la diferencia no se acumula. Ten en cuenta que por cada línea acumularías 0,45 us de error (64us de una línea PAL y 63,55 us de una NTSC, no 53us, que es aprox. la parte activa sólamente; mira este link para salir de dudas ), que es relativamente poco y que se traduce en más o menos distancia en la pantalla dependiendo del tamaño de ésta.
Eso sí, según mi teoría, el desfase lo notarías más cuando apuntaras en la parte de abajo de la pantalla y mucho menos en la parte de arriba y algunos disparos podrían irse de madre si pillaras un borrado vertical.

radorn escribió:Esta es mi teoria:
1: La pistola recibie la señal de video compuesto no estandar (NTSC-443, por lo que parece) que la PS1 PAL produce al poner un juego NTSC.
2: Intenta determinar el formato usando algun indicador "facil", por ejemplo, la frecuencia del colorburst. Esto le indica, erroneamente que la señal es PAL.
3: Recibiendo la señal de video directamente, detecta los pulsos H y V, que le indican cuando empiezan los campos y lineas. Con cada pulso resetea un contador interno que cuenta "ticks". Estos serían de duracion fija, habiendo mas en una linea PAL (64us) que en una linea NTSC (~53us)
4: Cuando empieza una linea, empieza a contar ticks, y e informa de la posicion cuando detecta la luz, numero de linea desde el ultimo H-sync y numero de tick desde el ultimo V-sync
5: El proceso de calibrado está, creo, para corregir el retraso que introduce el proceso de decodificado del video compuesto, y, asi, tener una referencia de cuanto hay que corregir los valores.

Eso mismo que cuentas es lo que te decía yo, pero yo conocía ese proceso hecho por las consolas y no por la pistola. Es posible que la pistola tenga algún circuito de decodificación de video y detecte el formato erróneamente como dices.

@magno
No todas las pistolas de PS1 usan cable de video. Creo que en PS1 basicamente hay dos "formatos" de pistola. La Justifier de Konami, que no usa la señal de video, y la GunCon de Namco, que si usa video compuesto. El resto de pistolas, que generalmente son de fabricantes de accesorios que no desarrollan juegos, usan uno u otro estandard para ser reconocidas por los juegos existentes, y algunas, como mis Nyko Super Cobra, son compatibles con los dos formatos, GunCon y Justifier, e incluso tienen un conector doble que permite usarlas en PS1 y tambien en Saturn, donde supongo que se comportaran como la SEGA Virtua Gun (Stunner en USA).

La GunCon de Namco, con cable RCA saliendo del conector del mandos.


Nyko Super Cobra, con RCA y conector doble PS1 y Saturn


Hubiese dudado de la precision de la Nyko por ser 3rd party y comprada en USA, pero la GunCon, que es original y comprada localmente, hace exactamente lo mismo.

Respecto a lo de funcionar en PAL o NTSC o modificar la consola.
Aunque hay una cosa de la N64 que me confunde, y es que hay 2 cristales en la placa y no tengo muy claro para que, en general parece que solo uno es importante (tengo que estar diciendo una burrada enorme, pero bueno), y de el se derivan las frecuencias tanto del bus de la RAM, que determina tambien la frecuencia del RCP y de la CPU, como de bus del DAC de video. La frecuencia de este cristal es diferente y se le aplican divisores y multiplicadores diferentes para que, al final, para el bus de la RAM haya una velocidad cercana a los 500Mhz y en el bus de video una cercana a los 50Mhz pero de la cual, mediante divisores y multiplicadores, se pueda derivar la frecuencia de la portadora de color propia de cada region.
Como resultado de todas estas carambolas aritmeticas, la N64 NTSC obtiene su colorburst 3.58Mhz y la N64 PAL obtiene sus 4.43Mhz y un bus de RAM ligeramente mas rapido que la consola NTSC. Como resultado, algunos aspectos de algunos juegos, por ejemplo, las secuencias animadas de Turok3, sufren desincronizacion de audio cuando cargas juegos NTSC en consola PAL y viceversa, o las pruebas temporizadas de DK64 pueden volverse imposibles al correr el tiempo mas rapido de lo que deberia (o ser muy faciles al correr mas lento, dependiendo de la combinacion de ROM y consola).
Respecto a la señal de video, A pesar de que, segun creo, ni cuando todo esta bien conjuntado, se ajustan las frecuencias de video producidas por la consola a los estandares correspondientes; ciertamente, si usas ROMs de un formato en la consola del formato contrario, la desviacion de las frecuencias es mayor si cabe. Si bien es posible que ni la N64 PAL haga 50Hz exactos, la N64 NTSC con ROM PAL aun se desvia mas de los 50Hz que la PAL, y lo mismo con la combinacion opuesta.
La cuestion es que el DAC, si bien tiene una portadora de color fija derivada de la frecuencia del BUS, la frecuencia de los pulsos de sincronizacion no es fija, si no que cada pulso es señalizado por el RCP a traves del BUS de video de forma similar a como transmite cada pixel RGB. El DAC solo tiene que producir los pulsos que manda el RCP, el cual es totalmente programable, asi que hackeando el codigo necesario en el RDP y el VI, teoricamente podria uno producir cualquier formato imaginable. Eso si, el pixel clock del bus es fijo y en terminos realistas, solo podrías ir hacia abajo en resolucion. O sea, que no se pueden hacer 640x480p porque el bus solo tiene ancho de banda suficiente para los pixeles necesarios para 640x480i a 60Hz (o 640x576i a 50Hz). Pero, quiza, de alguna manera, se puedan hacer 320x480p o algo asi.

Respecto a PS1, dado que lo unico que impide correr al software de importacion es la proteccion de region, y una vez superada, mediante el medtodo que sea (chip, swap, PSIO...), la consola pasa a funcionar con el modo de video especificado por el software, deduzco que, en terminos generales, funciona de manera similar a la N64 en ese respecto... claro que, segun parece, el DAC tambien cambia la codificacion de video a NTSC o PAL segun el formato especificado... si bien, la frecuencia de la portadora de color parece estar sujeta al hardware, lo cual tiene cierto sentido. Asi como la N64 necesita un un cristal y un DAC diferentes para cada region, la PS1 quiza use el mismo DAC en todas las regiones, capaz de producir color NTSC o PAL segun lo pida el software, pero la frecuecia de la portadora es suplida por un cristal externo que variará segun la región. Y por eso obtengo lo que parece ser NTSC-443 jugando juegos NTSC en mi consola PAL y mi capturadora no lo acepta.

Y con respecto a la acumulacion del error. Como ya he dicho antes, lo unico que hay es un "jitter" considerable (pero no salvaje xD) en la mirilla, y desviacion lateral a ambos lados del centro de la pantalla, y, para responder a lo que dices, añado esto: La desviacion que observé no aumentaba hacia la parte inferior de la pantalla. Era siempre igual en el plano vertical solo se desviaba hacia los lados. Tendré que volver a probar en algun momento y confirmar que tampoco se desviaba hacia arriba ni hacia abajo, de lo cual no estoy seguro, pero lo que si te confirmo es que no habia variacion en la desviacion por ser la parte superior o la inferior de la pantalla.

Pero tienes razon, NTSC no tiene lineas de 53.3us. Me confundi con la duracion del video activo en BT.601 (DVD, DVB...), que samplea la señal de video a 13.5Mhz tanto para PAL como NTSC.
(13.5MHz / (15750/1.001) lineas por segundo) = 858 puntos por linea en NTSC, 720 de los cuales son video activo en el estandard.
(1segundo / (15750/1.001) lineas) = 63.5~us por linea, que divididos entre 858 pixeles totales y luego multiplicado por los 720 activos da 53.3~us de video activo por linea en un DVD y otros formatos basados en BT.601

Parece que esto tira por tierra mi teoria, dado que, a fin de cuentas, la diferencia de duracion de linea entre NTSC y PAL no es tan grande. 64 microsegundos exactos contra 63.5555~

¡¡NUEVA teoria mucho mas simple, y que probablemente sea correcta!!
La pistola SI detecta PAL y NTSC correctamente mediante el conteo de los pulsos de sincronizacion, o, quiza, informada por la consola a traves del conector de mandos, pero usa la frecuencia de la portadora de color para contar los "ticks" de la linea. Por tanto, en mi caso, informada por la consola o detectando los 60Hz verticales y/o los ~15734Hz (15750/1.001) horizontales mediante los pulsos, asume internamente que la linea deberia durar ( 3.58MHz / 15734 ) ticks, pero resulta que la portadora que recibe es de 4.43MHz.
Al igual que en mi anterior teoria que erroneamente asumia una diferencia de duracion de linea entre PAL y NTSC mayor de la que realmente hay, usando la portadora de color comoreferencia otra vez tenemos una cantidad de "ticks" por linea mayor de la esperada, causando la deviacion lateral.
Tambien esto podría explicar el jitter, a causa de que la alineacion entre los pulsos de sincronizacion y la portadora de color es diferente para NTSC y PAL, y, sin hacer los calculos, me imagino que los 60Hz y los 4.43MHz no deben alinearse de la misma manera que 50Hz con 4.43MHz o los 60Hz con 3.58MHz.

yo en dreamcast pal tengo la pistola,pal y el the house of the dead 2 japo y no he notado nada extraño,todo parece ir ok

radorn escribió:¡¡NUEVA teoria mucho mas simple, y que probablemente sea correcta!!
La pistola SI detecta PAL y NTSC correctamente mediante el conteo de los pulsos de sincronizacion, o, quiza, informada por la consola a traves del conector de mandos, pero usa la frecuencia de la portadora de color para contar los "ticks" de la linea. Por tanto, en mi caso, informada por la consola o detectando los 60Hz verticales y/o los ~15734Hz (15750/1.001) horizontales mediante los pulsos, asume internamente que la linea deberia durar ( 3.58MHz / 15734 ) ticks, pero resulta que la portadora que recibe es de 4.43MHz.
Al igual que en mi anterior teoria que erroneamente asumia una diferencia de duracion de linea entre PAL y NTSC mayor de la que realmente hay, usando la portadora de color comoreferencia otra vez tenemos una cantidad de "ticks" por linea mayor de la esperada, causando la deviacion lateral.

Eso que cuentas tiene bastante sentido; la mayoría de chips que conozco usan la frecuencia portadora de color para determinar el estándar de color, y si es 60Hz o 50Hz lo hacen con los pulsos de sincronismo horizontal.

radorn escribió:Tambien esto podría explicar el jitter, a causa de que la alineacion entre los pulsos de sincronizacion y la portadora de color es diferente para NTSC y PAL, y, sin hacer los calculos, me imagino que los 60Hz y los 4.43MHz no deben alinearse de la misma manera que 50Hz con 4.43MHz o los 60Hz con 3.58MHz.

Respecto a esto, ¿a qué alineación te refieres?
La alineación en tiempo de la posición del colorburst respecto al pulso de sincronismo es diferente en PAL y NTSC, por supuesto, pero es tan pequeña esa diferencia que no en la práctica no se puede usar para determninar el estándar.
La posición en frecuencia entre ambos estándares sí es diferente, porque una está a 3.58MHz y otra a 4.43MHz, pero en ambos casos, tendría que estar imbricada: eso quiere decir que la frecuencia exacta de la subportadora de color (con precisión infinita) tendría que ser un múltiplo exacto de la frecuencia de línea. Esto es así porque la estructura espectral de la señal de video analógico es peculiar; si usas un analizador de espectro con un BW de resolución muy estrecho, verías que la energía (contenido de luminancia) se centra en torno a múltiplos de la frecuencia de línea: 15625Hz, 2*15625Hz, 3*15625Hz.... Cuando años más tarde de crear el estándar de video en B/N se introdujo el color, se tuvo que hacer de modo que no interfiriera con esos "paquetes" de energia en el espectro que llevaban la información de luminancia, y a ser posible, meter el color en la parte alta del espectro donde están las frecuencias de la imagen B/N que peor ve el ojo humano. Por eso hay una relación tan estrecha entre la frecuencia de línea y la frecuencia de la subportadora de color.
En el caso que comentas, y viene a colación de lo que te contaba antes de los dos relojes para dar las frecuencias exactas, si con un reloj consigues la frecuencia exacta para una señal PAL, al crear la señal NTSC a partir de ese mismo reloj, habría que usar un PLL con una fraccionalidad de muchísima precisión para que el color quedara bien imbricado en la señal de luminancia, cosa que me parece improbable en la época de PSX.

El resumen de este rollo, es que efectivamente como dices, los 60Hz y los 4.43MHz no se imbrican correctamente mientras que 50Hz con 4.43MHz (PAL) o los 60Hz con 3.58MHz (NTSC) si se imbrican bien.

@crazy2k4 Se agradece el dato.
Pregunta: La pistola de DC tiene conector de video tambien? O funciona solo con el conector al puerto de mandos?

@magno
Algunas cosas que dices me superan, pero intentaré seguirte el ritmo xD
Como ya comenté, tengo 2 problemas
Uno es el desvio lateral. Cuando mas me voy del centro, mas se va hacia los lados, talqueasín:

La linea es hacia donde apunto, la X es donde la consola registra el impacto.
Segun creo recordar, no se desviaba hacia arriba y abajo.
El otro problema es que donde sea que se registre el impacto, hay un considerable "jitter". Esto se nota en pantallas, como la de calibrado o algun que otro menu, donde la "mirilla" es visible todo el tiempo, claro; porque durante el juego normal no se espera que la pistola registre nada hasta que aprietas el gatillo y el juego flashea la pantalla en blanco.
Me consta que un cierto jitter es esperable en cualquier pistola de luz, pero por lo que he podido ver, en mi caso es mas pronunciado, y pasa igual con la guncon original que con las 3rd party, y en cualquier TV que probé en su momento.
Y de esto es lo que hablo cuando menciono lo de la alineacion entre chroma y los pulsos de sincro. Si la señal fuera estandar, habría una alineacion clara entre sincros y croma para la que la pistola estaría calibrada. Pero al ser una mezcla rara de frecuencias, la alineacion esperada se va al garete, y, pienso yo, esa divergencia entre expectativa y realidad podría ser la causa de que mi mirilla "tiemble" de mas.

AÑADO: Oficialmente, la frecuencia de las portadoras de color no es un multiplo exacto de la sincro horizontal.
NTSC 227.5 ciclos de croma por linea (sincro cada 2 lineas)
PAL 283.75 o 283.7516 (sincro cada 4 o 15625 lineas)

Valores de frecuencia portadora sacados/calculados de Wikipedia:
NTSC 315/88 MHz = 3.5795454545454545454545454545455 --> 227.5 ciclos por linea
PAL (283.75 x 15625) + 25 = 4433618.75 --> 283.7516 ciclos por linea - sincronizacion cada 15625 lineas, o 1 segundo completo...
sin los +25, puestos "para evitar interferencias", sincronizan croma y h-sync cada 4 lineas

radorn escribió:AÑADO: Oficialmente, la frecuencia de las portadoras de color no es un multiplo exacto de la sincro horizontal.
NTSC 227.5 ciclos de croma por linea (sincro cada 2 lineas)
PAL 283.75 o 283.7516 (sincro cada 4 o 15625 lineas)

Valores de frecuencia portadora sacados/calculados de Wikipedia:
NTSC 315/88 MHz = 3.5795454545454545454545454545455 --> 227.5 ciclos por linea
PAL (283.75 x 15625) + 25 = 4433618.75 --> 283.7516 ciclos por linea - sincronizacion cada 15625 lineas, o 1 segundo completo...
sin los +25, puestos "para evitar interferencias", sincronizan croma y h-sync cada 4 lineas

Dije que eran un múltiplo exacto de la frecuencia de línea, no un número entero. Es un múltiplo exacto para que un filtro de peine pueda extraer las componentes de luminancia imbricadas en los múltiplos de la frecuencia de línea y no se cuele residuo de portadora de color en dicho filtro de peine. Si la frecuencia de la portadora no fuera exacta, algo de energía de la croma se metería en la luma y viceversa. Eso se llama cross-talk y ocurría en las corbatas a rayas de los presentadores de TV: la alta frecuencia de las rayas generaban una gran componente de alta frecuencia en la luma y se metía en la crominancia, y por eso aparecían unos colores verdosos y rosáceos en vez de las rayas de la corbata.

De hecho, por no complicar demasiado la cosa, he omitido un detalle: la imbricación implica que la subportadora de color ha de caer justo en la mitad de dos múltiplos enteros y consecutivos de la frecuencia de línea, porque si fuera un número entero realmente, caería en uno de esos múltiplos. Creí que no hacía falta explicar esto con tanto detalle porque estaba fuera de lo que se hablaba

Aquí tienes el estándar oficial y puedes ver lo que te digo:

Tabla de parámetros estándares analógicos

@radorn no no,la pistola de dreamcast solo se conecta al puerto del mando y ya,no tiene mas xD

@magno me has dejado KO, macho.
Demasiada algebra para mi. No es que se me den mal los numeros, pero, mucho de eso, por una serie de desgraciadas circunstancias, nunca me lo llegaron a enseñar. La mitad de la notacion que aparece en esa tabla ni se lo que significa, y la otra mitad solo lo supongo, pero sin seguridad alguna. ains...
De todas formas me guardo la tabla en mi carpeta de datos tecnicos de video

Con respecto a todo eso de la imbricacion o alineacion... Todo eso es mas bien lo nominal, en el mundo real, es frecuente que las cosas se desvien dentro de un rango de tolerancias ya previstos en los estandares.
Las consolas, especialmente, incluso usandolas de la manera "oficial", sin importar juegos ni cosas asi, suelen tener "timings" con bastante variacion respecto al estandard. Y no hablo exclusivamente de los modos LDTV (240p y 288p), si no de frecuencias de refresco en general. Dudo incluso que haya muchas consolas anteriores a HDMI que se ajusten a los rangos de tolerancia oficiales de los formatos de video analogicos. Diría mas bien que tienden a estar fuera de rango, pero a las TVs analogicas no parece importarles demasiado y aceptan alegremente toda esta variacion. Tambien puede ser que esté diciendo tonterias... A mi me gustaría tener una buena lista de mediciones exactas de este tipo de cosas, pero supongo que la informacion, en los casos en los que exista, estará bastante desperdigada por internet adelante.

Lo que mencionas del crosstalk y las corbatas de rayas lo conozco. Los filtros que separan croma y luma de la señal de base se pierden un poco cuando hay contenido de alta frecuencia en alguna de las dos y queda algun resto de la señal de una en la otra. Los restos de altas frecuencias de luma en croma acaban produciendo colorinchos arcoiris y los restos de la portadora de croma en luma provocan puntitos donde el filtro no lo ha podido eliminar del todo (siendo las lineas verticales el ejemplo prototipico), resultando en el infame "dot-crawl".
Y si estas usando S-Video con un cable mal aislado, como el que tengo yo en la N64, croma se filtra en luma, y como ya no hay filtro separador (pues se supone que ya deberian estar separados) acabas viendo una imagen con punteado general, como si hubiese una especie de dithering pasado de rosca. Tambien luma se filtra en croma, pero el contenido de luma en N64 no suele ser de tan alta frecuencia como para causar colores psicodelicos, gracias a la baja resolucion y la interpolacion. En consolas sin filtros digitales de video como PS1 y Saturn si podria ser mas problematico tener un cable S-Video de baja calidad, me imagino.

radorn escribió:@magno me has dejado KO, macho.
Demasiada algebra para mi. No es que se me den mal los numeros, pero, mucho de eso, por una serie de desgraciadas circunstancias, nunca me lo llegaron a enseñar. La mitad de la notacion que aparece en esa tabla ni se lo que significa, y la otra mitad solo lo supongo, pero sin seguridad alguna. ains...
De todas formas me guardo la tabla en mi carpeta de datos tecnicos de video

Sí, impone mucho al principio, pero si te fijas en la columna de PAL BG, la mayoría de los datos ahí contenidos ya te los sabes y los has dado tú mismo en este hilo; además, se te nota que sabes del tema, seguro que te aclaras si lo miras en detenimiento. El parámetro que te decía de ver es "fsc", chrominance subcarrier freq.

Y si quieres algo más de información, dímelo, que yo trabajo diseñando chips de video en todos los estándares posibles, incluidos los analógicos, y tengo bastante info, algo desperdigada, eso sí,

radorn escribió:Con respecto a todo eso de la imbricacion o alineacion... Todo eso es mas bien lo nominal, en el mundo real, es frecuente que las cosas se desvien dentro de un rango de tolerancias ya previstos en los estandares.
Las consolas, especialmente, incluso usandolas de la manera "oficial", sin importar juegos ni cosas asi, suelen tener "timings" con bastante variacion respecto al estandard. Y no hablo exclusivamente de los modos LDTV (240p y 288p), si no de frecuencias de refresco en general. Dudo incluso que haya muchas consolas anteriores a HDMI que se ajusten a los rangos de tolerancia oficiales de los formatos de video analogicos. Diría mas bien que tienden a estar fuera de rango, pero a las TVs analogicas no parece importarles demasiado y aceptan alegremente toda esta variacion. Tambien puede ser que esté diciendo tonterias... A mi me gustaría tener una buena lista de mediciones exactas de este tipo de cosas, pero supongo que la informacion, en los casos en los que exista, estará bastante desperdigada por internet adelante.

Exacto, en las consolas de 16 bits de hecho el reloj venía de un cristal, así que las tolerancias al calor por ejemplo hacían salirse de la norma en muchos casos, sobre todo tras el envejecimiento del cristal.
Por eso insistía antes en lo de la exactitud en la imbricación: si a las tolerancias malas le añades que la subportadora de color no esté derivada correctamente de los 60Hz, podrían producirse los errores en la pistola que comentabas antes.

radorn escribió:Lo que mencionas del crosstalk y las corbatas de rayas lo conozco. Los filtros que separan croma y luma de la señal de base se pierden un poco cuando hay contenido de alta frecuencia en alguna de las dos y queda algun resto de la señal de una en la otra. Los restos de altas frecuencias de luma en croma acaban produciendo colorinchos arcoiris y los restos de la portadora de croma en luma provocan puntitos donde el filtro no lo ha podido eliminar del todo (siendo las lineas verticales el ejemplo prototipico), resultando en el infame "dot-crawl".
Y si estas usando S-Video con un cable mal aislado, como el que tengo yo en la N64, croma se filtra en luma, y como ya no hay filtro separador (pues se supone que ya deberian estar separados) acabas viendo una imagen con punteado general, como si hubiese una especie de dithering pasado de rosca. Tambien luma se filtra en croma, pero el contenido de luma en N64 no suele ser de tan alta frecuencia como para causar colores psicodelicos, gracias a la baja resolucion y la interpolacion. En consolas sin filtros digitales de video como PS1 y Saturn si podria ser mas problematico tener un cable S-Video de baja calidad, me imagino.

Exactamente

Una duda, el tener problemas de geometría en un monitor puede alterar el tema de la precisión? Lo digo pq he probado House of the Dead 2 con pistola oficial en una Dreamcast por vgabox a un monitor arcade 31khz el cual aún tengo que retocar la geometría y algunos disparos eran bastante imprecisos así como tampoco alcanzaba a disparar en los extremos de la pantalla.

Muy interesante el hilo, mis dies

@Samus de Arán
No pondría la mano en el fuego para decir que no, pero, dandole vueltas al tema, no veo en que manera le podría afectar.
La pistola no detecta la posicion de donde disparas por la posicion fisica del punto iluminado con respecto a la pantalla, si no comparando el momento en el "ve" la luz de la pantalla comparado con su temporizador interno (sea del tipo que sea, aqui hemos tratado 3, segun cuento yo). La señal de video es de tiempo continuo, y la posicion fisica del punto iluminado no cambia el MOMENTO en el que es iluminado. Incluso si la pantalla tiene una geometria tan fulera que hasta se ve la imagen ondulada, la cuestion es que la parte de la señal de video que esté activa en en el microsegundo 40 de la linea 137, va a causar que algun punto de la pantalla se ilumine en el microsegundo 40 de la linea 137 independientemente de si ese punto esta mas arriba o mas a la derecha en el area de la pantalla.
Ahora, bien, yo de DC, de sus multiples VGA-box's, y de monitores arcade que aceptan VGA, o los modelos concretos que tengas tu, ya no se. Igual algun componente en la cadena hace algun tipo de buffering no-lineal que afecta a la temporizacion de todos estos asuntos... No creo que deba haberlos, pero no tengo manera de saberlo.
De acuerdo con crazy2k4, la pistola de DC no tiene conexion de video como el de la GunCon, y quiza tu cadena de transmision introduzca demasiado lag (aunque lo veo improbable), desbaratando los intentos de sincronizar solo mediante la conexion por puerto para mandos sin acceder a la señal de video que el monitor usa...

Yo solo puedo teorizar con conceptos generales en este caso, quiza magno u otro sepan decirte mas.