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

[mcleod_ideafix]

McLeod el problema del color no es hacerlo, es lo que ocupa en memoria. Sólo metiendo 4 colores por pixel ya tendríamos que usar 12K de RAM

O no... Usando 6144+6144 bytes puedes tener un modo parecido al del Timex HiColour, o el del SAM Coupé en modo 1, es decir, 16 colores para cada cuadro de 8x1 píxeles.
Usando 6144+3072 bytes tendrías 16 colores para cada cuadro de 8x2 píxeles.
Y así hasta la bien conocida resolución de 6144+768 bytes para tener 16 colores en cada cuadro de 8x8 píxeles.

Si existe algún chip gráfico que sea barato y fácilmente localizable lo empleamos sin dudar, menos trabajo y más calidad.

Chips gráficos, alguno hay que se comunica por SPI, pero están orientados a caracteres, más que a otra cosa. En SparkFun he encontrado éste:
https://www.sparkfun.com/products/8541
En el terreno de los softcores, he encontrado esta descripción
http://www.frank-buss.de/yagraphcon/index.html
que se corresponde a un chip gráfico con soporte hardware para varias operaciones. Se comunica por SPI.

Respecto al Z80 a 20 MHz... no sería mala idea, aunque eso va a implicar que mi osciloscopio no va a servirme de mucho (es digital de 20 MHz)

Pues también tendrías problemas para depurar señales de la VGA, que van a 25MHz.

De acuerdo en que lo más simple del mundo mundial, por supuesto, es trabajar en monocromo. Si lo que buscas es diseñar un micro simple simple simple, pues monocromo es la mejor opción. Como ando despistado, es por eso que querría saber qué se pretende hacer con este micro una vez diseñado. O sea, para qué lo querrías usar. ¿Juegos? ¿BASIC? ¿CP/M? Para lo último es para lo que menos necesitarías el color, pero para lo primero, cuanto menos sería recomendable.

[radastan]

Te respondo McLeod con las intenciones de este montaje:

- Aprender la arquitectura de un ordenador a nivel básico
- Aprender la arquitectura de un sistema operativo a nivel básico
- Crear algo que luego podamos usar aunque sea para hacer cuatro cosas (la compact flash da mucho juego y sus tiempos de carga hacen que 32Kb permitan muchas cosas).
- Algún jueguecillo a nivel de ejemplo y reto personal
- ¿CPM quizás?

Como ves es algo más orientado a aprender que a ser un sistema con su base de usuarios. Creo que lo correcto es partir de esto y luego ya tratar de hacer un segundo sistema más potente con lo aprendido, además tiene su encanto un sistema tan sencillo, que quieres que te diga. Podemos ponerle un conector de expansión si quieres para el que quiera llegar un poco más lejos, con la posibilidad de poder paginar una parte de la memoria o anular la ROM desde el conector.

Es por eso que ni he hablado de audio, creo que con un simple conversor D/A de resistencias con su buffer nos valdría (no va a estar orientado a hacer efectos digitales espectaculares) y es por no poner un simple beeper que me parece ya ridículo.

Así que la pregunta es: ¿qué opciones de vídeo podemos darle que no sean complicadas? personalmente me atrae más la de monocromo con tonos de gris, o que los 4 colores sean seleccionables de una paleta.

[mcleod_ideafix]

Te respondo McLeod con las intenciones de este montaje:

- Aprender la arquitectura de un ordenador a nivel básico
- Aprender la arquitectura de un sistema operativo a nivel básico
- Crear algo que luego podamos usar aunque sea para hacer cuatro cosas (la compact flash da mucho juego y sus tiempos de carga hacen que 32Kb permitan muchas cosas).
- Algún jueguecillo a nivel de ejemplo y reto personal
- ¿CPM quizás?

Si estas son las intenciones, te diré que ni siquiera necesitas una pantalla. Puedes hacer que tu microordenador se comunique mediante terminal. De esa forma matas dos pájaros de un tiro: la entrada por teclado y la salida por consola.

