[Reparación] FixEight, no bootea

[Artemio]

A principios de Julio del año pasado adquirí esta placa descompuesta. Se trata de una Fixeight de Toaplan que me dijeron no encendía.

Sabía de la existencia del juego, pero nunca había visto video o jugado el título. Pero por el simple hecho de ser de Toaplan, una compañía a la que le tengo cariño, quería repararla y jugarlo.

Lo primero que se debe hacer al probar una PCB que no se sabe si funciona, o que está descompuesta, es medir la resistencia entre tierra y 5 volts, tierra y 12 volts y tierra y -5 volts. Esto con el fin de ver si no tiene un corto grave, para evitar dañar la fuente de poder o más componentes de la PCB misma.

En este caso, no había riesgo, así que procedí a lo primero: Hacer una revisión física. Y era evidente que tenía daño, posiblemente por una pequeña cantidad de agua y/o algún golpe en la zona de la ROM. Esto pintaba para ser una reparación sencilla.

Como se puede ver en la foto una pata de la ROM estaba dañada, posiblemente alguien trató de repararla. Procedí a limpiarlo y ponerle una pata de capacitor soldada por dentro como compostura. Después de eso realicé el dump de la ROM y la compare con romident de M.A.M.E.

006-ROMident.png (9.01 KiB) Visto 51829 veces

La ROM fuera del daño y una etiqueta maltrecha, no tenía problema. Pero la base sí tenía algo de óxido. Para evitar problemas decidí cambiarla:

Después de esto realicé la prueba de encenderla para ver si ese había sido todo el problema, pero no... la vida no es tan simple. La PCB seguía ofreciéndome una pantalla negra.

Lo siguiente fue revisar si había señales de reloj y actividad en el BUS de datos y direcciones. Esto se puede realizar con una punta lógica, osciloscopio, etc. En mi caso utilicé el osciloscopio para revisar las señales típicas: Bus de direcciones y bus de datos.

Para entender el porqué, les dejo este video de una plática que tuve oportunidad de brindar con respecto a arquitectura computacional básica, que trata de explicar todo lo esencial que se debe saber para reparar PCBs:



Me centré en los buses de datos y direcciones, así como la señal de reloj. Después de unos segundos casi todas las señales de actividad de la PCB se iban a “don’t care”, es decir el CPU se trababa y liberaba el BUS. Lo cual me complicaba el diagnóstico puesto que tenía que reiniciar cada prueba de pin en pocos segundos.


Para hacer esto más sencillo, decidí conectar el analizador lógico y revisar unas cuantas líneas más a la vez, además de su relación con el tiempo.

Es importante señalar que un analizador lógico, y más uno de bajo costo como el que tengo, no es una solución general que resuelva problemas. Sólo detecta valores lógicos, no muestra si las señales están bien o no, ni los voltajes reales. Sólo a partir de cierto valor es 1 o 0. Siempre es mejor revisar con el osciloscopio para esos detalles, pero para comparar un bus o ver los datos puede ayudar mucho… pero es laborioso.
Como sólo puedo analizar 16 canales a la vez, y de puras direcciones son 23 líneas, decidí conectarlo a las líneas más altas para saber que parte de la PCB se estaba accediendo a la hora de que el CPU se trababa.

El mapa de memoria de la PCB según M.A.M.E. es:

adrressmap.png (27.92 KiB) Visto 51829 veces

Es decir, va de 0x0 a 0x800000, lo cual implica A23 a A1 (dada esa dirección en hexadecimal, se necesitan 23 bits para representar 0x800000). Con 16 líneas lo ideal es cubrir de A23 a A8, con eso sabemos que cubrimos todo menos los dos últimos bytes.

Con esos datos comparados con el mapa de memoria de la PCB pensaba dar con el componente dañado, que suponía era la RAM principal o del CPU secundario que maneja al audio, inputs y otros aspectos importantes.

Por desgracia los resultados carecían de mucho sentido, incluso comparándolos con un dump de la ROM desensamblado en MAME para seguir la ejecución.

En ese momento no sabía cómo proceder, más que adivinando y probando los componentes. Seguía pensando que era la RAM, pero para comprobar me puse a probar las líneas de lectura y escritura de las memorias para saber cual se estaba escribiendo antes de que dejara de funcionar el CPU.

