Spectrum +2A floating bus puerto

[chernandezba]

Hola

Perdón por enlazar a otro foro, pero es para ahorrarme tener que traducir el post a español...

http://www.worldofspectrum.org/forums/d ... g-bus-port

En él hablo del "Floating bus port" del Spectrum +2A, que, por lo que he leído yo siempre, se dice que no tiene dicho bus, o sea, la lectura de puertos no usados debería retornar 255, pero no es así... En dicho enlace hay una explicación y video demostrativo con un Spectrum +2A (el mío, funcionando después de montón de años y no arrancado desde hace 5 años ) donde muestra que sí que hay puertos que retornan dicho valor diferente de 255.

Saludos
César

[mcleod_ideafix]

¡Qué bueno! ¿Y cómo se te ocurrió probar esos puertos? En el +2A/+3 no hay un "floating bus" port evidente porque los dos buses de datos de RAM, el de RAM de video y el de RAM no contenida, no se acoplan con resistencias sino que se hace el acople dentro del gate array. Que tú hayas descubierto esto implica algo muy curioso, y es que dentro del gate array de Amstrad debe haber algo parecido a un acople con resistencias entre los dos buses. Claro que como siempre ha estado dentro, nadie se le ha ocurrido suponer que existía. Siempre se ha supuesto que había transceivers "de verdad", lo que hubiera impedido la existencia de tal bus flotante.

[chernandezba]

Esto lo descubrí hace bastante tiempo, quizá por el año 98 o 99, cuando estaba programando mi anterior emulador, ZXSpectr. La verdad es que no sé cómo se me ocurrió, pero diría que en aquel entonces descubrí lo que era el floating bus y decidí probarlo en mi +2A.
Como yo leí que hablaban de puertos 'no usados' , probé en un bucle desde el puerto 0 en adelante, y no me limité al puerto FFH. Es entonces cuando descubrí esto.
Por aquel entonces yo no me conectaba mucho a los foros pero sí que comenté el descubrimiento en WOS, ahora no sé si era Martijn o Phillip quien lo gestionaba, pero no obtuve respuesta y el tema quedó en el olvido.
Con ZEsarUX, desde la primera versión en que añadí el floating bus, ya emulé el +2A de la manera que descubrí.
Ha sido recientemente hablando con Jeff Braine, el creador del Prism, que he recordado de nuevo el tema y he decidido volver hacer 'broadcast' del tema
Entiendo lógicamente que esto no sólo se da en mi +2A, pero no estaría mal probarlo en algún otro... Quizá tú Miguel Ángel puedes validarlo en alguno tuyo
Tengo apuntado el serial y el issue del spectrum, por si esta feature solo se da en algunas series... cosa que dudo


Saludos
César

[zup]

Tres dudas.
- Dices que el invento solo funciona con la paginación habilitada. ¿No es un poco raro que sólo puedas usarlo en juegos de 128k?
- La máscara que propones coincide con la máscara del puerto centronics. ¿No estarás leyendo ruido de alguna línea de ese periférico (Error, busy)?
- ¿Ese cambio de estado se produce exactamente en el mismo punto que en el 48k? Es decir, ¿el rayo de electrones está en el mismo sitio (para evitar nieve)?

Para estar seguros, quizás habría que repetir el experimento con un cable centronics completo conectado a una impresora encendida (para no tener líneas "al aire"), a ver qué pasa.

[chernandezba]

Tres dudas.
- Dices que el invento solo funciona con la paginación habilitada. ¿No es un poco raro que sólo puedas usarlo en juegos de 128k?
- La máscara que propones coincide con la máscara del puerto centronics. ¿No estarás leyendo ruido de alguna línea de ese periférico (Error, busy)?
- ¿Ese cambio de estado se produce exactamente en el mismo punto que en el 48k? Es decir, ¿el rayo de electrones está en el mismo sitio (para evitar nieve)?