Claro que si lo que quieres es un sistema stand-alone, entonces sí, hay que implementar video y entrada por teclado. Por cierto, ¿qué has pensado para la entrada por teclado? Lo más sencillo que se me ocurre es implementar el protocolo PS/2 en software y usar por tanto un teclado PS/2. La electrónica necesaria es muy pequeña (un puerto de escritura de 2 bits y un puerto de lectura de 1 bit).

Es por eso que ni he hablado de audio, creo que con un simple conversor D/A de resistencias con su buffer nos valdría (no va a estar orientado a hacer efectos digitales espectaculares) y es por no poner un simple beeper que me parece ya ridículo.

¿Por qué no? Será ridículo, pero bien usado da un juego que no veas. Pregunta si no a Yerzemey (o como se escriba).

Así que la pregunta es: ¿qué opciones de vídeo podemos darle que no sean complicadas? personalmente me atrae más la de monocromo con tonos de gris, o que los 4 colores sean seleccionables de una paleta.

Que se implementen en lógica discreta sin llenar una placa de chips: video monocromo orientado a bitmap (no orientado a caracteres como el Jupiter ACE). Memoria compartida y resolución de contienda con WAIT, al estilo del ACE.
Que se implemente en CPLD: pues depende de qué CPLD uses, pero sin mucho esfuerzo ni CPLD gordas, video en color RGB en modo "chunky" o con planos indpendientes bitmap-color al estilo Spectrum,Timex o Coupé. Contienda por WAIT o sin contienda. Lo de la paleta lo descarto en principio porque se pasaría de memoria usable dentro de la CPLD. La CPLD en la que estoy pensando es una XC9572XL en formato PLCC44. Para los miedosos con el montaje SMD, estas CPLD's pueden venir en un zócalo de 44 pinchos que se suelda sin problemas.

[radastan]

Claro que si lo que quieres es un sistema stand-alone, entonces sí, hay que implementar video y entrada por teclado. Por cierto, ¿qué has pensado para la entrada por teclado? Lo más sencillo que se me ocurre es implementar el protocolo PS/2 en software y usar por tanto un teclado PS/2. La electrónica necesaria es muy pequeña (un puerto de escritura de 2 bits y un puerto de lectura de 1 bit).

Es por eso que ni he hablado de audio, creo que con un simple conversor D/A de resistencias con su buffer nos valdría (no va a estar orientado a hacer efectos digitales espectaculares) y es por no poner un simple beeper que me parece ya ridículo.

¿Por qué no? Será ridículo, pero bien usado da un juego que no veas. Pregunta si no a Yerzemey (o como se escriba).

Así que la pregunta es: ¿qué opciones de vídeo podemos darle que no sean complicadas? personalmente me atrae más la de monocromo con tonos de gris, o que los 4 colores sean seleccionables de una paleta.

Que se implementen en lógica discreta sin llenar una placa de chips: video monocromo orientado a bitmap (no orientado a caracteres como el Jupiter ACE). Memoria compartida y resolución de contienda con WAIT, al estilo del ACE.
Que se implemente en CPLD: pues depende de qué CPLD uses, pero sin mucho esfuerzo ni CPLD gordas, video en color RGB en modo "chunky" o con planos indpendientes bitmap-color al estilo Spectrum,Timex o Coupé. Contienda por WAIT o sin contienda. Lo de la paleta lo descarto en principio porque se pasaría de memoria usable dentro de la CPLD. La CPLD en la que estoy pensando es una XC9572XL en formato PLCC44. Para los miedosos con el montaje SMD, estas CPLD's pueden venir en un zócalo de 44 pinchos que se suelda sin problemas.

Para no complicarnos la vida:

- Teclado y ratón PS/2 (no creo que sea muy complicado meter el ratón de paso)
- Sonido por Beeper o por D/A, lo dejo a vuestra elección, pero ninguno de los dos casos debe parar la CPU como en el ZX Spectrum
- Vídeo orientado a Bitmap, 256x192 de resolución en monocromo, memoria compartida de contienda con WAIT

Así podemos implementar todo con lógica discreta para comprobar el buen funcionamiento y luego hacer una versión con CPLD que quite chips de por medio.