Bajo esa lógica, llegué a las RAMs MB81C78A en U67 y U68 (D4 y D5). Sin pensar mucho y esperando que se tratara de ello, decidí desoldarlas.
En retrospectiva fue una mala decisión, pues viendo la ubicación de as RAMs en la placa son memoria de video de algún tipo. El mapa de memoria indica que el CPU si tiene acceso a la memoria de toda la placa, pues está en el address space.

En fin las quité y las probé en mi lector de EPROMs, y para mi suerte estaba dañada:

025-RAM-BAD.jpg (39.9 KiB) Visto 51829 veces

Feliz de que posiblemente ya funcionaría me puse a buscar si tenía memorias compatibles. Y no, no tenía. Y las tiendas en línea de México tampoco tenían. Así que tuve que pedirlas a China y esperar un tiempo.

Ya con la RAM en mano, corrí a probar si eso hacía la diferencia sin haber probado nada más. Y pues, no arrancó el juego.
Así que tuve que seguir con el diagnóstico.

Revisando mejor el código de M.A.M.E. y basado en algo que había leído hace tiempo en los foros de shmups, me puse a revisar una memoria EEPROM 93C45. Esta memoria serial es utilizada para almacenar varias cosas, de hecho todas las variables de configuración del menú de TEST, ya que el juego no tiene dip-switches físicos. Pero un factor aún más importante es que almacena la información de la región del juego desde la fábrica. Es decir, el juego es una sola ROM para todo el mundo, pero la región se almacena en la EEPROM.

No existen esquemáticos de la PCB, pero hay de un juego relativamente similar que varía en arquitectura pero da una idea de la lógica de las placas en general de este hardware de Toaplan. El juego es Knuckle Bash. Esta referencia sirve para entender como se hace el direccionamiento, si están conectadas líneas de control del CPU, como es la lógica de control, etc. Aunque no sea idéntico y no tenga esta parte de la lógica para una EEPROM. Peor es nada, dicen.

Había visto que las direcciones más altas del juego, los bits de A20 a A23, entran a un 74LS154 en lugar de la configuración de Knuckle Bash con un 74LS138 y otras líneas de memoria más bajas. Pero es un diseño equivalente. Después de todo, ambos tipos de TTL son usados para decodificar direcciones.

Gracias a esto siguiendo los outputs del 154 pude ver por medio de continuidad a donde estaban conectados y con eso saber a cuál parte del código se podía estar accediendo. Debo acentuar que esto no era constante, era bastante errático pues en cada reinicio había variaciones.
Después de confirmar con el analizador lógico que sí se estaba accediendo a la 93C45 desde el CPU V25 directamente, decidí desoldar la EEPROM y probarla en el lector.

Y sorpresa, no funcionaba. Y evidentemente, no tenía la refacción… sin mencionar que ni siquiera podía encontrar la datasheet o alguna en venta. Nuevamente tuve que recurrir a un vendedor chino y esperar un buen rato.

Pero no me quedé de brazos cruzados, seguí diagnosticando un poco pues la PCB daba señal de video completamente en negro y las RAMs en la zona inferior izquierda de la PCB parecían no tener nada de actividad.

Esto me llevó a revisar la GAL16V8 ubicada en D20. Al comparar con el diagrama todos los outputs de la GAL daban salidas fijas, cuando su entrada se encontraba variando.

Nuevamente imaginé que esto podría ser todo el problema, y procedí a desoldarla con seguridad pues esto definitivamente podía ser grave.
Una PAL o como en este caso una GAL que es de propósito más general, son dispositivos que anteceden a los FPGA que cuentan con un arreglo de transistores programable. O más bien un arreglo de compuertas lógicas que puede ser configurado para funciones complejas. Imaginen que pueden definir cada una de sus salidas como una función de sus entradas establecidas.

Comúnmente se usaban para sustituir un número considerable de TTLs, principalmente como lógica de control o pegamento entre componentes de la computadora.

Pero si se encontraba dañada, ¿qué podía hacer? ¿Cómo saber cuáles son las ecuaciones que definen el comportamiento requerido en esta PCB, más si está dañada? No sólo eso, en caso de no estar dañada estos dispositivos están comúnmente protegidos contra lectura, así que no se puede hacer un dump directo.

Cuando empecé a hacer dumps para M.A.M.E. hace ya más de una década recuerdo claramente haber dumpeado PALs inocentemente, y sin revisarlas a nivel binario mandarlas a un developer de la época. Dicha persona de por sí tenía fama de mal carácter, y me regaño efusivamente por no revisar – en mi completa ignorancia – que los valores que había enviado eran inútiles.

