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

[radastan]

¿Pero el modo grafico tiene caracteres que puedan ser cambiados por un byte? eso acelera el movimiento de graficos grandes, que aunque se muevan de 8 en 8, vale la pena.

No, el mapa de pantalla es lineal tipo bitmap. Vamos a lo sencillo y práctico.

[Toniman]

Ok, ¿Alguna idea de cuanto dinero podra costar el ordenador? aproximaciones.

[radastan]

Ok, ¿Alguna idea de cuanto dinero podra costar el ordenador? aproximaciones.

No tengo la menor idea.



Pero así a voz de pronto costará unos 50 euros como mucho, si lo haces con lógica discreta. Si aunamos todo lo posible en PLD y PIC posiblemente salga por 30 eurillos.

La idea es que sea económico para que todo el que se anime pueda tener uno.

Cuando terminemos el diseño veremos hasta donde podemos llegar en "miniaturización". Conociendo a Mc Leod es capaz de sacar una versión que sea una PLD, un Z80, una RAM de 64K, y una EPROM de 16K (que no es ninguna locura).

[jepalza]

Cuando terminemos el diseño veremos hasta donde podemos llegar en "miniaturización". Conociendo a Mc Leod es capaz de sacar una versión que sea una PLD, un Z80, una RAM de 64K, y una EPROM de 16K (que no es ninguna locura).

Me vais a perdonar la "intrusión", pero entonces ya no es un ordenador "de toda la vida". Para tener un sistema Z80 metido en una FPGA, no muevo un dedo.
Son DOS COSAS diferentes: o bien un ordenador DE SIEMPRE, con sus 8255, Z80, SRAM, TMS, etc, o bien un CPLD, con un Z80.....

Lo bonito, lo chulo, lo divertido, es un chisme al mas puro estilo Jupiter Ace, o sea, solo electrónica discreta, con sus 74LS, su Z80, 27c256 y 62256. Es que ponerse a meter FPGA para video, para I/O, para "no se qué" , deja de ser un ordenador clásico, sin trasteo posible.

Que me acribillareis, lo sé (sobre todo Mcleod_Ideafix), pero son dos cosas diferentes. Yo no quiero un ordenador moderno, que para eso, ni siquiera le pongo un Z80, lo meto todo en una FPGA, le pongo un teclado, y ya tengo un micro en menos de 4x4cm.

Un ejemplo de lo que digo, está en el ya citado Jupiter Ace, o en el que estoy haciendo ahora, el TVGames de Elektor, que son chips de siempre, nada moderno (a lo sumo, la RAM por la cosa de la cantidad de chips a emplear).

Ponerse a meter la mayoría de cosas en una FPGA/CPLD/XILINX es hacer un sistema parecido al DTV64 de Commodore, y deja de tener su gracia, o al menos, la diversión cambia, y pasa de ser trasteo a ser solo programacion.

Ala, ya podeis machacarme, que me pongo las orejas de burro

Nota: el mejor ejemplo, es el de "weirdocollector", con su --> http://www.youtube.com/user/weirdocolle ... rid&view=0 , pelado, sin nada, solo una CF

[radastan]

Jepalza, TODO se va a diseñar con lógica discreta. Salvo el tema del PS/2 y el sonido que irán en un PIC (que es tope de divertido de programar) el circuito se podrá ensamblar como dices. Es más, yo voy a crearme una placa de esta forma, ya que es más divertido y se tiene más control sobre lo que pasa (puedes medir señales intermedias y ver como son).

La solución de McLeod también me la construiré, me mola eso de tener un pequeño ordenador tamaño pañuelo, y esa solución será la mejor para los menos manitas o los que sólo quieran el ordenador para cacharrear y no hacerlo.

Así que no te pongas las orejas de burro que no es ninguna barbaridad lo que pides, ya que lo bueno de este ordenador es que va a contentar a todos.

[jepalza]

Así que no te pongas las orejas de burro que no es ninguna barbaridad lo que pides, ya que lo bueno de este ordenador es que va a contentar a todos.

MMmmmm, vale, aceptamos cocodrilo como animal de compañía....

[scooter]

Mapearlo en e/s supone un acceso indirecto al estilo msx si no me equivoco o como funciona el vdc del c128 que solo ocupa 2 direcciones de memoria pese a tener hata 64k de video

[mcleod_ideafix]

Me alegra saber que tenemos a alguien como McLeod detrás, pero si esto es para aprender lo suyo es que empecemos desde abajo y no dando directamente la solución. ¿Puedes poner el esquema que has usado en lógica discreta?

Pues no porque.... no trabajo en lógica discreta. Lo he prototipado en una CPLD usando Verilog, y convertir eso a chips TTL es un poco coñazo. Si acaso lo que puedo hacer es un diagrama de bloques de cómo quedaría la CPLD por dentro, pero no usando chips 74XX sino módulos ad-hoc.

Por otra parte, a quien quiera aprender sobre la generación de la señal de video, opino que lo mejor que puede hacer es leerse el libro de la ULA de Chris Smith.

[radastan]

Bueno señores, empezamos a cacharrear para hacer la gráfica con lógica discreta:

Nuestros amigos los contadores

Tenemos una serie de señales que hay que generar: portadora, subportadora, reloj de pixel... ¿Qué hacemos? ¿Cómo sacamos todas esas frecuencias? El secreto está en usar contadores.

El 74LS393 es la clave, se trata de un encapsulado que trae dos preciosos contadores de 4 bits:



Cada contador usará la entrada (A) y la usará para ir contando impulsos, por lo que si metemos una señal de reloj nos contará cíclicamente en formato BCD con 4 bits (Qa Qb Qc Qd):



Adicionalmente también tienen una entrada de borrado (clear).

¿Y cómo vamos a usar esto para generar frecuencias? Muy simple, si os fijáis en los bits de contaje veréis que el primero de ellos es igual a la entrada A, el siguiente sería la entrada A dividida por dos (cada dos pulsos genera uno), y así sucesivamente. Obtenemos de una señal de reloj tres señales divisores por 2,4, y 8.

Quiere decir que si metemos 7Mhz obtendremos con un contador las frecuencias:

- 3.5 MHz
- 1.75 MHz
- 0.875 MHz

Buen truco, ¿verdad?. Ahora nos vamos a fijar en el circuito de vídeo del Jupiter Ace, ya que es un buen ejemplo:

contadores_jupiter.png (39.12 KiB) Visto 7427 veces

Si os fijáis el Jupiter Ace usa una señal de reloj de entrada (6.5 MHz para ser exactos) y a base de contadores y un poco de lógica digital obtiene los pulsos de sincronismo horizontal (LINE) y vertical (FIELD). La señal de sincronismo vertical, al significar una nueva pantalla, se usa también para llevar una interrupción a la CPU para avisarnos de ello y que actuemos en consecuencia (si la memoria es contenida se accede más lentamente cuando escribes en pantalla, lo cual se aprovecha en el sistema operativo para leer el teclado y el resto de e/s).

Nosotros vamos a copiar esta parte del circuito tal cual, y vamos a añadir un reloj de pixel para formar los pixels de pantalla (también necesitaremos contadores para direccionarlos en memoria de forma secuencial). Al ser nuestra memoria de pantalla lineal nos bastará con ir sumando de uno en uno y el mapa de pantalla irá leyendo exactamente igual que lo hace en un televisor. Por supuesto sólo vamos a usar líneas impares (recordemos que cada imagen se compone de dos imágenes entrelazadas a 25 Hz cada una), por lo que no vamos a tener que preocuparnos del entrelazado tampoco. Por cierto, el ZX Spectrum usa la misma técnica, sólo dibuja los pixels en líneas impares, por eso se ven un poco difuminados los pixels.

[mcleod_ideafix]

Esto..... unas cuántas puntualizaciones

Para empezar hay que distinguir entre dos formatos: PAL (la que usamos en España) y NTSC (la que usan en EEUU por ejemplo). La señal PAL usa una frecuencia "portadora" de 50 Hz, mientras que la NTSC usa una frecuencia de 60 Hz.

Una señal de video monocroma va en banda base. No usa ninguna portadora. La única portadora que hay dentro de una señal de video compuesto es la de 4.43MHz que lleva el color, pero como aquí no hay color, no hay portadora. Las frecuencias que citas son frecuencias de campo. Creo que sería mejor antes definir algunos conceptos como: qué es un cuadro, qué es un campo, qué es una señal progresiva y entrelazada, etc.

Para el que no lo sepa, las frecuencias las marcan las redes eléctricas

No estoy seguro de si esto es así por eso, o es una simple casualidad el que ambas cosas tengan la misma frecuencia. Desde luego, un televisor no usa para nada la corriente alterna de la pared para sincronizarse ni nada de eso. Siempre he pensado que podría ser porque de esa forma el parpadeo de las bombillas de la iluminación en el plató no desfasa con la exploración que hace la cámara cuando toma la imagen. Si la frecuencia de ambos eventos es diferente, ocurriría un efecto de interferencia que haría que la imagen se viera a intervalos brillante y oscura.

A partir de la frecuencia base vamos a generar las subportadoras, que son las que van a llevar sumadas a la portadora la imagen a la pantalla.

No es ese el término correcto. No existen "subportadoras" como no existe "portadora" en esta señal. Como frecuencia base no se usa de hecho la frecuencia de campo, sino la frecuencia de pixel. Es de ahí de donde derivan el resto de frecuencias que se usan para generar video. Por ejemplo:

En el Spectrum la frecuencia de pixel son 7MHz. 448 períodos de esta señal duran 64us, con lo que tienes ahí la frecuencia de línea. 312 períodos de esta señal de frecuencia de línea duran 19.968ms (casi casi 20ms) lo que corresponde a la frecuencia de campo.

En el Jupiter ACE, que está todo más... "a la vista", tienes una frecuencia de pixel de 6.5MHz, que entra en un contador cableado para contar hasta 416. 416 períodos de la señal de 6.5MHz dan de nuevo 64us. Dejo como ejercicio identificar el circuito que cuenta líneas y que se resetea cuando llegas a 312 (¿o quizás es un número diferente?)

En la señal el valor de negro es 0V y el de blanco 0.7V, el valor de "ultranegro" se fija para -0.3V.

Por lo que tengo entendido, el negro es 0.3V, el blanco 0.7V (aunque en realidad se toman estos valores como porcentajes sobre el valor total de la señal, no como valores fijos), y el pulso de sincronismo 0V. De hecho, es común en los equipos que generan señales de video compuesto el acoplar dicha señal mediante un condensador, con lo que los valores de negro, blanco, sync, cambian por completo. Por otra parte, puedes generar una señal de video que tenga un valor pico a pico de más de 0.7V (como hace por ejemplo el Spectrum) y aun así verse bien, sin sobresaturación ni nada de eso.