Para estar seguros, quizás habría que repetir el experimento con un cable centronics completo conectado a una impresora encendida (para no tener líneas "al aire"), a ver qué pasa.

1. Bueno raro es, pero no lo he definido yo
2. No hay nada conectado, fíjate en el vídeo
3. Es una prueba hecha en basic, no se puede ser tan preciso con el timing usando basic, pero estoy seguro que si se ejecuta algún Test de bus floating hecho en asm, los valores corresponderán con el timing de pantalla

Si miras el vídeo veras que los valores del puerto son los mismos que retorna el bus flotante de un 48, eso sí, con el bit 0 activo. Ves como retorna valores 1 (0+1) que corresponde a zonas en blanco de la pantalla, o 56+1 del atributo en color blanco y tinta negra, fíjate que cuando cambio el color de papel, ese 56+1 también cambia
No hay duda que son valores del bus flotante

Saludos

[zup]

1.- A lo que me refiero es que si fuera algo intencional (para aumentar la compatibilidad) debería funcionar en modo 48k.

2.- Me refiero a eso. Al tener las líneas del puerto paralelo "al aire" podría entrar ruido electrónico. Si mal no recuerdo, en niveles TTL no debería ser un problema, pero me pregunto cómo se comportará si todo está correctamente conectado.

3.- Estoy intentando ejecutar mi propio test en asm, pero me he cargado la flash del divide. De momento, el primer test no muestra ningún resultado (utilizo el puerto $0ffd, que coincide con la máscara y es el oficial del paralelo), aunque podría ser por ejecutarse a través del divide (¿esxdos deja la paginación habilitada o no?). El código que he usado es el siguiente:

Código: Seleccionar todo

port equ $0ffd

org 40000
inicio:
halt
di
bucle1:
ld bc,port
in a,(c)
cp $ff
jr z, bucle1
ld bc,20
bucle2:
djnz bucle2
xor a
out ($fe),a
ld bc,30
bucle3:
djnz bucle3
ld a,7
out ($fe),a
ei

jp inicio

Creo que es correcto para lo que quiero probar. En un 48k, usando el puerto $00ff, muestra una barra de color negro en el borde en una posición fija. Lo que se pretende probar es:
- Si se produce un cambio de estado en el puerto $0ffd (mostraría una barra de color negro) o no (borde blanco).
- Si ese cambio se produce correctamente (barra fija) o es más o menos aleatorio (barra moviéndose).

Es la primera vez que hago experimentos con el bus flotante, por favor que alguien repase el código que he escrito y me diga si es correcto o no.

Por otra parte, el estado del bit 1 es correcto: si no hay impresora conectada (o está ocupada) la línea BUSY estará a 1; si la impresora está lista para imprimir, estaría a 0.

A ver si termino de restaurar la flash del divide y puedo probarlo más a fondo.

Mi equipo de pruebas:
- Spectrum +3 británico.
- Teclado castellano.
- Mod de vídeo compuesto.
- Mod de corrección de vídeo (quitar el condensador que mezcla audio y vídeo).
- Mod chapucero de corrección de audio (añadida una resistencia para que el amplificador no funcione en corte/saturación).
- ROMs +3e versión 1.38 en castellano para divIDE.

Ninguno de los mods debería variar la validez de la prueba, pero los listo por si acaso.

[zup]

Vaaale, ahora ya estoy confuso.

He repetido la prueba en mi +3. Al principio pensaba que no se producía el cambio de estado en el puerto, pero luego me he fijado que justo en el borde superior de la pantalla había media franja negra. Pulsando una tecla, la franja se completaba (lógico, la interrupción de la ROM anda activa y le cuesta algo de tiempo deducir qué tecla he pulsado).

En un Spectrum 48k normalito, la franja negra en el borde se produce al principio de la tercera línea de caracteres.