Desde ese momento estaba consciente después de leer un poco que eran piezas clave y que su extracción no era tan trivial. Por eso hace algunos años que en el Dumping Union se liberó un método liderado por Charles MacDonald para replicar los contenidos de las PAL y GAL no registradas hice mi propio dumper. Les dejo el link por si se interesan en los detalles: http://techno-junk.org/readpal.php

Esto es un factor en el que M.A.M.E. rara vez es de ayuda, pues por desgracia no se concentra en hacer emulación de bajo nivel (aún). Es decir, sólo se hace la emulación a nivel CPU y datos. Todos los detalles de comunicación, control, manejo real de video y de audio se ignoran y se hace todo en alto nivel implementándolo en una tarjeta de video (frame buffer) o tarjeta de audio modernas. Es por esto que casi ningún dump de ROMs incluye las PAL, aunado a que la metodología para dumpearlas es limitada y relativamente nueva.

Por fortuna la amable gente de JAMMARCADE ha creado un repositorio de PLDs (PALs y GALs) equivalentes y probadas para reparar PCBs: http://www.jammarcade.net/pal-dumps/

Y mejor aún, la GAL de FixEight se encuentra documentada. De cualquier manea lo primero que hice fue tratar de leerla con mi versión del lector, y no funcionaba.

Así que grabe una GAL16V8 con el JED de JAMAMARCADE y la palca me recibió con una linda pantalla blanca. De momento no sabía si eso era mejor o peor que la pantalla negra que tenía antes, pero una revisión rápida de las entadas y salidas de la GAL en la PCB marcaron actividad que antes no había, y mejor aún todas las RAMS y los TTLs en la sección de video tenían actividad. Eso lo tomé como que definitivamente la GAL era un problema que ya estaba resuelto.

De momento restaba esperar a que llegara la EEPROM de China para confirmar la operación de la parte del CPU y audio, pero como tengo una PCB de Hishouzame descompuesta esperando reparación y ambas utilizan el CPU 68000, me puse a hacer algo que tenía muchas ganas de probar y que me daría en casos como estos una forma más de acuerdo con mi formación de probar ciertas cosas de una PCB.

Hace años viendo videos y leyendo bitácoras de reparación de PCBs arcade me enteré de la existencia del Fluke 9010A, un aparato que sirve para diagnosticar microcomputadoras al reemplazar el CPU. Se pone en un socket en lugar del procesador y permite realizar pruebas de direcciones, datos, ROMs, RAMs, líneas de control y demás monerías que facilitarían el diagnostico de PCBs Arcade como estas en algunas circunstancias.

El costo era muy elevado, y las piezas muy difíciles de conseguir. Sin mencionar que cada “pod” para sustituir a los CPUs es igual de difícil y caro. Ya tendrá unos 8 años que había querido uno de esos.

Con el tiempo nunca faltó fantasear con contar con un FPGA o algún dispositivo moderno de bajo costo que permitiera hacer lo mismo. Ha sido práctica común sustituir partes con FPGAs (Si no saben lo que es un FPGA, lo explico en la plática de preservación de hardware)



Así que en aquel entonces busqué para ver si no había una implementación similar. Incluso imaginé que tal vez alguien había hecho una soluciónen FPGA que se conectara a un CPU moderno y pudiera emular al CPU del juego desde la PC, permitiendo hacer debug remoto y dar con el problema de manera más sencilla.

Por supuesto esa fantasía y la de tener realidad aumentada que indique pistas y diagramas de partes con pinouts están aún lejos de la realidad.
En algún momento soñé con de la posibilidad de emular un CPU en una Raspberry PI y conectarlo al BUS de una PCB. Pero eso no es algo viable por muchos factores, siendo el más inmediato la cantidad de pines de entrada y salida disponibles en ese dispositivo.

Ese día me metí nuevamente – después de años – a ver cuántos pines de I/O tenían los Arduinos actuales. Y cuál sería mi sorpresa, que ya soportan ¡54! De inmediato pedí un Arduino MEGA en Amazon que me legaría al día siguiente, y empecé a escribir código fuente tentativo de las cosas que necesitaría para por lo menos tratar de revisar RAM y ROM desde un Arduino.

Al día siguiente por la noche ya lo tenía funcionando con cables dupont, Kola-Loka, cinta de aislar y silicón:

El pequeño proyecto se llama Ghetto Fluke9010 por falta de un mejor nombre, y su código fuente está en este URL:

https://github.com/ArtemioUrbina/GhettoFluke9010A