Para la Compact Flash usaremos la interfaz de 8 bits pero usando los 16 bits de datos del conector (usaremos dos puertos de e/s de 8 bits y en paz, con buffer si hace falta). De esta forma será posible usar FAT.

La entrada y la salida de audio creo que ya hemos aprendido la lección con el clon de ZX Spectrum y no habrá problemas, por supuesto usaremos una velocidad turbo por defecto.

¿Todos de acuerdo? ¿Beeper o conversor D/A de resistencias?

[mcleod_ideafix]

Para no complicarnos la vida:

- Teclado y ratón PS/2 (no creo que sea muy complicado meter el ratón de paso)

Bueno, con lo del PS/2 hay algo que se me escapó comentar: aunque no hay problema en implementar el protocolo PS/2 en modo "bit bang" en software, hay que estudiar si es posible "callar" al controlador del teclado para que sólo envíe teclas cuando estamos leyéndolas. Por defecto, el teclado lanza una interrupción cuando tiene una tecla nueva para enviar, y eso lo haría complicado de usar con un esquema simple en el que sólo tengamos una interrupción para el retrazo vertical (porque por cierto, aún no hemos hablado de las interrupciones).
Si es posible usar un protocolo de parada y espera a este nivel con el teclado y el ratón, entonces no hay problema en usarlos sin complicar la electrónica.

- Sonido por Beeper o por D/A, lo dejo a vuestra elección, pero ninguno de los dos casos debe parar la CPU como en el ZX Spectrum

Voto por sonido tipo beeper usando un divisor de frecuencia programable (un timer, vamos) si pretendes que no pare a la CPU. Sonido D/A sin parar a la CPU requiere DMA.

- Vídeo orientado a Bitmap, 256x192 de resolución en monocromo, memoria compartida de contienda con WAIT

OK a eso. La forma más sencilla (y más burra) de resolver la contienda es como lo hace el Jupiter ACE, que detiene al procesador con WAIT hasta que termina de pintar una línea de video, en caso de contienda. Es una contienda muy gorda pero es la más fácil de implementar.

Así podemos implementar todo con lógica discreta para comprobar el buen funcionamiento y luego hacer una versión con CPLD que quite chips de por medio.

Fíjate que yo iba a proponerte prototiparlo en una FPGA para probar así todo el conjunto, y luego irlo "traduciendo" a lógica discreta.

También estoy pensando en qué cuarzo (reloj) usaremos. De esto depende el formato de pantalla y la velocidad del resto de los elementos. Había pensado en 8MHz, porque son unos relojes muy usados en los PIC's, pero tiene el problema de que para contar 64uS hay que contar hasta 512, y si tenemos 256 píxeles, ésos ocuparán un rectángulo reducido en el centro de la pantalla, con un borde inmenso. Tampoco se puede usar dos ciclos por pixel porque entonces no tienes ciclos para implementar el hbalnking y resto de cosas que "no se ven" en pantalla, así que la opción es usar una frecuencia de reloj de unos 6 o 7MHz (o un múltiplo de estos). Una frecuencia muy común es 14.31818, que es 4 veces la frecuencia de reloj NTSC y por tanto un cristal fácilmente localizable. ¿Alguna idea a este respecto?

[radastan]

Bueno, con lo del PS/2 hay algo que se me escapó comentar: aunque no hay problema en implementar el protocolo PS/2 en modo "bit bang" en software, hay que estudiar si es posible "callar" al controlador del teclado para que sólo envíe teclas cuando estamos leyéndolas.

Hay varios esquemas por la red para implementar el protocolo PS/2 con un PIC de los económicos y no complicarte la vida. De todas formas luego lo estudiamos, ahora es el momento de saber lo que queremos para marcarnos los objetivos.

Voto por sonido tipo beeper usando un divisor de frecuencia programable (un timer, vamos) si pretendes que no pare a la CPU. Sonido D/A sin parar a la CPU requiere DMA.

Perfecto, lo del timer me gusta y es muy sencillo de implementar.

- Vídeo orientado a Bitmap, 256x192 de resolución en monocromo, memoria compartida de contienda con WAIT