¿Cómo interpreto el resultado? Bueno, mis conclusiones son las siguientes:
- Efectivamente, se produce un cambio de estado en el puerto $0ffd.
- O bien se produce antes de lo esperado (y por eso la franja aparece en el borde superior), o bien se produce mucho más tarde de lo esperado.

...todo eso suponiendo que mi código de detección de bus flotante es correcto...

¿Se puede aprovechar? Pues no estoy seguro. Mi prueba no estaba destinada a saber si se producen esos cambios en todas las líneas, pero algún resultado ha dado.

Se me ocurren dos pruebas: la primera es usar el mismo código aumentando el retardo del primer bucle (para bajar la franja negra y ver si mis conclusiones eran correctas). La otra es comprobar qué pasa en algún juego (p.ej. Sidewize o Crosswize) al cambiar el puerto, si vuelven a ser "compatibles" (hay un parche de compatibilidad pero da unos parpadeos considerables). Pero eso ya son deberes para otro día...

EDITO:
Vaaaale, mi código tiene bugs. He hecho un programa nuevo que debería funcionar mejor, a ver si se lo largo a mi +3 y lo pruebo en condiciones.

Algunos pensamientos alegres:
- Si se sigue comparando con $ff, fallará en caso de que haya una impresora enchufada al puerto paralelo (la línea BUSY se quedará a 0).
- ¿Por qué lee el último dato de la RAM justo en el puerto paralelo? ¿Tendrá algo que ver el HCT273? ¿Qué pasaría si quitamos IC14 e intentamos repetir la prueba? (Otra prueba: esperar a que el puerto $0ffd esté a $ff, enviar un dato y leer de vuelta el puerto $0ffd a ver qué sale)

[chernandezba]

Buenas

Has probado el mismo Test simple que hice en basic con un PRINT IN 1?
Por otra parte, hay por ahí un test (creo que viene con fuse) que comprueba los valores del bus flotante. Supongo que alterando el test para que use un puerto diferente del FFH puede servir, aunque hay que tener en cuenta que los valores del +2A siempre vienen con el bit 0 alzado.
Por lo que yo recuerdo del floating bus, los valores que se leen son:
-bytes de pixeles o atributos cuando el haz de electrones está en la zona de pantalla
-255 cuando el electrón está en el borde

Lo digo de memoria, seguro que está perfectamente documentado por ahí...

[chernandezba]

Por cierto, esto mismo lo he publicado en WOS y hay alguien que comenta que la máscara de puerto es la usada en los puertos de paginación (7ffd....)

[chernandezba]

1.- A lo que me refiero es que si fuera algo intencional (para aumentar la compatibilidad) debería funcionar en modo 48k.

2.- Me refiero a eso. Al tener las líneas del puerto paralelo "al aire" podría entrar ruido electrónico. Si mal no recuerdo, en niveles TTL no debería ser un problema, pero me pregunto cómo se comportará si todo está correctamente conectado.

.

1. No creo que sea nada intencional.. Será una característica del propio diseño
2. Ruido porque? No es ruido aleatorio, los valores siguen el mismo patrón del bus flotante , excepto por lo del bit 0

[antoniovillena]

Por cierto, esto mismo lo he publicado en WOS y hay alguien que comenta que la máscara de puerto es la usada en los puertos de paginación (7ffd....)

Pues probablemente sea un efecto colateral del hardware de paginación. El puerto 7ffd tiene decodificación parcial 01-- ---- ---- --0- (A15=0, A14=1, A1=0, IORQ=0), mientras que el 1ffd tiene 0001 ---- ---- --0- (A15=A14=A13=0, A12=1, A1=0, IORQ=0). Puede que no hayan tenido en cuenta la señal WR para activar el buffer, con lo que se activa de una forma no deseada también con RD y provoque un valor distinto en el bus flotante.

[zup]

Empezaré con lo del puerto $7ffd que mencionan en WOS. La máscara que ha propuesto @chernandezba es la correspondiente al puerto paralelo (oficialmente $0ffd), no $1ffd ni $7ffd que mencionan.

