En busca del bug en el superupgrade

[wilco2009]

Estimados compañeros de fatiga del Superupgrade.

Si habéis montado con éxito el superupgrade os daréis cuenta de un detalle, las ROMs del +3 y +3e fallan en el arranque con frecuencia.

En el caso de la ROM del +3 el fallo es más esporádico, pero en el caso de las del +3e lo raro es que arranquen.

Estoy estos días un poco off-line de todos los foros porque ando buscando el problema.

Todavía no lo he resuelto, pero en el camino de hacerlo he resuelto algún otro que he descubierto.

A saber:

- Existe una incompatibilidad entre la decodificación del puerto $1FFD, que me sirve para cambiar el segundo bit de la página de ROM y el puerto $3FFD que curiosamente es el que se encarga de inicializar la controladora del floppy.
El problema está en que, aunque son puertos diferentes, como la decodificación que hago es parcial, sólo uso los bits A15, A14 y A1, que casualmente son idénticos en los dos casos.

Solución evidente, añadir el bit A13 que es diferente.

Cuando descubrí esto pensaba que ya tenía resuelto el problema del arranque, pero para mi pesar las ROMs siguen haciendo lo mismo. Es más, creo que el problema del +3e se ha agravado, aunque diría que la situación del +3 a mejorado algo.
Esto significa que aún hay otro problema que se me escapa. Lo que es seguro es que esto era un problema, y no sé ni como arrancaba el sistema.

Por si fuera un problema de intensidad en las señales, he pasado la selección de A15 (que corresponde con la del puerto $1FFD) por un biestable que me sobraba en el circuito, pero el resultado es exactamente el mismo.

¿En qué estoy ahora mismo?, pues con los fuentes de la ROM del +3, estoy poniendo cambios de color en el borde seguidos de esperas a pulsación de una tecla, para detectar donde me falla exactamente.

Tarea tediosa donde las haya, porque a la mínima se me cuelga el sistema, y cada nueva prueba significa modificar el fuente, quemar la ROM de nuevo y probar.

Hasta ahora he descubierto que el sistema me falla al llegar a la llamada a $3e80 con el parámetro $2410, que básicamente lo que hace es cambiar a la página 1 de la ROM para inicializar y mostrar las unidades de disco disponibles.

De hecho, he cambiado la llamada a dicha subrutina por NOPs y el sistema arranca con total normalidad, tanto en el caso del +3 como en el del +3e, por lo que voy acorralando el problema.

Como veis todo parece indicar un problema al inicializar las unidades de disco, pero me tiene confundido que siga sin funcionar al interpretar también el bit A13 en la decodificación del puerto.

Adicionalmente a lo anterior también he descubierto un problema de decodificación con el puerto $00FD que sirve para enviar caracteres al puerto de impresora, pero este no debería ser un problema mientras no utilicemos el comando LPRINT, por lo que lo voy a ignorar.

Soy consciente de que es un tema complejo, y que no puedo esperar mucha ayuda, ya que requiere dedicarle horas y sobre todo, tener el equipo para poder probar, pero os pongo esto para informaros de como va todo, y por si acaso alguien tiene alguna idea de por donde van los tiros.

Mientras tanto, sigo con el trazado del programa de la ROM y en busca del problema, aunque a partir de ahora se hace más difícil de seguir ya que hace varios cambios de página de ROM.

Os mantendré informados de los progresos.

[mcleod_ideafix]

Por si fuera un problema de intensidad en las señales, he pasado la selección de A15 (que corresponde con la del puerto $1FFD) por un biestable que me sobraba en el circuito, pero el resultado es exactamente el mismo.

Hay dos cosas que no entiendo de esto:
- A15 vale lo mismo tanto si quieres decodificar el puerto $1FFD, como el $3FFD, como el $7FFD, así que no sé qué significa lo de que se corresponde con el puerto $1FFD.
- Usar un biestable para reforzar la señal no me parece muy buena idea. Un biestable no es un buffer: sólo cambia su salida si hay un flanco de reloj. Si no, ya puede cambiar la entrada todo lo que quieras, que la salida no se inmuta. Exactamente ¿cómo has conectado el biestable?