OK a eso. La forma más sencilla (y más burra) de resolver la contienda es como lo hace el Jupiter ACE, que detiene al procesador con WAIT hasta que termina de pintar una línea de video, en caso de contienda. Es una contienda muy gorda pero es la más fácil de implementar.

Si hay otra forma sencilla de hacer que la cosa vaya más rápida estoy abierto a sugerencias, de todas formas yo optaría por meter el WAIT sólo si la CPU trata de direccionar esa área de memoria (los 16K famosos).

Así podemos implementar todo con lógica discreta para comprobar el buen funcionamiento y luego hacer una versión con CPLD que quite chips de por medio.

Fíjate que yo iba a proponerte prototiparlo en una FPGA para probar así todo el conjunto, y luego irlo "traduciendo" a lógica discreta.

Cada cual que lo haga según sus posibilidades, es que en mi caso meterme con FPGA de golpe y porrazo "es demasié".

También estoy pensando en qué cuarzo (reloj) usaremos. De esto depende el formato de pantalla y la velocidad del resto de los elementos. Había pensado en 8MHz, porque son unos relojes muy usados en los PIC's, pero tiene el problema de que para contar 64uS hay que contar hasta 512, y si tenemos 256 píxeles, ésos ocuparán un rectángulo reducido en el centro de la pantalla, con un borde inmenso. Tampoco se puede usar dos ciclos por pixel porque entonces no tienes ciclos para implementar el hbalnking y resto de cosas que "no se ven" en pantalla, así que la opción es usar una frecuencia de reloj de unos 6 o 7MHz (o un múltiplo de estos). Una frecuencia muy común es 14.31818, que es 4 veces la frecuencia de reloj NTSC y por tanto un cristal fácilmente localizable. ¿Alguna idea a este respecto?

¿Y si usamos 320x200? ya que usamos monocromo podemos usar una mayor resolución y así el borde no es tan acusado.

Lo que me resulta curioso es que optes por NTSC y no por PAL, ¿algún motivo concreto?

[mcleod_ideafix]

Lo que me resulta curioso es que optes por NTSC y no por PAL, ¿algún motivo concreto?

En este caso la frecuencia de reloj no tiene nada que ver con implementar una señal PAL o NTSC. 14.31818 es una frecuencia muy común, y por tanto es fácil encontrar cuarzos a esa frecuencia. Diviendo entre 2, tienes una frecuencia de pixel de poco más de 7MHz, lo que daría una imagen con un borde ligeramente mayor que el del Spectrum.

320x200 tiene el pequeño handicap de que para trabajar con esa resolución necesitas un valor de 16 bits en lugar de uno de 8, y eso puede complicar más tarde las rutinas de pintado de líneas o de cálculo de dirección para pintar caracteres. Además, no sé si saldrían de esa forma píxeles cuadrados o rectangulares... No, creo que si se elige una frecuencia de 7MHz para el reloj de pixel, los píxeles siguen saliendo cuadrados aunque haya más

-- 02 Oct 2012, 17:36 --

Hay varios esquemas por la red para implementar el protocolo PS/2 con un PIC de los económicos y no complicarte la vida. De todas formas luego lo estudiamos, ahora es el momento de saber lo que queremos para marcarnos los objetivos.

Ah! así sí. Pensé que querías hacer algo realmente simple. Usando un PIC no hay que implementar el protocolo en software ni nada de eso (bueno, no en software de Z80)

Perfecto, lo del timer me gusta y es muy sencillo de implementar.

Lo puedes incluir en el PIC, y así tenerlo a modo de "coprocesador" muy al estilo de como se usa el 8042 en el QL (teclado y sonido precisamente)

Si hay otra forma sencilla de hacer que la cosa vaya más rápida estoy abierto a sugerencias, de todas formas yo optaría por meter el WAIT sólo si la CPU trata de direccionar esa área de memoria (los 16K famosos).

Sí, sí, me he explicado mal. Es así como lo implementa el ACE. La contienda surge si hay colisión en el acceso a memoria compartida, pero si surge, el retraso se prolonga hasta que termina de pintarse la línea (en realidad, el peor caso es que la contienda ocurra justo al iniciarse la exploración de la parte "paper" de la pantalla, en cuyo caso el retraso dura hasta que termina de pintarse ese "paper". En el Jupiter ACE esto significa unos 39.38us de retraso máximo)