El problema que mencionan en WOS es que al leer el puerto $fd quizás puedas leer el $7ffd por accidente y bloquear el Spectrum. El problema es que al usar in r,(c) se usa bc para definir un puerto de 16 bits. Si no se controla el valor de b en ese momento (concretamente que NO sea $7f) tendrás un bonito bloqueo.

Lo que no tengo claro es qué pasa al hacer un in a,($ff)... ¿qué valor toma el byte alto del puerto? ¿$00, $ff, b, indeterminado?

Tengo un nuevo test (esperar a la primera línea, esperar n líneas, poner borde) a la espera de ejecutarlo en mi +3, a ver qué pasa con esa sincronización.

El hecho de que se deshabilite al mismo tiempo que la paginación, indica que sí que está relacionado con el diseño (o las ecuaciones relacionadas) con el puerto paralelo. Como ya he indicado si el Spectrum tiene una impresora conectada y en línea, la sincronización fallaría (porque el bit 0 nunca estaría a 1). Creo que nadie utiliza una impresora y necesita una sincronización de vídeo exacta, pero es algo a tener en cuenta (¿mejor sincronizar con el bit 7? ¿comparar con 128 y saltar si es menor?).

[chernandezba]

Hola

Que quieres decir con que la gente necesita sincronización exacta?
Lo de sincronizar con el bus idle se usó en algunos juegos, como arkanoid, y luego se dejó de usar (afortunadamente) e incluso esos mismos juegos que lo usaban se modificaron en una versión superior (the hit squad series, por ejemplo)
Yo no sé si perdería mucho tiempo viendo que valores retorna en un frame de pantalla, porque estoy casi seguro que se ajustará a lo que lea la ula en ese momento: border, pixeles o atributos

Quizá lo que sí es curioso lo de la impresora y el bit 0... Quizá con una impresora el bit 0 no se ve alterado...

Por cierto lo de la máscara del puerto no es que la haya sugerido yo, sino que es tal y como se comporta el +2A... Si haces un bucle con todos los puertos veras que el comportamiento obedece justo a esa máscara

Saludos
César

[zup]

Lo de la "sincronización exacta" era una coña, todo esto del in a,($ff) se puede usar tanto para sincronizar el juego con el haz de electrones (y regular velocidad, y evitar nieve) como para efectos multicolor. Lo que me refería es que no se me ocurren muchos casos en que sea necesario usar la impresora y necesitar ese control.

En cuanto a lo de las comparaciones es por lo de la impresora. Si no hay impresora conectada, el bit 0 estará siempre a 1; si hay impresora conectada estará a 0 (a menos que la impresora esté apagada, sin papel o cualquier otra cosa que cause que BUSY se active). La mayoría de los juegos comparan con $ff (como has dicho, borde), pero un +3 con impresora conectada y en línea devolvería $fe en esos casos. Por eso sugería comparar con el bit 7 (atributo flash, habitualmente desactivado) ya que es una manera que funcionaría tanto con impresora como sin ella.

Y como he comentado, el bit 0 SIEMPRE se ve alterado, ya que retorna el valor de la señal BUSY. Tanto si no existe impresora (siempre a 1) como si existe (a 0 si la impresora está lista, a 1 si no), el bit 0 se verá alterado. No tengo cable de impresora (ni impresora paralelo) para probarlo, ese sería tema de otras pruebas.

Se me ocurre también parchear algún juego (p.ej.: Crosswize o Sidewize) que use el puerto $ff para que use el $fd y luego lanzarlo en mi +3 a ver si la sincronización mejora. La nueva prueba que quiero lanzar sobre el +3 también debería ayudar a aclarar un poco esto.

[chernandezba]

Ok, gracias por las explicaciones. Será curioso ver si ese bit responde tal cual comentas al conectar una impresora

En cuanto a los juegos, yo también tengo intención de parchear alguno a ver qué sucede...

Saludos
César