deconstruyendo el video cartridge de Turbo Software

[vitoco]

Bueno, el difunto me parece suficiente como para identificar las diferencias con su antecesor, si es que hay otra distinta del contenido de la eeprom.

He estado pensando en meterme a programar un generador de video para grabar cintas compatibles, pero topo en 2 cosas, no tengo un cartucho para probar, ni un VHS para grabar. Mi reproductor se murió hace más de un año y en el servicio técnico se hicieron los web. Es más, cambiaron de dueño (y nombre) y eliminaron sobrestock de "repuestos". Y todavía tengo muchas horas de video que quiero pasar a medio digital!!!

++V

PS: supongo que el pelo no venía en la resina :lol:

[Walky]

Según wikipedia, los rayos X pueden borrar eproms, aunque no me quedó muy claro ya que primero dicen que bastan Rayos X para borrarlas... y luego dicen que se borraría con los rayos más exposición a altas temperaturas

De todas formas dudo que una "foto" dañe la información, el tiempo de exposición es mínimo. Además... si se dañasen con tal cantidad, seguramente la mayoría de los juegos basados en roms que uno se trajera del extranjero en avión (por ejemplo al viajar, o como encargo a un familiar) se dañarían en el aeropuerto (donde la exposición dura más). No sólo eso, sino que también se dañarían roms de otros equipos electrónicos como cámaras y demases, dejándolos potencialmente inservibles.

[ZZT]

Anoche me di cuenta, sacando el esquemático, que A12 esta a 1. Por consiguiente la EPROM 2764 (8K) debe tener el código duplicado dentro de los 8K. Al estar A12 en "1" solo toma en cuenta la información contenida de la mitad hacia arriba, ignorando los primeros 4KB. En consecuencia el código es de 4K solamente, bastaría con una eprom 2732 de 4K. Supongo que de seguro las 2732 ya eran obsoletas en esa época y por eso usaron una más grande y disponible en el mercado (la 2764 es de 8K) y de paso se comieron la mitad del contenido.

Si alguien analiza las rom que postie puede confirmarlo.

[Walky]

En otras palabras.. si A12 estuviese en 0 funcionaría igual (a no ser que el código no esté repetido en la primera mitad), ¿cierto?

[vitoco]

Analicé las ROMS (ambas versiones) y son 4 bloques idénticos de 2K respectivamente.

[Walky]

O sea con una 2716 están daos xD

Aunque a estas alturas seguramente es más barato usar 27c128 o 27c256 (mucho más fáciles de conseguir)...

[ZZT]

O sea con una 2716 están daos xD
Aunque a estas alturas seguramente es más barato usar 27c128 o 27c256 (mucho más fáciles de conseguir)...

Años atras compre 24 memorias 2732 en una feria y vieras como me han servido, sobretodo para reparar mis flippers que originalmente usan la 2716. Como las 2732 son el doble de lo que necesito les puenteo A11 a 0 y quedan plug & play.
Por cierto, en algunos comercios venden la 2732, pero vale más cara que la xuxa, incluso más que una 27C512 (64K). Mejor adaptar una de esas al toque.

En otras palabras.. si A12 estuviese en 0 funcionaría igual (a no ser que el código no esté repetido en la primera mitad), ¿cierto?

Exacto!

Analicé las ROMS (ambas versiones) y son 4 bloques idénticos de 2K respectivamente.

Ja! Tenía razón. Pero que raro que el código sea de apenas 2K, osea que XT5 esta en lo correcto al decir que de la eprom se traspasa al Atari una rutina que funciona solo como cargador o "loader". Por cierto, el encabezado de los archivos Binarios (no en basic) siempre empiezan con FF FF, tal como dijo XT5, y si el cargador busca el string "FIN" para terminar la carga y comenzar la ejecución del juego significa que efectivamente parcharon cada juego, ya sea de forma manual o automatizada, pero lo hicieron.

