Proyecto ZDP-80 - Nuestro microordenador desde cero [#01]

[scooter]

Y que a modo de resumen viene a decir que si vemos el ordenador en un televisor normal vamos a perder pixels (no se van a ver porque se los come el borde del televisor) y sólo se verían todos los pixels en un monitor.

Es decir, que lo suyo, para no calentarnos la cabeza, es dejar el borde y punto pelota.

Pues no lo tengo muy claro; en un televisor moderno (que yo sepa*) se ve toda la pantalla, en mi caso particular hace ya muchos años que no queda un CRT en mi casa. No se si es que mi televisor no es "normal*" o si que lo es. No se si es "de recibo" ser tan retro, osea, supongo que este ordenador "nuevo" no usará demasiado hardware obsoleto y difícil de encontrar como diskettes o "televisores"

*En los asteriscos está la clave; en si las teles modernas se comen el borde no he dicho nada , pero que yo sepa no lo hacen y en si "normal" es un CRT o un TFT. Hoy creo que "normal" = TFT.

[antoniovillena]

Por mi no hay problema en meter 20 MHz, pero creo que no hace falta apurar tanto y que 14 MHz supone una velocidad considerable respecto a un 8 bits normal (aparte de necesitar menos lógica discreta como bien mencionas).

Además, lo bueno de usar 14 MHz en una CPU que está preparada para 20 MHz es que disipa bastante menos calor, ¿no?

Vamos a lo sencillo, por favor, ya habrá tiempo para una segunda versión más burra con 256 colores por pixel o varios Z80 si hace falta.

No es por la velocidad, un 43% más no es para tirar cohetes. Es porque es más fácil de encontrar un cristal de cuarzo de 20Mhz que uno de 14. Y si vas ponerle un oscilador en lugar de un cristal sería mucho más complicado encontrar uno de 14Mhz.

Ahora que caigo, no es necesario cambiar dicha lógica, lo único que habría añadir es un divisor de frecuencia de 3 para obtener sacar el reloj de pixel. Un divisor de 3 es tan sencillo que se puede hacer de muchas maneras posibles (contador, shift register, 2 biestables sin lógica adicional). No sé si me explico, obtenemos 6,66Mhz del reloj maestro con los cuales alimentamos la circuitería de video.

[mcleod_ideafix]

¿Has probado a 20Mhz?
Se pueden usar 20Mhz sólo que la lógica para detectar si estoy en el área visible es un poco más compleja...

¿Dices usar 20MHz como reloj de pixel y de CPU? ¿O 20MHz para la CPU y 7MHz para la sección de video?
Si es la segunda opción, el problema que tendremos, al no ser la frecuencia de la CPU múltiplo (o divisor) entero de la frecuencia de pixel es que será más complicado sincronizar ambos dispositivos para que no se genere contienda. Mi circuito de "evitación de contienda" es sencillo porque se basa precisamente en esto. Con dos dispsoitivos desacoplados en frecuencia, es necesario usar más bufferes intermedios, lo que implica más lógica.

Si te refieres a lo primero, no habrá problemas para evitar la contienda (a costa de usar memorias más rápidas), pero para este nuevo modo de pantalla, hagamos números:

Fp = 20 MHz
Npt = 20 * 64 = 1280
Np = 256 píxeles. Para no tener un área de pantalla demasiado pequeña, habría que hacer píxeles que fueran 4 periodos de reloj, así que Np en realidad es 256*4=1024
Nfp = 5.8*20 = 116
Nbp = 1.5*20 = 30
Nhs = 4.7*20 = 94

De aquí sacamos Nb = 1280 - (1024+116+30+94) = 16
O lo que es lo mismo, dos bordes izquierdo y derecho de 8 periodos de reloj cada uno. Como hemos determinado que la anchura de los píxeles es de 4 periodos de reloj, estos bordes tendrán en realidad 2 píxeles cada uno. Exactamente el mismo esquema que el QL.

Si nos parece demasiado poco borde, podemos elegir tener píxeles que sean de 2 periodos de reloj. Entonces Np es ahora 512, y Nb se calcula como:
Nb = 1280 - (512+116+30+94) = 528

O sea, cada borde izquierdo y derecho ocupará (528/2) = 264 periodos de reloj de pixel, y como cada pixel ahora son dos periodos de reloj, tenemos que cada borde mide 264/2 = 132 píxeles. Esto es bastante más del grosor del borde lateral en el Spectrum. El área activa de la pantalla se te quedaría muy escasita.

-- 08 Oct 2012, 13:38 --

Es porque es más fácil de encontrar un cristal de cuarzo de 20Mhz que uno de 14. Y si vas ponerle un oscilador en lugar de un cristal sería mucho más complicado encontrar uno de 14Mhz.

Si es por eso, usa como frecuencia 14.31818MHz . Es de las frecuencias más estándar que hay.

...obtenemos 6,66Mhz del reloj maestro con los cuales alimentamos la circuitería de video.

Bien. Tenemos entonces un sistema de video que va a la tercera parte de frecuencia que el reloj de la CPU. En este caso, mi mecanismo de "no contienda" no funcionará, porque se basa en que entre cada dos accesos de memoria de la CPU hay, al menos, dos ciclos de reloj de CPU en donde ésta no accede a memoria. Si la circuitería de video va a 1/3 de la frecuencia de CPU, necesitará más de dos ciclos de CPU para hacer una lectura de VRAM y en ese caso, habrá colisiones.

Si divides la frecuencia de CPU entre 1.5 o entre 2, sí que se puede seguir usando este mecanismo. En el caso más rápido, la memoria con la que implementes VRAM tendría que ser de como máximo, 1.5*1000/20 = 75ns de tiempo de acceso.

[antoniovillena]

¿Dices usar 20MHz como reloj de pixel y de CPU? ¿O 20MHz para la CPU y 7MHz para la sección de video?
m

No. Digo usar 20Mhz para la CPU y mediante un divisor de frecuencia de 3 extraer los 6.66Mhz para el video. Evidentemente habría que hacer unos pequeños cambios en los timings, pero no implica mayor circuitería (estos cambios, el divisor evidentemente sí). 6666666/15625= 426,666624, por lo que habría que poner el límite del contador horizontal a 426 ó 427 en lugar de a 448.

[mcleod_ideafix]

No. Digo usar 20Mhz para la CPU y mediante un divisor de frecuencia de 3 extraer los 6.66Mhz para el video.

Ok. Eso puedo testearlo, pero para poder seguir teniendo accesos libres de contienda, en lugar de usar 6.6666666MHz, usaré el doble, es decir 13.333333MHz . Así se cumple que la frecuencia del reloj de pixel no es demasiado lenta respecto de la frecuencia de reloj de la CPU y mi sistema sigue funcionando

Hagamos números:
Fp = 20/1.5 MHz = 13.333333333333MHz
Np = 256 píxeles. Como he doblado la frecuencia de reloj de pixel, para que cada pixel siga teniendo la misma anchura que tendría si el reloj fuera a 6.66666MHz, usaremos dos periodos de reloj por pixel, con lo que en realidad Np = 512
Npt = 64 * Fp = 853 (redondeando)
Nfp = 5.8 * Fp = 77 (redondeando)
Nbp = 1.5 * Fp = 20 (exacto)
Nhs = 4.7 * Fp = 63 (redondeando)

Como hemos tenido que redondear resultados, comprobemos que la suma Nfp + Nbp + Nhs sea igual a 12 * Fp, y si no es así, añadimos o quitamos un ciclo de reloj a alguno de los parámetros.
Nfp + Nbp + Nhs = 77 + 20 + 63 = 160
12 * Fp = 12 * 20/1.5 = 160 ¡coinciden! No hay que tocar nada.

Nb = Npt - (Np + Nfp + Nbp + Nhs) = 853 - (512 + 160) = 181
Este valor es impar. Para que cada borde quede de la misma anchura, haremos que Npt sea uno menos, 852. De esa forma, Nb sale igual a 180. Esto significa que cada borde mide 90 ciclos de reloj. Dado que cada pixel ocupa dos ciclos, la anchura en píxeles de cada borde es de 45 píxeles. Ligeramente inferior al Spectrum (48 píxeles)

Por tanto, los parámetros para el generador de señales del circuito de video son:

Fp = 20/1.5 MHz = 13.333333333333MHz
Np = 512
Npt = 852
Nfp = 77
Nbp = 20
Nhs = 63

Con esto puedo sintetizar una versión de este circuito que permita que la CPU pueda funcionar a 20MHz sin contiendas

[antoniovillena]

No hacía falta que lo implementaras, si yo te lo decía por decir.

De todas formas si quieres hacer experimentos te propongo lo siguiente:
ROM: $0000-$37ff
Bitplane 0: $3800-$4fff
Bitplane 1: $5000-$67ff
Bitplane 2: $6800-$7fff
Resto de RAM: $8000-$ffff

Tendríamos de esta forma 3 bitplanes diferenciados y 3 modos de video "ficticios" de 2, 4 y 8 colores (algo parecido a un Amstrad CPC). La diferencia es que esto es mucho más sencillo, si sólo queremos 2 colores sólo tocamos un bitplane y la velocidad para mover gráficos de esta forma es 3 veces más rápida que en el caso de 8 colores. La pega de esto es que para pintar un pixel hay que escribir en 2 y 3 zonas distintas para 4 y 8 colores respectivamente.

Los 8 colores yo los sacaría de dos formas distintas:
1. Escala de grises lineal, por video compuesto.
2. 8 colores paletizados y configurables, por RGB.

Lo bueno es que no necesitamos meterle un caro AD724 al circuito. Lo malo es que las salidas son distintas, y los juegos diseñados en color se verían mal en B/N (lo contrario no pasa porque la paleta se puede configurar a escala de grises).

[radastan]

Tendríamos de esta forma 3 bitplanes diferenciados

Disiento, eso es complicar la vida enormemente al programador y perder tiempo de CPU. Es una pena tener una CPU a 20 MHz y perder la potencia a la hora de escribir en pantalla.

Como ya he dicho me parece absurdo estar pensando en un ordenador z80 básico y sencillo para aprender y liarnos ahora a meter bitplanes y similares. No estamos hablando de un producto comercial, esto va a tener usuarios contados y exclusivamente por cacharreo, lo mismo nos animamos a hacer algún juego pero dudo que se le saque el 100% de partido.

2 bits por pixel como mucho es todo un lujo para nuestras pretensiones, limitar a 16K la VRAM y que quede espacio para el sistema operativo en esos 16K lo veo más que suficiente. Y la Gameboy ya demostró que los tonos de gris dan mucho juego, y tienen un encanto especial. No quiero hacer un nuevo Amiga, para eso ya habrá un segundo proyecto (o no).

256x192 con 1 o 2 bits por pixel en monocromo/gama de grises.

Es más, si queréis podemos consensuar que el modo de vídeo sea seleccionable por un puerto (fijemos dos bits para poder seleccionar hasta cuatro modos de vídeo, cuatro bits para el color del borde, y otros dos bits para cambiar la página de VRAM que ve el Z80), de esta forma el modo 0 es 256x192x1, el modo 1 256x192x2, y los otros dos modos hacéis lo que os de la gana y los fijáis vosotros. Así el que quiera un modo de vídeo más avanzado, siempre dentro de los 16K, podrá implementarlo en su placa sin perder compatibilidad con los modelos "menores".

Creo que es lo más flexible para todos y así nadie queda descontento, yo sólo voy a fijarme en el modo 0 y el 1. ¿OK?

-- 08 Oct 2012, 15:05 --

Con esto puedo sintetizar una versión de este circuito que permita que la CPU pueda funcionar a 20MHz sin contiendas

¿De cuantos ns hablamos para las memorias?
¿Se calientan mucho los Z80 a 20 MHz?

[antoniovillena]

Entiendo que no estés de acuerdo, pero me gustaría saber a qué te refieres con perder tiempo de CPU. Si usas un único bitplane no existe diferencia de velocidad ni complicación para el programador.

[radastan]

Entiendo que no estés de acuerdo, pero me gustaría saber a qué te refieres con perder tiempo de CPU. Si usas un único bitplane no existe diferencia de velocidad ni complicación para el programador.

Si usas 2 o 3 bitplanes como dices... si.

Por eso te digo que podemos fijar un "estándar" para el quiera implementarse algo más gordo y ya está, todos contentos.

Idem para la cantidad de RAM, cuando llegue su turno fijamos un sistema de paginación y que cada cual decida la RAM que quiere.

¿No es más sencillo y divertido para todos tener algo de libertad?

[mcleod_ideafix]

Tendríamos de esta forma 3 bitplanes diferenciados

Disiento, eso es complicar la vida enormemente al programador y perder tiempo de CPU. Es una pena tener una CPU a 20 MHz y perder la potencia a la hora de escribir en pantalla.

Aparte de que te va a quedar la circuitería de video como si fuera el parche de válvulas que le puso Doc Braun al DeLorean en 1955 para sustituir a un microchip que se quemó en su último viaje al pasado. Las ideas de AntonioVillena son fácilmente implementables en lógica programable. En lógica discreta ya hay que ponerse a darle más vueltas.

La otra idea, CPU a 20MHz y video a 13.3333MHz (el doble de lo que tú calculaste) sí es fácilmente implementable, y entra dentro de los requerimientos iniciales de Radastan: modo de video simple y sin contienda a ser posible. Y como el procesador es el mismo, pues eso.

¿De cuantos ns hablamos para las memorias?

Buena pregunta. A 20MHz necesitas memorias RAM y EPROM de 50ns o menos. Estas velocidades, aun siendo sencillas de conseguir, no sé qué tal estarán de precio respecto a las más bajas de 70 o 120ns.

¿Se calientan mucho los Z80 a 20 MHz?

Nunca he puesto uno a 20MHz, pero siendo dispositivos CMOS no creo que se calienten demasiado... si es que llegan a calentarse.

Yo la pega fundamental a poner la CPU a 20MHz es precisamente lo que has comentado antes: las memorias. Mirando por eBay, encuentras RAM's de 32K x 8 de 120ns, 100ns y 70ns. De estas tres velocidades hay a patadas. De 50ns o menos no encuentro ninguna.

Mira, en DigiKey sí que tienen:
http://www.digikey.es/product-detail/en ... ND/1206029
Ahí tienes una memoria RAM de 32K x 8, de 12ns de tiempo de acceso. Mucho más rápida de lo que se necesita. Es pequeña (no es anchota como las habituales 62256) y es "SMD-fearboy compliant" (compatible con aquellos a los que les da miedo soldar SMD). Sale a 1.7€ la unidad.

En cuanto a EPROM's para implementar la ROM, de suficiente velocidad, y que sean de al menos 16K x 8, lo único que he encontrado es una Flash EPROM de 64Kbytes y 45ns de tiempo de acceso. Lo malo es que parece que no tienen stock de ella, así que no puedo saber su precio ni disponibilidad.
http://www.digikey.es/product-detail/en ... ND/1133334

Creo que, siendo prácticos, será más razonable no pasarnos de 14MHz en la CPU, para no tener que tirar de memorias difíciles de encontrar. Implementaré la propuesta de AntonioVillena, aunque sea sólo por ver si el aumento de velocidad "se nota" o no es para tanto (un 43% debería notarse, digo yo). Y porque... con la FPGA es taaaaaaan sencillo cambiar las especificaciones y probar nuevas ideas... (en serio, teneis que probarlo )