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

[mcleod_ideafix]

Sin embargo, un diseño realizado desde el principio para ser implementado en FPGA o CPLD y que no use ningún elemento propio de éstas (como módulos DSP o cosas así) podrá portarse siempre a lógica discreta.

Repito, que no hay problema, que si quieres fijamos las especificaciones, te dejamos tiempo para implementarlo, y nos pasas la equivalencia en lógica discreta... pero algo me dice que como que eso sería darte todo el trabajo y ya estás bastante liado con otras sopotocientas cosas.

Sólo contestaba a lo que decía Joss sobre la conveniencia o no de implementarlo primero en lógica discreta. Fïjate que te comenté que sería buena idea prototiparlo en CPLD precisamente para que la depuración y los ajustes resulten mucho más sencillos. Después, con el diseño depurado y sabiendo que va a funcionar sí o sí, es cuando lo portas, si quieres, a discreta.

Si lo haces desde el principio en discreta, y tienes la mala suerte de que no te funcione a la primera, te tocará depurar, y depurar hardware es muy muy laborioso. A menudo un osciloscopio no será suficiente. Además, estarás tú solo depurando, porque nadie más tendrá hecha una placa prototipo con toda la lógica del chisme. No estamos hablando de copiar un esquema que se sabe que funciona, sino de hacer algo, parecido o no a lo que hicieron otros, pero que no deja de ser "nuevo". En el foro de speccy.org están haciendo un "Mastresizador" (o como se diga) para acoplarlo al clon de Harlequin y darle soporte de 128K y la cosa se les ha complicado durante una temporada (creo que había otro diseño parecido que abandonaron por difícil de probar y depurar). Si eso pasa con un circuito relativamente sencillo y que está documentado (en el esquemático del 128K), qué no será con uno del mismo orden de complejidad que el sistema de video del Jupiter ACE y que no es una copia de él.

Eso sí, si te pones y lo sacas, habrás aprendido una barbaridad sobre diseño digital

¿Dejarme tiempo para implementarlo? ¡Pero si ya lo hice ayer! (el chip gráfico, quiero decir). El pantallazo que mostré del ISE Webpack con las estadísticas se refiere a los resultados de la síntesis. El chip de video, en formato PC44 dentro de una XC9536(XL) ya existe, y se puede usar en el esquema de bloques que dibujé ayer.

Pero es que es eso... que si lo hago yo, pues no tiene gracia. Lo chulo es que vosotros (los interesados en diseñarlo y hacerlo) os enfrenteis a las mismas visicitudes a las que yo me enfrenté en su día. Lo primero, fijar las especificaciones de qué se quiere en video, y empezar a hacer números (de la manera que os he puesto antes).

[antoniovillena]

No se, ya os digo que estoy abierto a sugerencias, ayudadme a ir implementando el modo monocromo y cuando lo tengamos funcionando ya nos podemos plantear opciones como los tonos de gris, color, o lo que sea, y ver si realmente merece la pena. Es lo bueno del proyecto,que podemos cacharrear sobre la marcha y modificar las especificaciones finales si nos interesa.

Esto tendrías que decidirlo cuanto antes, no es algo que se pueda hacer sobre la marcha. Usar 4 tonos de grises ó 4 colores paletizados en realidad es más sencillo que hacerlo en monocromo si partes del diseño del ZX Spectrum, tan sólo hay que cambiar el registro de atributos por otro registro desplazamiento y sacar esos 2 bits por la salida de video (compuesto y/o RGB). Lo del video shadow no complica el hardware de video, el inconveniente es que te reduce la ROM a la mitad. Y no hace falta programar juegos para sacarle partido, se puede aprovechar desde el propio firmware, implementándolo en llamadas al sistema que escriban caracteres en la pantalla. Es una manera muy sencilla de evitar el parpadeo.

[radastan]

No se, ya os digo que estoy abierto a sugerencias, ayudadme a ir implementando el modo monocromo y cuando lo tengamos funcionando ya nos podemos plantear opciones como los tonos de gris, color, o lo que sea, y ver si realmente merece la pena. Es lo bueno del proyecto,que podemos cacharrear sobre la marcha y modificar las especificaciones finales si nos interesa.

Esto tendrías que decidirlo cuanto antes, no es algo que se pueda hacer sobre la marcha. Usar 4 tonos de grises ó 4 colores paletizados en realidad es más sencillo que hacerlo en monocromo si partes del diseño del ZX Spectrum, tan sólo hay que cambiar el registro de atributos por otro registro desplazamiento y sacar esos 2 bits por la salida de video (compuesto y/o RGB).

Pues no, yo había pensado en otra forma.

Un puerto de e/s que decida varias cosas:

bit 0 y 1: tono de borde en gris (da igual el modo de vídeo)
bit 2: modo de vídeo

Con el bit 2 se elige si coger los pixels con uno o dos bits, si es con uno el 0 es blanco y el 1 negro (o viceversa), si es con dos bits el siguiente bit indica que es tonalidad de gris y el bit de antes cambiaría por uno de los dos tonos de gris. Con simples puertas lógicas se puede hacer la selección y como si lo piensas apenas implica complicación o un gran número de chips.

Lo del parpadeo no es problema porque sólo vamos a usar las líneas impares de la imagen, por lo que hay mucho tiempo para tocar en pantalla sin que haya contienda (y el micro va a 7 MHz, casi el doble que en el Spectrum).

[mcleod_ideafix]

Lo del parpadeo no es problema porque sólo vamos a usar las líneas impares de la imagen

¿Mande?
¿Pretendes generar sólo un campo de los dos? En ese caso, más te vale que no seas epiléptico y que casi toda la pantalla esté a negro Si no, por lo menos el dolor de cabeza lo tienes asegurado .

