Hark0 escribió:Me he perdido con los cambios de Mejias3D....
Supongo que al usar Illustrator, importar el PDF no habrá sido problema.
De momento el fallo de los UDG me queda claro.... (vaya gamba)
Sobre el "arcoiris" si hay espacio en el A4 no cuesta nada incluirlo, el problema viene a la hora de colocarlo... en el teclado que tengo actualmente aquí NO CABE... Cada usuarío tendrá que "adaptarlo" a su espacio/teclado, etc.
¿Que más tocaría retocar?
Mejias3D escribió:Basicamente la filosofía que he seguido es:
- ¿Existe esa tecla en un Spectrum 48K? -Se pinta de color gomas
- ¿No existe esa tecla en un Spectrum 48K? -Se pinta de negro
- ¿No hace nada esa tecla en ZX-Uno? -La tapamos
- El logo no cabe en todos los teclados, pero aún así va de perlas para la cajita "RasPi"
- El "arcoiris" no cabe en ningún teclado tal y como está, necesitará ser recortado por el usuario, incluso puede ser descartado por completo si se desea, dado que el proyecto es sobre una FPGA abierta y no solo un ordenador Sinclair clásico.
Mejias3D escribió:mcleod_ideafix escribió:[...] todos vosotros estáis autoinvitados a echar un cable en este aspecto identificando qué instrucciones del T80 tienen diferente temporización que las de un Z80 real. Igual no son demasiadas y se puede arreglar el T80. [...]
Mi nivel de conocimientos en electrónica digital y FPGAs es cero, pero aún así me he animado a intentar echarte un cable:
En un primer momento se me ocurrió preparar esta sencilla rutina para sustituir cada NOP por instrucciones Z80 de una en una y ver su respuesta en relación al patrón de negro y blanco que produce el borde. He reservado 4 bytes por ser el ese el número de bytes necesarios para escribir ciertas instrucciones con prefijo.Código: Seleccionar todo
org 40000
di
xor a
loop: out (254),a
dec a
out (254),a
inc a
nop
nop
nop
nop
jp 40002; loop
Tras intentarlo por orden, empezando primero con las instrucciones sin prefijo, me doy cuenta en seguida de algo: Todas las instrucciones tienen un comportamiento similar en el T80 con una temporización comparable al Z80. Da la sensación de que todas se ejecutan con una velocidad algo inferior a la de un Z80 real, del orden de solo unos pocos nanosegundos más lento por cada instrucción y en todas las instrucciones. No puedo precisar cuantos nanosegundos en cada caso, pero sí que el retraso no supera un T-estado de Z80 a 3,5 Mhz. También es posible que el problema del T80 esté además (o solo) con instrucciones de lectura y escritura en los puertos. No es concluyente.
En resumen:
Mi idea de "cronometrar" los tiempos de ejecución de las instrucciones del T80 con esta rutina no tiene sentido práctico dado que el comportamiento del T80 es estable, siempre con el mismo margen de retraso. Tal vez, como digo, por una cuestión exclusiva o no con las instrucciones out que utilizo.
Pero, por casualidad, sí he notado algo llamativo fuera de eso, lo verás en esta comparación de una captura de pantalla con el emulador Spectaculator en pausa y una foto a la tele que uso con ZX-Uno.
Así es como debería verse el borde...
y así es como se ve...
Si nos fijamos, por ejemplo, en el trazado de la primera línea del borde en ambos casos tenemos el mismo comportamiento con esta nueva rutina que cambia el color del borde cada ~4 microsegundos.Código: Seleccionar todo
org 40000
di
xor a
ld de,7
ld bc,254
ld hl,40011; loop
loop: out (c),a
out (c),e
jp (hl); loop
Nótese el detalle de que se puede hacer 285 nanosegundos más rápida si cambio la instrucción out (c),a por out (254),a, que consume un T-estado menos, pero en ese caso no conseguiremos un área de borde estable en ZX-Uno y dado que no puedo pausarlo todavía, hacer que sea estable es importante para su estudio.
Se obtiene en ambos casos 24 pixels de negro y 32 pixels de blanco, por cada vuelta del bucle de la rutina, pero con cada cambio de línea en la pantalla se produce un retraso apreciable del T80 que hace que el patrón de pixels negros y blancos queden alineados en vertical en vez de inclinados a la izquierda con una diferencia de 8 pixels, que es como debería ser.
Ese comportamiento se ve alterado en la zona de "paper", a ambos lados en el área de borde.
Si nos fijamos en esta ampliación...
y en esta otra...
los problemas comienzan justo después de dibujar "el paper" en su primera línea tras los primeros 40 pixels de la esquina superior izquierda, que aún se siguen mostrando con la temporización cuasi correcta de costumbre.
Curiosamente al terminarse el paper en la esquina inferior derecha, los problemas se acaban y comienza nuevamente a "pintar" bien el borde con el patrón habitual de negro y blanco. Algo le pasa al T80 que le hace perder tiempo con cada línea de pantalla entre esos 2 puntos.
Mis sospechas sobre el T80 son:
1) Los T-estados de las instrucciones van razonablemente bien, con un error inferior a 250 nanosegundos más lento que un Z80 real en estas pruebas.
2) El problema más grande llega cuando al T80 le toca esperar a la ULA para el refresco de la zona de paper.
McLeod comentará si mi valoración es correcta o no.
Según lo veo yo, tiene mal arreglo.
Hark0 escribió:Veo que has trabajado sobre el "layout AV"...
Has "arreglado" el tema UDG's y veo que has añadido una flecha (cursor) en el 8...
pero veo que otras como ">" las has tapado.... Ya que nos caben en la hoja, yo optaría por dejarlas.
Se puede añadir tu diseño como otro nuevo e incluírlo en el PDF bajo la denominación: LAYOUT MJ.
¿Qué más cambios has realizado?
Hark0 escribió:¿Porque no copias este post AL DE LAS ETIQUETAS? Y seguimos alli...
No es plan de cruzar temas de hard con adhesivos...
Nos pelan.... XD
Quest escribió:Ahora que tengo funcionando el Add-on del Z80, he decidido echar un vistazo al tema de los timings que comenta Mejias3D (con su test del borde).
Mejias, tras hacer las pruebas he observado que puedes haber pasado por alto un detalle importante, y es que no has tenido en cuenta que cada modelo de spectrum tiene unos timings diferentes:
1- 48K
2- 128K / +2 gris
3- +2A / +3
Veo según tus fotos y capturas, que en el emulador estás usando la emulación de un +3 (obviamente con sus timings particulares), pero en el ZX-UNO por la pantalla que sale, estás usando los timings de un 48K. Lo malo es que en el ZX-UNO todavía no se pueden seleccionar los timings de un +2A/+3 , sólo se puede elegir entre 48K y 128K/+2 gris (ver BIOS para forzarlo o bien hazte con GenRom las roms con el timing ya puesto).
[...]
¿Vas viendo lo que te comentaba?
Al margen de eso, el análisis nos dice, como se puede observar, que con el Z80 externo, el ZX-UNO se comporta como debe en los timings de 48K y 128K. No sabemos como lo hará con los del +2A/+3 hasta que no lo implementen en BIOS.
También se puede ver que con el core T80 hay ligeras diferencias, sobre todo en los laterales del borde, donde se desplazan las líneas de forma regular.
pero siempre que lo veo me chirría, simplemente que en todos los sitios donde aparece la palabra "timing" o "timings" lo pone con dos emes: "timming", siendo que la palabra correcta en inglés es con sólo una eme: "timing". Ya digo que es una chorrada, pero ahí está Además, no es lo mismo ponerse a jugar que a programar. A veces te resulta más cómodo usar un layout para una cosa y otro para otra.
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 10 invitados