PD: los cartuchos de prisma funcionan así, me refiero a buscar un string especial. En este caso buscaba LVA, en referencia a Jorge Leo Varas quien fue el que hizo el loader de cartridge en Prisma (y el parchenegro??? o se fue en puro NHP???).

[Walky]

O sea con una 2716 están daos xD
Aunque a estas alturas seguramente es más barato usar 27c128 o 27c256 (mucho más fáciles de conseguir)...

Años atras compre 24 memorias 2732 en una feria y vieras como me han servido, sobretodo para reparar mis flippers que originalmente usan la 2716. Como las 2732 son el doble de lo que necesito les puenteo A11 a 0 y quedan plug & play.
Por cierto, en algunos comercios venden la 2732, pero vale más cara que la xuxa, incluso más que una 27C512 (64K). Mejor adaptar una de esas al toque.

Son la raja esas cachureadas, una vez fuí especialmente a cachurear eproms y pillé una caja con nueve 27c040 y una 27c020 destinadas originalmente a un equipo Cisco. El tipo dijo tener más pero lamentablemente la plata no me ayudó y no pude volver a comprar más (no estaban a precio de huevo, pero aún así estaban baratas).

[ZZT]

Revisado!

Cotejando el esquemático versus el circuito impreso del cartridge me di cuenta que A11 tb esta hacia 1, por lo tanto el código es de solo 2K. Por eso vitoco encontró copiado 4 veces el código en la memoria de 8K.

[vitoco]

Por cierto, el encabezado de los archivos Binarios (no en basic) siempre empiezan con FF FF, tal como dijo XT5, y si el cargador busca el string "FIN" para terminar la carga y comenzar la ejecución del juego significa que efectivamente parcharon cada juego, ya sea de forma manual o automatizada, pero lo hicieron.

PD: los cartuchos de prisma funcionan así, me refiero a buscar un string especial. En este caso buscaba LVA, en referencia a Jorge Leo Varas quien fue el que hizo el loader de cartridge en Prisma (y el parchenegro??? o se fue en puro NHP???).

Es curioso, alguna vez vi un cargador que se fijaba en el fin de archivo mirando datos, pero no recuerdo que fuese por un string, sino que era algo así como $FE $FE ó $7F $7F (sólo 2 bytes, como la cabecera).

Los cargadores habituales como el de 3 boot sectors ó el que se ponía en cassette sólo se fijan en el fin real del archivo para terminar y pasar el control.

En todo caso, los archivos binarios tienen una estructura simple y clara, en donde se cargan N bloques de X bytes de largo (independiente del factor de bloqueo de la fuente de almacenamiento). Cada bloque puede comenzar (no es obligatorio, excepto en el primer bloque) con $FF $FF, seguido de 2 bytes que indican la dirección de memoria de partida y 2 bytes más que indican el término, continuando con los X bytes de datos que van a dar a ese rango de memoria. Posteriormente se repite el proceso hasta que no queden más datos. Para pasar el control, tiene que venir un bloque de 2 bytes que parta en la dirección $02E0, cuya data indica la dirección en memoria donde partir (obvio que es alguna dentro de cualquiera de los bloques cargados). Sin embargo, si también había un bloque de 2 bytes que partiera en la dirección $02E2, apenas se cargaba ese bloque, se hacía un salto de subrutina a la dirección indicada (rutina de inicialización), esperando que retornara para continuar la carga del siguiente bloque (lo que podía generar problemas a la carga de cassette, solucionado en parte por los "pitos lentos"). Mmmm... recuerdo que los programas en assembler generados por el MAC65 tenían esta estructura de muuuchos bloques consecutivos de a lo más 256 bytes cada uno, y había que "repararlos" para acelerar la carga.

Cuando me dé más de un ratito, voy a mirar el contenido de las ROM, a ver qué consigo.

A propósito, respecto de respaldar el contenido de las cintas VHS en medio digital, se me ocurrió que un buen sistema sería con GIF animados, pues no pierden calidad, y se puede guardar frame a frame... el problema es capturarlos!!!

++Vitoco

[_Dx_]