Si de todas formas sospechas de señales de la CPU que no vienen demasiado fuertes, haz una cosa: coge, si tienes, un Z80 CMOS y ponlo en tu equipo de pruebas en lugar del Z80 NMOS original. La versión CMOS da unos flancos más limpios, rápidos y rail a rail (el Z80 NMOS a veces no llega ni a 3V cuando pone un 1 en alguno de sus pines).

[wilco2009]

Por si fuera un problema de intensidad en las señales, he pasado la selección de A15 (que corresponde con la del puerto $1FFD) por un biestable que me sobraba en el circuito, pero el resultado es exactamente el mismo.

Hay dos cosas que no entiendo de esto:
- A15 vale lo mismo tanto si quieres decodificar el puerto $1FFD, como el $3FFD, como el $7FFD, así que no sé qué significa lo de que se corresponde con el puerto $1FFD.

Disculpa pero creo que no me he expresado bien.
Efectivamente A15 tiene el mismo valor en la codificación de los tres puertos, aunque sigue siendo necesario para diferenciarlos de otros.
Cuando hablaba de que A15 corresponde con $1FFD no me refería a la decodificación, sino a la línea de salida hacia el chip de ROM.
O sea, que cuando detectamos un out en $1FFD cambiamos la patilla A15 de la ROM al valor que tenga D2.

- Usar un biestable para reforzar la señal no me parece muy buena idea. Un biestable no es un buffer: sólo cambia su salida si hay un flanco de reloj. Si no, ya puede cambiar la entrada todo lo que quieras, que la salida no se inmuta. Exactamente ¿cómo has conectado el biestable?

Aquí no tengo herramientas para hacerte un dibujo, pero puedo explicártelo textualmente.
He cambiado la salida de la GAL que decodifica la salida que va a la patilla A15 de la ROM, pasando a ser una señal de reloj para el biestable:

CLK1FFD = !NIORQ*!NWR*!A15*!A14*!A13*!A1*!DIS128;

La nueva señal de reloj la he conectado al pin de reloj del biestable, mientras que la patilla "D" del biestable la he conectado a D2.

Por otro lado la patilla "Q" la he conectado a A15 de la ROM.

Por último la patilla /RESET la he conectado a la patilla /RESET del biestable.

Si de todas formas sospechas de señales de la CPU que no vienen demasiado fuertes, haz una cosa: coge, si tienes, un Z80 CMOS y ponlo en tu equipo de pruebas en lugar del Z80 NMOS original. La versión CMOS da unos flancos más limpios, rápidos y rail a rail (el Z80 NMOS a veces no llega ni a 3V cuando pone un 1 en alguno de sus pines).

Probaré lo que dices. De todas formas me resisto a pensar que el problema esté ahí, porque solo me falla la paginación en ese punto de la ROM (cuando se inicializa el controlador de floppy) . En el resto de la ROM la paginación se realiza sin problemas.

[wilco2009]

Tras ardua búsqueda ya parece que tengo acorralado el problema.

He partido de los fuentes de del +3 de Garry Lancaster, que vienen para un ensamblador que no tengo, por lo que adicionalmente a los problemas ya comentados me toca modificar los fuentes para que compilen con PASMO.

He seguido la pista al cuelgue a través de la ROM0.

Hasta que ejecuta esta subrutina todo va bien:
call $3e80
defw $2410

Esta subrutina llama a la subrutina $2410 en la ROM1, que se encarga de inicializar la controladora de discos.

Una vez en la ROM1 va todo bien hasta que ejecuta:

call l3f00
defw DD_INTERFACE

Que llama a la subrutina DD_INTERFACE de la ROM2.

El contenido de la subrutina es el siguiente:

.l1f27 push bc
ld bc,$2ffd
in a,(c) ; read FD status register ($ff if no i/f)
add a,$01
ccf ; carry not set if no i/f
pop bc
ret

