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

[mcleod_ideafix]

Imaginemos que queremos usar un 68000 de Motorola. Perfecto, no tenemos que preocuparnos de la memoria y podemos acceder a 1 MB en su versión más básica. Es potente de la leche, sobre todo si usamos la versión de 32 bit... pero ni es fácil de programar, ni tienes tanta variedad de recursos de programación, etc.

Eh eh! Ahí disiento. El 68000 tiene el ensamblador más "bonito" que haya visto en mucho tiempo. Tiene compiladores de C (¡si hasta tiene Linux portado!), y al ser el micro usado en Amiga, Atari, Mac... tiene soporte de todo lo soportable. Incluso se fabrica en la actualidad (FreeScale)

Ya me gustaría poner un Z80180 a 20 MHz, que direcciona 1 MB, y meter un modo gráfico de 640x480 con 16 bits de color, salida HDMI, sonido de 8 canales por conversor D/A, etc... pero lo iba a programar el Tato y costaría un dineral. Es más... para eso te compras un PC de segunda mano y es más potente.

Cuando empecé a planear (sólo se quedó en eso, un plan) lo que para mi fuera el Spectrum Nex-Gen, pensé en usar un Z8000. De hecho incluso compré algunos Z8000, con MMU y todo, pensando en que el ensamblador iba a ser más o menos igual, que me sería familiar.... Nada de eso. Era bastante diferente, y para colmo, para el Z8000 sí que no he encontrado casi nada de compiladores o ensambladores

El Z80, además de archi-conocido, es un micro que se sigue fabricando en la actualidad, así que aún tiene cuerda para rato (¡y existe soft-core para FPGA! )

Ahora, que como te digo una cosa, te digo la otra: el Z80 no es el micro más amigable que hay cuando te encuentras con el problema de compartir memoria. Otros micros, como el 6510, lo ponen más sencillo: cuando el reloj está alto, acceden a memoria, cuando está bajo, no acceden (o quizás era al revés).

[scooter]

Precisamente estaba pensando en un z80 "extendido" para que sea mas fácil de programar, claro que si ese z80+ resulta ser un bicho raro sin herramientas que supone un cambio importante de mentalidad, si los compiladores soportan la paginación sobre el z80 "a secas"entonces nada. Lo bueno de tener una opinión es que se puede cambiar.

[radastan]

Eh eh! Ahí disiento. El 68000 tiene el ensamblador más "bonito" que haya visto en mucho tiempo. Tiene compiladores de C (¡si hasta tiene Linux portado!), y al ser el micro usado en Amiga, Atari, Mac... tiene soporte de todo lo soportable. Incluso se fabrica en la actualidad (FreeScale)

Que conste que tengo micros 68000 en casa para hacer pruebas...

De verdad, prefiero el Z80 para empezar, si esto llega a buen término ya hablamos de un bicho superior en el futuro.

[mcleod_ideafix]

Que conste que tengo micros 68000 en casa para hacer pruebas...

Yo tengo aquí, que compré hace poco tiempo, unos cuantos 68008. Adivina para qué tengo pensado usarlos... (¿dónde está el emoticono de silbar y mirar para otro sitio?)

De verdad, prefiero el Z80 para empezar, si esto llega a buen término ya hablamos de un bicho superior en el futuro.

El Z80, o cualquiera de los otros micros emblemáticos de 8 bits (6502, 6809) es perfecto para comenzar

[scooter]

Yo aprendí código máquina con el 6502.. que tempos aquellos!
Con el ensamblador "boli bic + libreta", eso era depuración y lo demas tonterías

[mcleod_ideafix]

Radas, una propuesta para incluir en el clon: interrupción raster, configurable en el número de línea en la que se quiere dar la interrupción.

¿Cómo? Se guarda el número de línea donde quieres dar la interrupción en un latch de 8 bits (que habrá sido cargado con un OUT a cierto puerto). Luego se compara la salida de ese latch con los 8 bits menos significativos del contador vertical usando un 74HCT682. La salida de ese comparador será 0 cuando la cuenta llegue al valor del latch, y 1 en el resto de los casos.

Para tener la interrupción en el retrazo vertical habitual (que se dispare cuando el televisor está en modo retrazo vertical), escibirías el valor 255 en el latch (de acuerdo con los timmings calculados para 7MHz que hasta ahora estamos usando).

Para evitar que se dispare la interrupción dos veces seguidas en el mismo campo de video (por ejemplo, que lo programes en la línea 2 y también salte en la 258), puedes hacer un OR de la salida del comparador (activa a nivel bajo) con el valor del bit 8 del contador vertical (que será 0 sólo cuando el contador está contando de 0 a 255).

Para restringir el pulso de interrupción para que dure 32 estados de reloj de pixel (conveniente para que el Z80 no redispare la interrupción cuando aún está en ella) haz OR de la salida arriba generada con el OR de todos los bits del contador horizontal desde el bit 5 hasta el 8.

En resumen, algo así:

Bus de datos de la CPU conectado a la entrada del registro de 8 bits 74HCT574
Entrada de reloj del registro conectado a un decodificador que reconozca una operación de escritura en cierto puerto de E/S (a definir)
Salida de ese registro al puerto P del comparador 74HCT682
Bits 0 a 7 del contador vertical al puerto Q del 74HCT682
Salida P=Q del comparador se combina con OR con todos los bits 5 a 8 del contador horizontal OR bit 8 del contador vertical
El resultado de todos esos OR's, va al pin INT del Z80

Con esto consigues una interrupción raster programable. ¿Para qué sirve? Pues:
- En un juego en el que la acción se desarrolle en cierta zona de la pantalla, pones la interrupción ráster para que se dispare justo después de la zona. Así tienes más tiempo para repintarla para el siguiente cuadro de pantalla. O hilando más fino: la rutina de gestión de sprites podría funcionar ahora así: para todos los sprites en pantalla, se calcula cuál de ellos está más abajo en la imagen, y se calcula en qué posición estará cada uno en el frame siguiente. De esos dos valores escoges el mayor (el que representa a la línea de pantalla más inferior en la imagen) y programas la interrupción ráster ahí. De esa forma te aseguras de que tienes el máximo de tiempo disponible para hacer el repintado.
- Si implementas más de un modo de video (p.ej. monocromo y 2bpp) puedes saltar de uno a otro durante la generación de la imagen, y así por ejemplo tener una zona de acción en monocromo (gestión más rápida) y una zona de marcadores y arte del juego en 2bpp.
- Temporizaciones más precisas: ya no estás limitado a temporizaciones que sean múltiplo de 20ms, sino que puedes hacerlas múltiplo de 64us (de un retrazo de línea a la siguiente línea). Muy útil si quieres implementar cosas como sonido digital con un DAC, ya que podrás reproducir efectos de sonido digital sin circuitería adicional (no hará falta DMA) y con una "molestia" mínima para la CPU ya que no tiene que estar continuamente dedicada a generar sonido, sino que se haría por interrupciones.

[radastan]

Radas, una propuesta para incluir en el clon: interrupción raster, configurable en el número de línea en la que se quiere dar la interrupción.

No te miento si te digo que lo comprendo perfectamente pero que pocos van a usarlo. Ya que usa poca lógica lo meteremos, pero quisiera hacer otras pruebas por si fueran más útiles.

Yo casi preferiría algo tipo DMA, mucho más jugoso y útil para los programadores normales, pero es que no quiero convertir un proyecto sencillo en un monstruo (y más si hemos desechado el color por sencillez).

Para los que terminen usando PLD's será la mar de sencillo, el número de chips será el mismo, pero para el resto se nos puede complicar la cosa. Por cierto, dijiste que estabas justo de patillas... ¿cómo lo haces ahora?

Cuando tenga el circuito completo de vídeo tomamos la decisión, ¿te parece?

[EdgeM]

Por mi experiencia haciendo emuladores y pruebecillas, la interrupción raster que propone mcleod da mucho juego. La de pijadillas y efectos que se consiguen con esto

[mcleod_ideafix]

No te miento si te digo que lo comprendo perfectamente pero que pocos van a usarlo. Ya que usa poca lógica lo meteremos, pero quisiera hacer otras pruebas por si fueran más útiles.

Hombre.... habida cuenta que esto es un sistema que desde el principio tendrá esa característica, ¿por qué no usarla? No es como si se la pones a un Spectrum, que no podría aprovecharlo ningún software existente, pero es que esta máquina aún no tiene nada de software. El que se haga para ella, ¿por qué no iría a usarlo? Las máquinas que lo tienen de serie (SAM Coupé, C64) lo usan.

Para los que terminen usando PLD's será la mar de sencillo, el número de chips será el mismo, pero para el resto se nos puede complicar la cosa. Por cierto, dijiste que estabas justo de patillas... ¿cómo lo haces ahora?

Usando otro encapsulado, como VQ64 (64pines).

Cuando tenga el circuito completo de vídeo tomamos la decisión, ¿te parece?

Ok.

[PabloMarmol]

Volviendo a mi propuesta inicial... si el z80 tiene 256 ioports como el 8085 ¿por qué hay direcciones de 16 bits como 1ffd para los puertos?.

Porque es que el Z80 no tiene 256 puertos de E/S: ¡tiene 65536 puertos de E/S!

Yo soy mas de la opinión de los colegas de Zilog, y pienso que el Z80 tiene 8 bits para los puertos.
Esto se ve bien suponiendo que "realmente" tuviera 16 bits.
Si fuera así, cuando sacaron el Z80 les hubieran echado la bronca. Pero zilog, por dios, que has hecho con las INIR OTIR y similares, que a cada vuelta del bucle usan un puerto distinto! Esas instrucciones están totalmente jodid...as
No, esas instrucciones no están preparadas para 16 bits.
El Z80 es de 8 bits (para puertos). Y lo de poner otro registro mas en la parte alta es "una feature", una gracia que nos hacen los de Zilog, en plan "ya de tener que poner algo en A8-A15 pongo eso, y oye, si os sirve de algo pues me alegro", (y vaya que si sirve) pero el micro no lo hicieron para operar con puertos en 16 bits.