- Pantalla de arranque
En este caso, el reloj estaba perfecto, pero no había actividad alguna en las líneas de datos. Procedí a extraer la información de algunas roms para confirmar de que revisión del juego se trataba, y si se encontraban en buen estado. Era la revisión americana del juego y por suerte el manual del juego cuenta con los esquemáticos de servicio, que hacen mucho más fácil diagnosticar y revisar la placa. Debo admitir que no tengo más experiencia haciendo esto que la que detalla a continuación, y he ido aprendiendo sobre la marcha. Así que después de familiarizarme con la arquitectura de la placa, asumí que algo tenía que estar muy mal. Mis sospechas se confirmaron al encontrar imágenes de la PCB en línea... le faltaba una pieza:
- Mi PCB
- PCB Completa
- 1101503468.jpg (24.62 KiB) Visto 42590 veces
Con multímetro en mano me puse a confirmar las líneas de dirección desde el bus del CPU - controlado por un 74LS245 - hacia el conector, encontrando todas las direcciones, líneas de datos, la tierra y el voltaje. Apuntando todo en un papel, y después de confirmar en MAME los tamaños de las ROMS, decidí utilizar una 27c400, que aunque era del doble de capacidad de lo que necesitaba, tenía varias que uso pocas veces.
Realicé la relación de conexiones en una hoja de cálculo, y me día a la tarea de hacer una adaptación de lo que pensé podría ser muy sencillo.
- Adaptador 1.0
- 2-adapter1.0.jpg (59.92 KiB) Visto 42589 veces
- Adaptador 2.0
En otras palabras, las roms tsu_02b.1a y tsu_04b.1b entrelazadas un byte de cada una primero, seguidas por tsu_03b.2a y tsu_05b.2b. Emocionado corrí a probar mi nuevo Frankenstein, pero me recibió una pantalla muy similar llena de basura.ROM_LOAD16_BYTE( "tsu_02b.1a", 0x00000, 0x10000, CRC(cf965a0a) SHA1(ab88742a3225a0b82ee2dfef6ed0058d3e11c38c) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_04b.1b", 0x00001, 0x10000, CRC(c9884bfb) SHA1(7d10cedff0a62847f8deb61a9611cc6661efb037) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_03b.2a", 0x20000, 0x10000, CRC(4e157ae2) SHA1(cc02931376d22a7fcfc320e6fd4129e03a461a49) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_05b.2b", 0x20001, 0x10000, CRC(e66ca0f9) SHA1(a503badf2fed38786d38c313d1dc315f3175d6de) ) /* 68000 code */
Así que asumí haber hecho algo mal, esto debía funcionar. Con la continuidad del multímetro revisé una a una todas las conexiones. Todo estaba tal cual lo había diseñado en papel. Así que fue momento de saber si el CPU estaba recibiendo los datos que según yo debería. Con el fin de realizar esto, se me ocurrió medir con el osciloscopio cada una de las 16 líneas de datos del 68000, utilizando como referencia la línea de reset del CPU. Y visualmente determinar los primero bits que llegan por el bus al cpu. con los 16 bits podría saber los primeros dos words que le estaban llegando al 68000. Y eso hice, en parte por la curiosidad de saber si podía hacer tal cosa y en parte por saber si la teoría de lo que había hecho coincidía con la realidad, o confirmar que no entiendo nada de lo que intento hacer. remarco, que sigo en proceso de aprendizaje continuo de esto.
Lo que vi en el Bus fue 1111 1110 0000 0000 seguido de 0000 0000 0001 0000, o FE 00 00 10. Exactamente lo que debería estar allí porque es lo primero que hay en la ROM que entrelacé. Justo el pensar eso me hizo darme cuenta de la posibilidad de mi error. "¿Y si el endianness es al revés?", pero de inmediato asumí que esto tenía que ser como lo hice, había corrido el debugger de MAME y los datos aparecían exactamente en el orden que lso grabé en la ROM. Por otra parte yo sabía que el 68000 (Big Endian) tiene endianness inverso al 8086 (Little Endian). Sin nada que perder, grabé la ROM con los bytes invertidos. Y cual sería mi sorpresa, el juego mostró otra pantalla. Pero en este caso, una que me informaba que la RAM principal de la PCB no se podía leer/escribir adecuadamente:
- Work RAM
Durante mi tiempo de comida, decidí seguir el código del juego con el debugger de MAME, y así saber si realmente estaba probando las que había asumido eran las Work RAMs que cambié. No quería ponerme a desoldar RAMs aleatoriamente, con la posibilidad de causar más daño. Cabe resaltar que los diagramas claramente marcaban como /WRAM a aquellas que había cambiado, pero había mucha más RAM que al que indicaban las pruebas en toda la PCB.
Después de entender el código, confirmé que efectivamente esas eran las RAMs que se estaban probando. Ya en casa, probé si todas las líneas de control hacia la RAM se encontraban llegando bien, y así era. Revisé las líneas de datos y había ruido en ellas. Seguramente el lector que tiene más experiencia que yo en este momento sabe exactamente cual era el error, y sí lo confirmo. Mi adaptación de la EPROM estaba corrompiendo las líneas de datos, por una omisión mía. La línea de control de lectura de las ROMS estaba siempre activa en mi diagrama, y esto lo podía haber evitado de saber más o de haber estudiado el manual de la PCB con más detalle.
Resulta ser que en el manual se encuentra detallado todo el esquema de la placa C que había reconstruido, pero no en donde yo esperaba, sino más bien unas páginas más adelante. Y allí se detalla la línea de control y a que pin va. Como yo deje dicha línea en tierra en mi ignorancia, porque eso había visto en varias PCBs, la ROM alegremente respondía con los datos que yo mismo había puesto, durante la prueba de RAM pues se encontraban en el mismo bus.
Bien, procedí a corregir mi error, habiendo aprendido mucho gracias a ello. Y las sorpresas aún no terminaban:
- Sprites incompletos
[Esta entrada continuará]