A propósito, respecto de respaldar el contenido de las cintas VHS en medio digital, se me ocurrió que un buen sistema sería con GIF animados, pues no pierden calidad, y se puede guardar frame a frame... el problema es capturarlos!!!

++Vitoco

Vitoco, hay un codec llamado CorePNG que captura el video en una seria de imagenes PNG, tal vez sirva para tu proposito.

Saludos

[Walky]

¿Y simple AVI sin compresión?

El problema es que cualquier método sin compresión pesaría bastante. Lo otro es que las capturadoras suelen "promediar" cuadros que están juntos y eso podría causar problemas, además de que está la limitación de cuadros por segundo que sea capaz de capturar y las líneas no visibles que pueden causar bajo ciertas circunstancias que la copia salga con la imagen corrida o con otro tamaño y/o proporción en relación a lo que espera el cartucho.

¿El software copiado de cinta a cinta "a la antigua" carga correctamente?

[133MHz]

¿El software copiado de cinta a cinta "a la antigua" carga correctamente?

Al parecer no ya que en la historia original se menciona que todas las cintas producidas son masters! No creo que se hayan tomado esa molestia "por gusto".

Nuestro mayor desafio fue la grabacion del video. El problema que tuvimos era que si haciamos un master y reproduciamos este master en nuevas cintas la informacion perdia mucha calidad y las tasas de errores subian mucho por lo cual bajaba la tasa de seguridad en la carga.

Nos cabeciamos un buen tiempo para resolver que cada VHS fuera un original grabado directamente desde el computador, y al final lo logramos.

Coelsa tenia en stock el primer Hard Disk externo que existio para la marca Atari, y se lo compramos. Nos conseguimos una interfaz que permitia mediante el bus paralelo conectarlo a un computador 8 Bits y grabamos toda la informacion de los 300 juegos en el disco duro. Entonces hicimos un software de grabacion que leia los programas a medida que los enviaba a varios VHS obteniendose en cada uno de ellos la primera generacion del video osea masters en cada copia. Claro que era medio peligroso pues solo teniamos un Hard Disk y no era facil conseguirlos en esta epoca pero resistio muy bien a su trabajo.

[Walky]

Eso me pasa por no releer antes de preguntar xD

[xt5]

He estado pensando en meterme a programar un generador de video para grabar cintas compatibles, pero topo en 2 cosas, no tengo un cartucho para probar, ni un VHS para grabar.

hice bastantes pruebas para encontrar la manera mas eficiente de generar las barras, y al final consegui quedar con 50% de CPU libre.

aqui hay una captura, pinchandola se puede bajar un video lossless de esta carga


y aqui esta el xex que la genera http://www.ingenieria-inversa.cl/retro/ ... _test1.xex

ZZT, tienes el cart version 1 como para probar si carga?? en teoria deberia

estuve revisando el video que colgaron en atariware hace tiempo (donde carga el defender), y por lo que pude ver cada bloque pasa una sola vez y no hacen uso de la redundancia que el cart soporta.
ZZT, tu dices que el juego cargo antes de que pasaran todas las barras, pregunta: cargo todo el juego antes que terminaran las barras o solo salio una pantalla de carga?

lo de capturar en video digital tiene escasisimas posibilidades de funcionar, quedan descartadas de plano todas las capturadoras USB, y del resto solo se podrian utilizar las que capturan en crudo de verdad y que sus etapas de compresion (a no ser que sean lossless) se puedan deshabilitar, pero creo que estas caracteristicas las cumplen solo tarjetas profesionales, ademas que hay que contar con un software de captura decente.

preguntas para los entendidos en VHS: que calidad -en la media- tiene una linea VERTICAL en una cinta VHS??
por ejemplo al mirar esta captura, las delimitaciones verticales se ven muy turbulentas y quiero saber que porcentaje de eso lo aporta el VHS.



otra pregunta para los que en su tiempo hieron cargadores y cosas, cual fue la velocidad peak que se manejaba en esa epoca para lectura de medios?
en turbosoftware usaron un disco duro, pero que velocidad se podia conseguir con eso??