Por lo que parece ser que hay que implementar el puerto lectura $2ffd para que funcione sin modificar la ROM.

Realmente el tema se puede abordar desde dos enfoques:

- Implementando la funcionalidad del puerto $2FFD de tal manera que devuelva el valor correspondiente. Este método es complejo y habría que estudiarlo en detalle. Además haría falta meter aún más electrónica engordando el interface.

- Modificando ligeramente la ROM para que devuelva $FF en el punto donde consulta el estado de la controladora. En principio esto se centra en un solo punto y a partir de ese momento el ordenador se comporta como un +2A. Esta es la solución que he adoptado de momento, de tal manera que tendremos unas ROMs parcheadas para usar con el superupgrade actual.

Para el caso de añadir un interface de floopy compatible con las ROMs del +3, tendríamos que implementar obligatoriamente toda funcionalidad de los puertos $2FFD (lectura) y $3FFD (escritura) además de completar la funcionalidad del puerto $1FFD para el control del motor, y por supuesto volver a poner las ROMs sin parchear.

Concretamente la subrutina DD_INTERFACE de la ROM2 lo que hace es asignar el bit de acarreo en el caso de que el puerto $2FFD devuelva un valor distinto de $FF.
Después de eso, vuelve a la ROM1 y hace un salto condicionado al bit de acarreo para seguir comprobando qué unidades hay presentes, o bien ir directamente a mostrar sólo la unidad "M:".

Código: Seleccionar todo

        call    l3f00
        defw    DD_INTERFACE
        call    l32ee           ; restore TSTACK
        call    l2b64           ; page in page 0
        jr      c,l2463         ; move on if interface present
        ld      hl,l24c4
        call    l24b5           ; display " M:" if no interface

La modificación adoptada ha sido sustituir el salto por un par de NOPs. De esta manera siempre iría a mostrar la unidad "M:" directamente.

El siguiente paso será coger los fuentes que me ha pasado antoniovillena y buscar el punto adecuado para no inicializar la disquetera pero sí el interface IDE en el caso de las ROMs del proyecto +3e.

[mcleod_ideafix]

No creo que necesites implementar nada en el puerto $2FFD ni parchear las ROMs. Lo que necesitas es que si se lee en ese puerto, se devuelva $FF, para que la rutina al volver detecte que no hay controladora de disco y pase directamente a mostrar M:

La cosa es que en el Spectrum, cualquier puerto de E/S no implementado, devuelve $FF en lectura.

Si no es tu caso, significa que tu interface sí que está decodificando erróneamente esa dirección de puerto, o hay algún tipo de ruido en el bus de datos que hace que lo que se lea no sea $FF.

Como referencia, te diré que en el ZX-Uno no se decodifica ni el puerto $3FFD ni el $2FFD. Es más, ni me acordaba de estos puertos, y las ROMs del proyecto +3E funcionan sin problemas.

Con la ROM modificada para poder arrancar, si haces un PRINT IN 12285 (lectura del puerto $2FFD) deberías obtener siempre 255. ¿Es así?

[Scooter]

Igual el bus se pasea demasiado o uno de los circuitos gasta mucho. A lo mejor con unas resistencias de pullup en el bus, de alto valor para no cargarlo, suben un poquito y va...

Anbiao ende mi parato usando catacrak

[wilco2009]

No creo que necesites implementar nada en el puerto $2FFD ni parchear las ROMs. Lo que necesitas es que si se lee en ese puerto, se devuelva $FF, para que la rutina al volver detecte que no hay controladora de disco y pase directamente a mostrar M:

Exacto, para parchear y que funcione sin controladora es suficiente con eso, a eso me refería. Pero si quieres dejarlo preparado para poder conectar un interface de disquetera lo tienes que hacer de otra manera.

Con la ROM modificada para poder arrancar, si haces un PRINT IN 12285 (lectura del puerto $2FFD) deberías obtener siempre 255. ¿Es así?