Cada cual que lo haga según sus posibilidades, es que en mi caso meterme con FPGA de golpe y porrazo "es demasié".

Otra forma de enfrentarse al asunto es escribiendo un emulador. Ten en cuenta que de alguna forma tendrás que probar el S.O. que desarrolles. Un micro como el que has descrito se puede prototipar en FPGA en un fin de semana (o menos), pero el software que corra en ROM... eso puede tardar perfectamente meses (años, si partes de cero, y no es tu principal actividad)

[Joss]

Queria animaros a que continueis con el tema. Me parece muy interesante. Intento aportar un par de ideas:

- El apartado gráfico creo que es mejor hacerlo con componentes discretos que se puedan encontrar en tiendas. Una CPLD necesita equipo extra para programarla y puede echar atrás a muchos que no tengan (como yo .... ) un nivel avanzado con lo que se reduce el número de gente que lo probará en casa.Componentes discretos son mas accesibles y solo es cuestión de paciencia y algo mas de tiempo ....

- Si podeis hacerlo compatible con el CP/M suena bien. Asi existe un S.O. con el que ir tirando hasta que se escriba uno nuevo. Bueno, esto no lo entendí bien en la discusión, no se si puede hacerse así por las buenas, o hay que recompilarlo.

- Me pareció entender al principio que seria un proyecto basado en Z80. Si meteis PICS y demas "copros" quizás se pierda un poco la idea principal.

La idea del emulador también suena bien ( hasta le puede ayudar a Hark0 y a muchos otros como yo ). Así se tiene un prototipo en software que puede usarse para ir desarrollando código para la máquina. Implementarlo en una FPGA también suena bien, pero me repito con el argumento de la CPLD, se necesita equipo extra y conocimientos que son mas difíciles de conseguir.

EDITO: Hay un libro online, que fue liberado para dominio público hace un par de años. A mi me ayudo a empezar a entender como están diseñados/implementados los computadores. Los mas expertos seguro que lo conoceis, para el resto como yo, ahí va:

Build your own Z80 computer - Steve Ciarcia
http://books.google.es/books?id=mVQnFgWzX0AC&printsec=frontcover&hl=es&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

[radastan]

- Me pareció entender al principio que seria un proyecto basado en Z80. Si meteis PICS y demas "copros" quizás se pierda un poco la idea principal.

La idea del emulador también suena bien

Usar un PIC no tiene ningún secreto, es pequeñito, encapsulado fácil de soldar, y se puede programar con un cable que lo puedes hacer tu en tu casa de forma sencilla. De todas formas llegado el caso ofertaré los "kits" de montaje yo mismo listos para ensamblar y no tenéis que preocuparos de nada, tengo varios programadores de PIC, CPLD, y lo que haga falta. No veáis un PIC como un copro, sino más bien algo para reducir circuitería.

Lo del emulador no sería complejo llegado el caso, la estructura hardware la vamos a definir nosotros (no hay problemas de documentación) y al estar basado en Z80 puedes usar los muchos emuladores en C que hay de ese procesador.

[mcleod_ideafix]

Una CPLD necesita equipo extra para programarla

Un PC con puerto paralelo es lo que necesitas. Es más barato hacerse o comprar hecho un JTAG para CPLD's de Xilinx, que, por ejemplo, un grabador de EPROM's. El software (WebISE) es gratuito.

y puede echar atrás a muchos que no tengan (como yo .... ) un nivel avanzado con lo que se reduce el número de gente que lo probará en casa.Componentes discretos son mas accesibles y solo es cuestión de paciencia y algo mas de tiempo ....

Y más caro (más componentes, placa más grande, mayor consumo de corriente), y más difícil de depurar (más propenso a errores en caso de mal montaje), y menos versátil (a la hora de añadir variaciones -PAL o NTSC por ejemplo- ). Sobre los conocimientos extra... Internet es tu amiga