De paso implementé al CPU Z80 por aquello de que se usa en Flying Shark, el código fuente es abierto y bajo GPL.
Emocionado, me tomé la libertad de compartirlo con la comunidad interesada, y me informaron que ya existía algo así liberado hacía pocos meses. Es un proyecto mucho más completo y serio, pues toma todas las líneas de control y no tiene las mismas limitantes que el mío., Pero requiere que se construyan PCBs custom para los PODs de cada CPU, y no una solución de tercer mundo como la mía. Acá les dejo su URL:

http://www.paulswan.me/arcade/ArduinoMegaICT.htm
https://web.archive.org/web/20180115201 ... egaICT.htm

Me puse a pulir y probar la Hishouzame, pues su CPU se encuentra en socket y el de Fix Eight se encontraba soldado a la PCB. De paso aprendí muchas cosas útiles con respecto a las señales de control y timming de lectura y escritura de valores de ambos CPUs. Eso será tema de otro post si es que algún día la termino de reparar.

Pero después de unas semanas, regresé a FixEight ya que habia llegado la EEPROM. Emocionado procedí a ponerla sin grabarle nada para ver si la inicializaba. Pero no, no le grababa nada. Supongo no llegaba a esa parte del código, pero tampoco tenía manera de saber si realmente estaban funcionando los controles y el código completo del V25. Así que procedí a grabarle los datos de NV RAM que están en MAME. Cabe señalar que hay una nota en el código, y efectivamente hay que realizar el proceso:

Código: Seleccionar todo

// note you may need to byteswap these EEPROM files to reprogram the original chip, this is the same for many supported in MAME.

Al cambiarlo el CPU tardaba mucho más en caerse, pero de todas maneras la PCB no booteaba.

Decidí entonces desoldar el CPU de la FixEight y meter mi probador con Arduino. Hasta este momento no tenía otra razón para desoldar el CPU que hacer estas pruebas. Pero en mi mente valía la pena.

Lo primero a probar con algo así es revisar el CRC de la(s) ROM(s). ¿Esto que implica? En primer lugar conocer la dirección de memoria y tamaño, que lo sabemos de M.A.M.E.

Código: Seleccionar todo

0x000000, 0x07ffff  AM_ROM

¿Qué es el CRC? Es una cifra que sirve como verificador sencillo de que – con alta probabilidad – los datos corresponden a la versión conocida de la ROM. De hecho el dato está en M.A.M.E. también y es uno de los usados para la función de romident, junto con el más confiable SHA1:

Código: Seleccionar todo

ROM_LOAD16_WORD_SWAP "tp-026-1", 0x000000, 0x080000, CRC f7b1746a SHA10bbea6f111b818bc9b9b2060af4fe900f37cf7f9

El amable lector se preguntará para que quería eso si ya hice el dump y verifiqué que la ROM es correcta. Y está en lo correcto, pero al hacer esta prueba sabemos si desde la perspectiva del CPU la ROM es idéntica. Es decir, si todas las pistas de direcciones y de datos, es decir el BUS de datos y direcciones, se encuentra bien. Así como TTLs que se encuentren en el camino y las líneas de control mismas hacia la ROM y de la lógica de control hacia el CPU.

Y bueno, la ROM, líneas de control, BUS de datos y direcciones y lógica estaban bien:

De paso conociendo las direcciones y tamaños de las RAMs realicé las pruebas pertinentes:

Algunas de las RAMs son de 8 Bits, y otras están detrás de latches por lo que no se pueden verificar escribiendo y leyendo.
Hay otras cosas que hice con mi tester que facilitan el diagnóstico desde mi perspectiva. El poder leer y escribir a direcciones específicas, pausadamente o “en cámara lenta” permite seguir la lógica y líneas de control para identificar los componentes involucrados. Claro, con la ayuda de una punta lógica u osciloscopio. Esto sirvió para identificar los componentes y zonas de la placa con direcciones

Pero había un caso en particular que fue muy importante. Al refinar el código para el Arduino e integrar la lectura y espera de la señal DTACK de CPU di con algo interesante.

En el 68K la señal DTACK es Data Acknowledge, y le dice al CPU que los datos que está por leer ya están listos en el BUS, o que los datos que escribió ya fueron almacenados. Claro que en una PCB arcade esto generalmente está truqueado y sólo es un retorno de la lógica de control, incluso a veces DTACK está conectado a tierra y siempre está prendida (es en negativo).