Pues parece que has dado con algo, porque cualquier puerto no implementado del spectrum que intente leer me devuelve a veces $FF (la mayoría) y a veces $38, por lo que parece que algo falla con los bits 0, 1, 2, 6, y 7.

[wilco2009]

Igual el bus se pasea demasiado o uno de los circuitos gasta mucho. A lo mejor con unas resistencias de pullup en el bus, de alto valor para no cargarlo, suben un poquito y va...

Anbiao ende mi parato usando catacrak

Sí, es posible que esos valores de "1" estén al límite. Sería cuestión de comprobarlo con un osciloscopio.

[Scooter]

Lo que pasa es que si está crítico, igual conectas algo y va siempre. Recuerdo que hace años buscando una avería en un circuito digital, al poner un analizador lógico iba de PM.

Al quitarlo ya no iba, y salia muy caro dejar el analizador puesto.

Anbiao ende mi parato usando catacrak

[wilco2009]

jajaja, pues sí, habría que probar con ese analizador.

[mcleod_ideafix]

Exacto, para parchear y que funcione sin controladora es suficiente con eso, a eso me refería. Pero si quieres dejarlo preparado para poder conectar un interface de disquetera lo tienes que hacer de otra manera.

Si quieres hacer "hueco" en tu Superupgrade para poner una disquetera como opción, y que sea la GAL del Superupgrade quien la decodifique, no pasa nada porque decodifiques esos puertos, mientras no haya ningún circuito que responda a esa codificación. En ese caso seguirás viendo $FF. Si lo que quieres es permitir que otra tarjeta, que se conectara por ejemplo al expansor del bus del Superupgrade, haga las veces de controladora de disco, entonces tu Superupgrade no necesita decodificar esos puertos.

En cualquier caso, si tu Superupgrade no implementa un puerto de E/S, lo decodifique o no, la CPU debe ver un $FF.

Pues parece que has dado con algo, porque cualquier puerto no implementado del spectrum que intente leer me devuelve a veces $FF (la mayoría) y a veces $38, por lo que parece que algo falla con los bits 0, 1, 2, 6, y 7.

No, no pasa nada raro. Es que se me olvidó comentarte el efecto del bus flotante en los puertos no implementados. Y.... espera porque lo que he dicho antes igual me lo tengo que tragar.

A ver: en el +2A/B/3 no existe bus flotante, así que en esos ordenadores sí que es cierto lo que he dicho antes, de que un puerto no implementado debe devolver $FF. En esto se basa precisamente esa parte de la ROM que has mirado: en que de seguro que si no existe controladora de disco, el puerto $2FFD devovlerá SIEMPRE $FF.

Pero en el 48K/Plus esto no es cierto: si se lee el puerto $2FFD, a veces verás $FF, y a veces verás el contenido de lo que en ese momento esté leyendo la ULA, lo que habitualmente es un byte de atributo, y como seguramente estés usando la pantalla con los colores iniciales, ese atributo es flash 0, brillo 0, papel blanco, tinta negra, o sea, el 56 ($38). Eso es lo que estás leyendo.

Para descartar ruidos en el bus, haz esto:

Código: Seleccionar todo

10 PAUSE 1: PRINT IN 12285;" ";: GO TO 10

Ahora sí que deberías ver SIEMPRE un 255 en pantalla. El PAUSE 1 hace que la instrucción siguiente, el IN, se ejecute cuando la ULA aún está pintando el borde. En ese tiempo, no hay efecto de bus flotante.

Volviendo a la implementación hardware: sí, vas a tener que implementar un puerto de E/S para $3FFD y $2FFD que devuelvan siempre $FF, con alguna opción tipo jumper para deshabilitar esta opción en caso de que tengas algún periférico que implemente de verdad esos dos puertos.

