radastan escribió:No sería mala idea que hicieras un post con el código fuente de la ROM que te has creado, que por cierto no hacía falta que la pusieras en el zócalo de la ROM original... para eso está el puerto de cartucho.
Ponerlo en el zócalo de la ROM original es más sencillo... ¡No hay que hacer ningún circuito! (al menos no ninguno de doble cara, claro). De hecho creo que puedo poner la Minerva sin tener que hacer el circuito de JL, sino directamente poniendo la ROM en uno de los zócalos, y el 74LS00 en zócalo de la otra ROM, cableándolo adecuadamente. Si lo consigo, postearé fotos
Por otra parte, creo que a la ROM de cartucho se la invoca desde la ROM principal, una vez que se ha testeado la memoria y el SuperBASIC ha alojado sus variables del sistema, por lo que si algo falla antes, el cartucho de ROM no entra en escena. Además, prefiero algo que desde el mismísimo principio de los tiempos, tome el control del sistema. He usado de hecho, esta misma filosofía para diagnosticar un Amstrad CPC464 y una consola Vectrex. En el caso de la Vectrex no he usado un cartucho ROM con el test, sino que he sustituido la ROM del sistema por la de mi test. En el Amstrad, que no tiene puerto de cartucho, pues sustituí la ROM de 32K por una con un test parecido al que uso en el Spectrum.
Respecto al código fuente, no puede ser más sencillo (ni más poco optimizado
). Ahí va:
Código: Seleccionar todo
ORG $0
dc.l $ffff ;Dirección de pila. No la uso.
dc.l start ;Dirección de comienzo de ejecución de la ROM.
start:
move.l #$18063,a0 ;El MCSR (Master Chip Status Register)
move.b #$08,(a0) ;Modo de 8 colores, pantalla #0, display ON
move.b #$aa,d1
move.b #$55,d2
OtraVez:
move.l #$20000,a1 ;Comienzo de la RAM de pantalla
move.l #$4000,d3 ;Contador de bucle de 4000 a 0000 inclusive (en cada vuelta se rellenan 2 bytes)
BucRAM:
move.b d1,(a1)+
move.b d2,(a1)+
dbra d3,BucRAM
eor.b #$ff,d1
eor.b #$ff,d2 ;Ahora pruebo con los valores complementados
jmp OtraVez
end start
Este código fuente lo paso por el Easy68K y lo ensamblo con F9, dándome un fichero S-record (.S68). Con un pequeño programa de línea de comandos, MOT2BIN, convierto el S-record en un binario, que flasheo a la EEPROM.
Para probar diferentes valores en pantalla, simplemente desde el propio grabador universal leo la EEPROM, cambio los valores iniciales que van a d1 y d2, y vuelvo a grabar. Usando el libro "Assembly Language Programming on Sinclair QL", concretamente el capítulo dedicado al video, compruebo qué debería ver en pantalla con la combinación que he escrito y lo comparo con lo que realmente veo (usando la salida RGB, claro). A partir de ahí es hacer cábalas.
En mi caso, lo que pasó es que veía la pantalla dividida en franjas verticales. Conté 16 franjas, así que como estaba en el modo de 256x256, pues cada franja consistía en 16 píxeles. Las franjas en posición par (0,2,4...) no se inmutaban cuando escribía en ellas con el programa, mientras que las impares sí cambiaban, aunque no mostraban la secuencia de colores esperada.
En el esquemático vi que los 16 bits del bus de direcciones (los 16 bits más bajos) se multiplexaban a través de sendos 74LS257. Ya conocía esta disposición porque es la misma que usa el Commodore 64. Si hay barras verticales que cambian y otras no, es porque a las que no, no les "llega" el dato, pero no puede ser culpa del 74LS245 porque si fuera así, no le llegaría a nadie, así que debe ser algo del direccionamiento, lo que significa, algo relacionado con los multiplexores. Hay dos, ¿cuál de ellos?
Pues como el "fallo" se produce cada 16 píxeles, veamos... según el libro mencionado, una palabra de 16 bits controla 4 píxeles en el modo de 8 colores, así que 4 palabras (8 bytes) controlarán 16 píxeles.
Para direccionar 8 bytes se emplean A0, A1 y A2. A3 es el que cambia de 0 a 1, y de 1 a 0 en cada franja de 16 píxeles. El multiplexor IC19 es quien se encarga de los bits de direcciones A0 a A7. Si a este multiplexor le llegara, por ejemplo, siempre A3=1, entonces nunca se pintarían las franjas pares. A3 viene directamente del 68008. ¿Está mal la CPU? No, porque direcciona la ROM correctamente, así que A3 debe llegar con su valor correcto al multiplexor, y salir de él siempre con un 1. Ergo, el multiplexor está mal.
¿Y el otro multiplexor? (IC20). Ese otro multiplexa los bits de direcciones desde A8 hasta A15. Si estuviera mal, no podría estar direccionando la RAM de pantalla bien. O no vería nada, o vería como la pantalla se rellena pero no en el orden esperado (de izquierda a derecha y de arriba a abajo). La cosa es que podía ver que se rellenaba, y en el orden correcto, así que descarté IC20.
Total, que después de estas cábalas me decidí por IC19, y ya está
El test de RAM de la Minerva daba fallo, obviamente, pero no podía ver ningún número en pantalla porque el fallo del multiplexor impedía que se viera nada legible en pantalla.
No es la primera vez que veo freirse un 74LS257. La otra vez fue reparando un C64, cosa que documenté (en inglés, sorry), aquí:
http://www.lemon64.com/forum/viewtopic. ... 6&start=23