Pero en comunicación a otros CPUs o en RAM compartida la señal generalmente si es generada por un dispositivo externo. En este caso la RAM compartida con el V25 no estaba activando la señal DTACK y el CPU se quedaba trabado.

Código: Seleccionar todo

AM_RANGE 0x280000, 0x28ffff AM_READWRITE shared_ram_r, shared_ram_w

Con el Ghetto Fluke9010 esto lo indica en pantalla. Por supuesto lo podía haber revisado con el osciloscopio, pero no relacionado a la dirección de salida. Además de que aparentemente a veces si se generaba y a veces no. Pero en una prueba de toda la RAM en la zona siempre fallaba.

Esto me llevó a revisar con continuidad de donde se generaba a señal, y pues resulta que no había continuidad. No venía de ningún lado. Es decir, había una pista rota. Siguiendo desde el V25 visualmente y por continuidad, vi que la señal debía pasar por bajo de la ROM de código cuyo socket había cambiado.

Por allí abajo. Y sí, se alcanza ver que unas pistas no están en perfecto estado… pero al quitarlo:

Y de paso quité el 73LS153 que estaba junto para poder trabajar mejor. Acá el daño más de cerca:

Y la reparación:

Procedí a soldar sockets, poner todo de nuevo en su lugar y probar de nuevo.

Para mi sorpresa, la placa seguía sin bootear.

Al revisar de nuevo todo parecía seguir más o menos igual, aunque ahora si regresaba el DTACK y el Arduino no se quejaba.

¿Qué podía estar mal? Bueno el CPU ya lo tengo en socket… ¿qué tal si pongo otro CPU?

Pues sí… el 68K aunque generaba señales en los buses de datos y direcciones estaba mal. La maldita placa booteó y pude ver el mensaje de copyright de TOAPLAN.

Pero, de inmediato se metía a TEST y comenzaba a apretar todos los botones. Lo primero que pensé es que un 74LS273 debería estar mal y sería ya algo sencillo. Pero no nos adelantemos.

El CPU estaba mal y generaba las señales. Eso explica porque al usar el analizador lógico las direcciones por las que andaba eran erráticas. Y porqué a veces llegaba a una parte y a veces no, y porque se caía tan rápido. Lección: siempre probar el CPU en otra PCB de ser posible. Aunque en este caso siempre había otra falla, por lo que nunca lo había hecho y porque había señales coherentes.

En fin, a buscar ese 74LS273.

Oh sorpresa, no recordaba que esta placa y otras de TOAPLAN de la época son famosas por usar un integrado custom llamado HK-1000 de cerámica que de estar dañado no hay mucho que hacer. Y ese HK-1000 es justamente encargado de la salida final de video y de todos los inputs.

Hace mucho había leído que esto mataba varios proyectos, pero de cualquier manera releí los viejos threads. Sin embargo había esperanza… para mi buena suerte el buen Caius de JAMARCADE acababa de liberar su proyecto de ingeniería inversa y reimplementación del HK-1000

http://www.jammarcade.net/toaplan-hk-1000-reproduction/

Ya estaba yo dispuesto a pagar por un reemplazo hecho por él, pero antes de eso quise tratar de ver si no era algo simple en la pieza ya que había comportamiento errático si la presionaba ligeramente por una esquina. La desoldé y me dí a la labor de ir descarapelar la cobertura por lo que se sintió como un par de horas.

Pues resulta ser que posiblemente por algún golpe había un falso en la esquina, y refluir a soldadura fue todo lo necesario. Si, no quedó muy estético, pero funcionó y por fin pude ver el title screen del juego:

La verdad es que no lo podía creer. Estaba funcionando. Me quedé viendo el title screen y el demo por un rato, sin darle start por la incredulidad. Y porque el monitor donde pruebo no está en vertical.

Después de jugarlo el juego me encantó, y pues ya se había ganado tener sus patitas, su bolsa anti-estática, desecante y una caja:

Y por supuesto, su adaptador para jugar de tres jugadores simultáneos:

[pogo8bit]

¡Que odisea!. Admiro tu paciencia y dedicación a cada proyecto que inicias, la verdad es que se leen bastante frustrantes cada uno de los stoppers que te fuiste encontrando, aunque por otro lado ese es el chiste de las reparaciones.

Además también sirvió como detonante para tu contribución con el "debugger" Ghetto Fluke9010 (genial el nombre que elegiste ), que seguro le será de mucha utilidad para otros lectores. Me pondré a ver con detenimiento tu video de Preservación de hardware y software para entender un mayor porcentaje de lo que acabo de leer.

