En busca del bug en el superupgrade

[wilco2009]

Pues si me puedes proporcionar una imagen sin controladora te lo agradecería. Se me quedó mal sabor de boca al no hacerlo andar...

Anbiao ende mi parato usando catacrak

Te pasaré el enlace por privado.

[Scooter]

Gracias

Anbiao ende mi parato usando catacrak

[wilco2009]

Bueno, vamos poco a poco, pero creo que casi lo tengo.

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.

De momento 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.

Aún tengo que modificar los fuentes de la ROM2 para conseguir que ensamblen en pasmo y poder modificarlos, pero 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 me da que pensar que hay que implementar el puerto lectura $2ffd para que funcione.

La prueba de fuego sería modificar la subrutina para devolver siempre $ff, y de esa manera el sistema sepa que no hay unidades conectadas.

Si es así habrá que investigar como se inicializan los IDEs.

[antoniovillena]

Por si te sirve de ayuda yo tengo desensamblados de las 4 ROMs oficiales, más la del plus3e compatible con ZXMMC y una adaptación de ésta para que funcione en DivMMC.

http://sourceforge.net/p/emuscriptoria/ ... /plusROMs/

Compilan con SjAsmPlus y parten todas del mismo fuente plus3.asm con ensamblado condicional.

[wilco2009]

Muchas gracias!!, le echaré un vistazo.
Me serán bastante utiles para ver el tema del ide.

[flopping]

Lo que no entiendo muy bien, es lo siguiente, si en un +2a,b funciona bien sin controladora de discos y en nuestro upgrade, tampoco tenemos controladora, debería de funcionar bien con las roms de un sistema o de otro, a no ser que se este haciendo llamadas a direcciones o posiciones, en las cuales debería de haber algo cargado previamente, que en nuestro caso no lo hay, ya que de otra forma no me explico el por que de la incompatibilidad y por que unas veces arranca y otras no.

[Scooter]

Eso es lo que yo pensaba. Pero cabe la posibilidad de que si no está la controladora pero si su circuito de decodificación o algo mas, detecte 00h al leer yo que se que puerto (por ejemplo) en mi caso y en este, al faltar parte de la circuitería, lee aire y por eso a veces va y a veces no.
Eso o algo así.
En cualquier caso, si no hay controladora, o no hay lo que sea, no sirve para nada inicializarlo.

Anbiao ende mi parato usando catacrak

[wilco2009]

Lo que no entiendo muy bien, es lo siguiente, si en un +2a,b funciona bien sin controladora de discos y en nuestro upgrade, tampoco tenemos controladora, debería de funcionar bien con las roms de un sistema o de otro, a no ser que se este haciendo llamadas a direcciones o posiciones, en las cuales debería de haber algo cargado previamente, que en nuestro caso no lo hay, ya que de otra forma no me explico el por que de la incompatibilidad y por que unas veces arranca y otras no.

Lo primero es decir que todavía no tengo comprobado al 100% que el problema esté donde he dicho, ya que para eso tengo que modificar la ROM2. Eso es lo que intentaré esta tarde.

En cuanto a porqué funciona un +2A, la respuesta está en mi mensaje anterior. La ULA del +2A implementa el puerto de lectura $2FFD que devuelve si existe una controladora de discos. Si no hay controladora devuelve $FF en el bus de datos.

En nuestro caso, cuando se hace la lectura del puerto, leemos un valor aleatorio. Mi planteamiento es que, cuando leemos $FF todo va bien ya que el sistema no vuelve a intentar hacer ninguna llamada a una función de de la controladora.
El problema viene si leemos cualquier otro valor, ya que se dedica a hacer llamadas a funciones de disco sin haberlo, con lo que al final se cuelga.

[flopping]

Vale, entonces estas depurando las roms, digamos que para evitar que el sistema haga llamadas a la controladora de discos y así evitar que lea valores aleatorios en el bus, ¿es más o menos eso?.

Si es así, estarás inhabilitando la controladora de por vida, a no ser que digamos que tendremos 2 opciones una, roms sin controladora y dos, roms normales y así ya se podría implementar la controladora, cosa que en el primer caso aún poniéndola, no serviría de nada.

Si lo que digo es correcto, si le ponemos al súper upgrade una controladora de discos, ¿ya no tendríamos esos problemas de incompatibilidad, no?, entiendo que ahora lo estés depurando, para que el sistema arranqué y no tenga fallos ya que no tenemos,controladora, pero más adelante si le ponemos una controladora, deberemos de usar las roms normales, ¿crees que es correcta mi suposición?.

Bueno, pues nada, suerte con esas modificaciones y a ver si al final de todo esto sacamos algo en claro, jejejejeeje.

[wilco2009]

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 centraría solo en un punto (o eso espero) y a partir de ese momento el ordenador se comportaría como un +2A. Esta es la solución que tengo planificado adoptar, de tal manera que tendríamos 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

Una forma sencilla de cambiarlo sería modificar el salto sustituyendolo por un par de NOPs. De esta manera siempre iría a mostrar la unidad "M:" directamente.

Esta forma es más sencilla que la que había pensado inicialmente de modificar la ROM2, ya que este último fuente no lo tengo todavía adaptado a PASMO.

Esta tarde lo probaré y os cuento.

El siguiente paso será coger los fuentes que me ha pasado antonio, para comprobar si lo hace de la misma manera en las ROMs del +3e, y si esto no tiene influencia en el interface IDE. En caso contrario, habría que buscar una solución alternativa.