[antoniovillena]

Lo siento pero no me queda muy claro que así sea más simple. Si te he entendido bien habría 2 modos de video, en el primero cada byte se traduce en 8 pixeles (memoria video desde $4000-$5800) y en el segundo cada byte son 4 pixeles (rango $4000-$7000). Implementar 2 modos de video requiere más hardware que implementar uno sólo. Sólo digo que con un único modo de video de bitplanes separados siempre podrías poner a 0 el rango $5800-$7000 y trabajar sólo con los primeros 6K en monocromo.

Con las lineas impares supongo que te refieres a que en vez de generar PAL a 625 líneas con frames diferenciados para líneas pares e impares, vas a usar un único campo de 312 líneas. El parpadeo se produce porque estás pintando en pantalla justo por donde pasa el haz de electrones, por lo que generas un frame en el que se mezcla contenido actualizado y contenido sin actualizar. Tampoco influye la contienda para nada, aunque no hubiese contención habría parpadeo igualmente.

-- 03 Oct 2012, 23:07 --

Lo del parpadeo no es problema porque sólo vamos a usar las líneas impares de la imagen

¿Mande?
¿Pretendes generar sólo un campo de los dos? En ese caso, más te vale que no seas epiléptico y que casi toda la pantalla esté a negro Si no, por lo menos el dolor de cabeza lo tienes asegurado .

Jeje... no te volverías epiléptico, lo único que verías es un efecto scanlines la mar de chulo porque supongo que las líneas pares serían negras, pero a costa de tener sólo 25fps (eso sí, la contienda se reduciría a la mitad).

[Joss]

Gracias mcleod por la contestación. Ahora lo tengo mas claro .

Yo me puse con el Quartus para intentar hacer funcionar el CPCTRex en una DE1. No te puedo decir si es mejor o peor porque no me enteré de un pimiento de lo que hacia y todavía no lo he hecho funcionar .... . De ahí que quiera/tenga que empezar por abajo para poder comprenderlo.

Por lo que dices las FPGAs/CPLDs son mas precisas que la lógica discreta, y sopongo que "algo" menos precisas que el diseño en papel. No me había parado a pensarlo. Quizás otro requerimiento es que sea robusto frente a la tolerancia de los componentes usados. En cualquiera de los dos casos se puede aprender algo de como llevar a la práctica un diseño de esta embergadura ...... el camino es el objetivo, supongo ah! el libro que recomiendas ya lo he encargado

[mcleod_ideafix]

Por lo que dices las FPGAs/CPLDs son mas precisas que la lógica discreta, y sopongo que "algo" menos precisas que el diseño en papel...

Bueno... no es una cuestión de precisión, sino de versatilidad. Lo más versátil es trabajar al nivel RTL (transistor). Le sigue (un poco menos versátil), el diseño con lógica discreta y señal mixta, y luego, el diseño con lógica configurable (CPLD y FPGA). Claro que cuanto más te acerques en el diseño al transistor puro y duro, más difícil es realizar cambios, depurar, etc.

Eso significa que un diseño descrito a alto nivel, como para implementarlo en FPGA, puede traducirse para hacerse con lógica discreta, y que un diseño en lógica discreta puede traducirse al nivel RTL; es análogo a cómo cualquier programa en C puede traducirse a ensamblador, y cualquier programa ensamblador puede traducirse a código máquina. En el sentido contrario, no siempre es posible, o es muy difícil.

En la industria se usan precisamente las FPGA's para prototipar lo que después se llevará al nivel RTL (es decir, a un chip más o menos custom). Así se hizo, por ejemplo, el DTV64. Su autora, Jeri Ellsworth, lo prototipó antes para FPGA. Luego los chinos de turno pasaron esa descripción a un chip semicustom (creo que era un semicustom), que es el que se ve en forma de gota de resina epoxy en el cacharrito ese.

[PabloMarmol]

Con las lineas impares supongo que te refieres a que en vez de generar PAL a 625 líneas con frames diferenciados para líneas pares e impares, vas a usar un único campo de 312 líneas.

Respecto a lo de las 312 líneas.... ¿Habéis pensado en usar "312/313/..." o "312+0,5/..." ?

Porque con 312 líneas ocurre lo del spectrum, que sale una frecuencia de 50,08 Hz y después en los programas es un dolor cuando hay que llevar una cuenta de tiempo, por los decimales.

[radastan]

Lo del parpadeo no es problema porque sólo vamos a usar las líneas impares de la imagen

¿Mande?
¿Pretendes generar sólo un campo de los dos? En ese caso, más te vale que no seas epiléptico y que casi toda la pantalla esté a negro Si no, por lo menos el dolor de cabeza lo tienes asegurado .

Tus ZX Spectrum funcionan así.

¡Se algo que McLeod no sabe!

[mcleod_ideafix]

Tus ZX Spectrum funcionan así.

¡Se algo que McLeod no sabe!

Noooooooo, te he preguntado si pretendes generar un solo campo, no si pretendes generar dos campos con la misma información, que es lo que hace el Spectrum. El tiempo sin contienda (medido en microsegundos) será el mismo que el que tienes en el Spectrum, uses una señal PAL progresiva "a la Sinclair" (dos campos, misma información, misma posición) o uses una entrelazada (dos campos, misma o diferente información, diferente posición).

Es que mi extrañeza viene de que tú dices que hay un montón de tiempo sin contienda "porque solo usamos las líneas impares", y yo he deducido (no sé si erróneamente) que tú quieres que el ordenador sólo pinte las líneas impares, y durante las pares (el otro campo), no haga nada, con lo cual ciertamente tendrías un montón de tiempo - una pantalla entera - sin contienda.