Felicidades de nuevo por tener tu placa funcionando, la verdad es que el juego se ve increíble y seguro para 3 jugadores aún más!

Saludos y gracias por compartir tu experiencia.

[lugerius]

Que gran documento. Tenía rato esperándolo para leer la implementación y uso del Ghetto. Una gran herramienta para diagnosticar. Seguro lo voy a implementar a ver qué tal me va.

¿Que tal las esperas a que lleguen los repuestos de China?.

Igual la herramienta para hacer los dump de las PAL, muy interesante.

En fin, después de toda esas largas esperas, cambios de piezas, reparación de pistas, diagnósticos acertados y errados el juego finalmente arrancó. Felicidades.

[Artemio]

¡Que odisea!. Admiro tu paciencia y dedicación a cada proyecto que inicias, la verdad es que se leen bastante frustrantes cada uno de los stoppers que te fuiste encontrando, aunque por otro lado ese es el chiste de las reparaciones.

Por cada uno que termino hay unos 5 que están incompletos.. pero sí, ayuda a practicar a paciencia y pensamiento sereno. Son los mejores aliados.

Además también sirvió como detonante para tu contribución con el "debugger" Ghetto Fluke9010 (genial el nombre que elegiste ), que seguro le será de mucha utilidad para otros lectores.

Es la idea. Aunque hay cosas mejro hechas, esta puede ser funcional el paises como el nuestro.

Me pondré a ver con detenimiento tu video de Preservación de hardware y software para entender un mayor porcentaje de lo que acabo de leer.

Cualquier duda acá estamos =)

Que gran documento. Tenía rato esperándolo para leer la implementación y uso del Ghetto. Una gran herramienta para diagnosticar. Seguro lo voy a implementar a ver qué tal me va.

;me comentas que tal te va. Debo confesar que leer tu reparación de Final Fight me impulsó a seguir escribiendo esta. Me daba mucha flojera hacerlo, pero entre más tiempo pasara más difícil iba a ser.

¿Que tal las esperas a que lleguen los repuestos de China?.

Con envío express, unos 5 días.. en burro, un par de meses. Y así al diferencia de costos también.

Igual la herramienta para hacer los dump de las PAL, muy interesante.

Sí, no sirve en muchos casos, pero cuando sí funciona es una salvación.

Gracias a ambos! Saludos

[Cyrox]

Hay mucho que no entiendo sin embargo me llena leer este tipo de post. Yo soy igual de persistente (necio) al reparar equipo de cómputo, por esa razón entiendo el gran sentimientos que es lograr arreglar algo que los demas dan por perdido.

Gracias por las lecciones los conocimientos y tú dedicación.
Felicidades

Enviado desde mi SM-G955F mediante Tapatalk

[Srburns]

Me encanta la manera que documentas y explicas las reparaciones. Dicen que WhatsApp está matando a los foros ... con ese nivel de detalle no pasaría .

[Artemio]

Hay mucho que no entiendo sin embargo me llena leer este tipo de post. Yo soy igual de persistente (necio) al reparar equipo de cómputo, por esa razón entiendo el gran sentimientos que es lograr arreglar algo que los demas dan por perdido.

Sí, la terquedad es un factor improtante, pero tiene que estar balanceada por paciencia y mente fría. O se cometen errores. Gracias man!

Me encanta la manera que documentas y explicas las reparaciones. Dicen que WhatsApp está matando a los foros ... con ese nivel de detalle no pasaría .

Si hay algo de que la gente abandona los foros, pero y crecí con contenido compartido de esta manera. Libre, sin requisitos y compartiendo información. Me siento comprometido a ofrecer lo mismo con lo que crecí, y me da gusto hacerlo. Mientras pueda, el contenido seguirá abierto.

Mucho se dá por ignorancia o por practicidad, no se dan cuenta que en facebook/grupos es cerrado y todo se pierde.

[lugerius]

;me comentas que tal te va. Debo confesar que leer tu reparación de Final Fight me impulsó a seguir escribiendo esta. Me daba mucha flojera hacerlo, pero entre más tiempo pasara más difícil iba a ser.

Sí claro ya te contaré cómo nos va, Que bien, me da gusto que la de Final Fight haya servido de motivación y te hayas animado a escribirla, entre más tiempo pasa se van olvidando los detalles y se vuelve más tedioso.

Gracias a ambos! Saludos

Saludos

[Hackcell]

¡Santísima! En serio te dio guerra.