En el ZX-Uno esto no fue necesario porque el efecto del bus flotante no lo implemento para cualquier puerto no usado, sino sólamente para aquellos de la forma $xxFF donde xx es cualquier valor de 8 bits. Para el resto de puertos realmente no implementados, ZX-Uno devuelve a la CPU siempre $FF.

[wilco2009]

Efectivamente siempre se ve 255.
Estás hecho un monstruo. jejeje.

La verdad es que estoy aprendiendo un montón sobre el spectrum con este prototipo que estoy haciendo.
A ver si me meto con una versión 2 con CPLD, que se me están multiplicando las GAL.

[mcleod_ideafix]

Efectivamente siempre se ve 255.
Estás hecho un monstruo. jejeje.

La verdad es que estoy aprendiendo un montón sobre el spectrum con este prototipo que estoy haciendo.
A ver si me meto con una versión 2 con CPLD, que se me están multiplicando las GAL.

Si lo vas a hacer con una CPLD, igual te puedo echar una mano con eso. De hecho, ya había empezado a hacer algo en ese sentido...



Es tu SuperUpgrade, pero aún más "super" si se me permite decirlo. A las características del SuperUpgrade (excepto lo de la salida en video compuesto) he añadido una implementación completa tanto del DivMMC como del ZXMMC. Dado que este chisme también te da la paginación de 128K, ambos dispositivos pueden usarse por un Spectrum 16K/48K.

No es necesario mezclar con un cablecito la salida del AY con la del beeper, porque este chisme genera su propia señal de altavoz, en el mismo puerto 254 que la ULA. Así, por la salida de sonido estéreo (configuración ACB) ya sale mezcldo el AY con el beeper, que por cierto conserva los niveles relativos de la ULA original (y que se pierden con la ULA de los modelos 128K).

Todas las características (soporte de 128K, DivMMC, ZXMMC, interface joystick, AY, grabación de la ROM, etc), son habilitables mediante un dip switch. Al poder desactivar a voluntad cada característica, este chisme puede ser usado también por un 128K/+2A/+3. Por ejemplo: puedes desactivar la paginación de RAM, pero dejar habilitada la conmutación de ROM y el ZXMMC y pincharlo a un 128K o +2 gris, o +2A/B/+3 y usarlo como si fuera un +2E/3E, con soporte para ZXMMC usando las ROMs del proyecto +3e en el chisme. Con 512K de la compatibilidad Pentagon, más un sistema de almacenamiento masivo y rápido, sí que no hay excusa para poder desarrollar programas que sean más voraces en cuanto a memoria.

O bien habilitar DivMMC y usarlo como eso, un DivMMC con cualquiera de tus Spectrums. DivMMC necesita 128K para él solo, así que no podría usarse junto con el modo de paginación Pentagon, pero sí sería compatible con el modo de trabajo de 128K.

Además, teniendo soporte de DivMMC ya tienes incluido en él un modo all-RAM que te funciona en cualquier Spectrum, y que no es "inventado" sino conocido por los desarrolladores.

Aun le faltan cosas por poner en el esquemático (por ejemplo, el botón de NMI y RESET), rutar muuuuchas líneas que faltan, pero hasta que no escriba la descripción de todo lo anterior en la CPLD no podré saber a ciencia cierta cuáles son los mejores pines de la CPLD para rutar las señales del circuito interno (las CPLD's no son tan flexibles como la FPGA en cuanto a qué cosas puedes meter en qué pin). Pero vamos, te haces a la idea de lo que puede llegar a hacerse, si metes la lógica dentro de una CPLD. Esta que he puesto es una XC95144XL, pero igual me encuentro con la sorpresa que con una XC9572XL tengo suficiente. Hasta que no se sintetice el circuito no lo sabré.

[wilco2009]

mmmm, interesante. Se agradece el ofrecimiento.

Ya te iré preguntando cosillas.

[antoniovillena]

La CPLD que va a usar wilco2009 es XC9572, que a diferencia de la XC9572XL trabaja a 5V y viene en un encapsulado compatible para throw hole (PLCC44). Desgraciadamente no existe dicha variante para XC95144XL