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

[radastan]

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.

Eso es precisamente lo que quiero hacer, y no se si erróneamente o no pero juraría que es lo que hace el ZX Spectrum (lo leí en Microhobby y lo comprobé en mi televisor hace años). Otra cosa es como se vea en un televisor LCD... esa es la duda. Yo creo que lo suyo es sacar mis placas de inserción y probar el asunto para ver como queda.

Canibalizaré los componentes de la placa del Jupiter Ace ZdP.

¿Qué opciones hay para evitar la contienda? la mejor que se me ocurre es usar los 16K al doble de velocidad mediante buffers y así servir a la CPU y a la gráfica al mismo tiempo. Tendría que ver el diagrama de tiempos de la memoria para ver si es factible tal cosa, porque acceder a memoria no es instantáneo.

[scooter]

Si no me equivoco lo que hace el zx es pintar dos veces el mismo cuadro en el mismo sitio.

[radastan]

Si no me equivoco lo que hace el zx es pintar dos veces el mismo cuadro en el mismo sitio.

Más bien pintar la misma información en ambos campos. Cada imagen se compone de dos campos entrelazados, uno de líneas impares y otro de líneas pares.

Creo que va a ser más razonable inventar algo para la contienda, pero prefiero experimentar lo que pasa si usamos sólo las líneas impares por vídeo compuesto.

[scooter]

Tendrás un "flikeo" que no veas o si es un televisor "listo", una de dos, o no se verá nada o se verá mas oscuro; todo en gris pero a base de rayitas blancas y negras.

¿No hay comando "bis" para TV?; se envía un cuadro y le dices "bis" y el televisor lo repite él solo

-- 04 Oct 2012, 12:46 --

Por cierto, tengo en mente un mapa de memoria "imaginativo", no se como de viable sería:

físicamente tres chips; una rom de 16k, una ram de 16k y un ram de 64k

La Ram de 64kb va siempre, no hay que decodificar nada.
la rom va en la posición baja (para eso es un z80)
la ram de 16k va donde esté el vídeo.

Si se accede a las posiciones bajas como lectura se lee la rom pero como escritura se escribe en la ram. En un momento dado se puede desconectar la rom y entonces se accede a la ram continua, esto mas o menos es lo que hace el c64.

Si se accede a la memoria de vídeo, al escribir se escribe a la vez en las dos rams (esto es en lo que tengo duda, supongo que iría) y esa escritura si que tendría la contienda con el "chip de video", al leer no se lee la memoria de video, se lee la memoria copia que es la de 64kB continua, de este modo no habría contienda en lectura. Bueno, esto tendría la pega que si el chip de vídeo hace de splitter y mueve bloques de memoria por hard o algo así no serviría pero creo que no es el caso.

La pega de este sistema es que se tiran a la basura 32k pero igual es mas barato un chip de 64 que uno de 32k, a cambio se gana el tiempo de la contención de lectura y se gana un "modo allram" que puede ser útil.

[radastan]

Si se accede a la memoria de vídeo, al escribir se escribe a la vez en las dos rams (esto es en lo que tengo duda, supongo que iría) y esa escritura si que tendría la contienda con el "chip de video", al leer no se lee la memoria de video, se lee la memoria copia que es la de 64kB continua, de este modo no habría contienda en lectura. Bueno, esto tendría la pega que si el chip de vídeo hace de splitter y mueve bloques de memoria por hard o algo así no serviría pero creo que no es el caso.

Se te olvida que este sistema es buenísimo si no lees la pantalla, pero olvídate de scroll a menos que copies la pantalla en otra parte. No lo veo muy práctico.

[scooter]

Tienes copia en la ram de "abajo" porque escribes en las dos a la vez. Si hay scroll por hard o DMA a la ram de video entonces no funciona pero si todo se hace a manubrio como en el speccy si que debería de ir.

[mcleod_ideafix]

Eso es precisamente lo que quiero hacer, y no se si erróneamente o no pero juraría que es lo que hace el ZX Spectrum (lo leí en Microhobby y lo comprobé en mi televisor hace años). Otra cosa es como se vea en un televisor LCD... esa es la duda. Yo creo que lo suyo es sacar mis placas de inserción y probar el asunto para ver como queda.

Pues no sé que leerías en el MH, pero el Spectrum no hace eso. Tienes el libro de Chris de la ULA, así que mejor explicado que ahí no lo vas a encontrar: el Spectrum genera una señal PAL progresiva "fuera de norma". Genera dos campos, pero no son campo impar y campo par, sino que ambos van a la misma posición de pantalla por lo que entre línea y linea hay un huequito siempre que no se llena (de ahí que aparezcan los scanlines). Si generas un campo sí y otro no, lo que pasa es que la línea de píxeles en lugar de regenerarse cada 20ms lo hace cada 40ms, y la persistencia del fósforo de la tele no es suficiente como para mantener la imagen estable. El parpadeo será muy acusado. Luego te escribo un pequeño programa que simula en un Spectrum esta condición, y tú mismo podrás ver si merece o no la pena hacer eso.

¿Qué opciones hay para evitar la contienda?

Dos métodos, que caiga ahora mismo:
- Multiplexar en el tiempo la memoria: se multiplexa el bus de direcciones de forma que la dirección le venga o bien del chip de video, o bien de la CPU. El bus de datos se cablea de forma que haya un bus de entrada (para escribir en la memoria) y un bus de salida (de lo que se lee de la memoria). El bus de salida va a un latch que guarda el último dato leído. Esto hay que replicarlo para CPU y video. Dado que sólo la CPU escribe en memoria, el bus de entrada no hay que duplicarlo ni nada.
- Usar un doble (o triple) buffer en el bus de datos. Es decir, la memoria se está accediendo a ella todo el rato, de forma que los buffers de pixeles estén siempre con al menos un dato. Cuando la CPU pide acceso se hace una lectura de memoria y se guarda el resultado en un buffer (las lecturas del Z80 son leeeeentas y tener a la memoria ocupada con la CPU durante 2.5 ciclos de reloj de CPU podría dejar sin datos al buffer de video. Este es el sistema que usa el Inves para no tener contención.

[radastan]

- Usar un doble (o triple) buffer en el bus de datos. Es decir, la memoria se está accediendo a ella todo el rato, de forma que los buffers de pixeles estén siempre con al menos un dato. Cuando la CPU pide acceso se hace una lectura de memoria y se guarda el resultado en un buffer (las lecturas del Z80 son leeeeentas y tener a la memoria ocupada con la CPU durante 2.5 ciclos de reloj de CPU podría dejar sin datos al buffer de video. Este es el sistema que usa el Inves para no tener contención.

Este es el que más me llama la atención pero no lo acabo de ver.

Entiendo lo del buffer para la CPU, pero si la CPU accede y resulta que el buffer de pixels se acaba de agotar los dos querrán acceder a la vez a la memoria de vídeo. Se le puede dar preferencia al buffer, si, pero a costa de parar la CPU en esa casualidad.

¿Puedes explicarlo un poco más desarrollado?

[mcleod_ideafix]

¿Puedes explicarlo un poco más desarrollado?

Código: Seleccionar todo

var ScanActual,ScanReserva
var DirVRAM = 0
var DirCPU
var LecturaVRAMenCurso = 0
var LecturaVideoEnCurso = 0
var WE_VRAM = 1
var ScanReservaVacio = 1
var PixelAPintar = 7
var PIXEL

HACER en cada ciclo de reloj de 7MHz lo siguiente
      SI LecturaVRAMenCurso = 0 Y se detecta comienzo de lectura de VRAM por parte de la CPU
         Bus de direcciones de VRAM <= DirCPU
         LecturaVRAMenCurso <= 1
      ENOTROCASO, SI LecturaVRAMenCurso = 1
         Bus de datos de VRAM => LatchSalidaVRAM
         LecturaVRAMenCurso <= 0
      ENOTROCASO, SI EscrituraVRAMenCurso = 0 Y se detecta comienzo de escritura en VRAM por parte de la CPU
         Bus de direcciones de VRAM <= DirCPU
         WE_VRAM <= 0
         Bus de datos de VRAM <= Bus de datos de CPU
         EscrituraVRAMenCurso <= 1
      ENOTROCASO, SI EscrituraVRAMenCurso = 1
         WE_VRAM <= 1
      ENOTROCASO, SI ScanReservaVacio = 1 Y LecturaVideoEnCurso = 0
         Bus de direcciones de VRAM <= DirVRAM
         LecturaVideoEnCurso <= 1
      ENOTROCASO, SI LecturaVideoEnCurso = 1
         Bus de datos de VRAM => ScanReserva
         LecturaVideoEnCurso <= 0
         ScanReservaVacio <= 0
         DirVRAM <= DirVRAM + 1

      SI PixelAPintar = 7
         PixelAPintar <= 0
         ScanActual <= ScanReserva
         ScanReservaVacio <= 1
      ENOTROCASO
         PIXEL <= ScanActual[7]
         ScanActual <= ScanActual << 1
         PixelAPintar <= PixelAPintar + 1
FINHACER


La idea es que las operaciones de acceso a la memoria no duren toooodo lo que la CPU necesita que duren, sino que duren lo mínimo necesario (un ciclo de reloj de pixel). De esa forma, y dado que entre lectura y lectura de la CPU pasan como mínimo 3 ciclos de reloj, usando un doble buffer nunca te quedarás "exhausto" ya que en cuanto el buffer de reserva se queda vacío porque su contenido acaba de pasarse al buffer actual, tienes 8 ciclos de reloj (8 oportunidades) para llenar ese buffer. Un Z80 que pudiera (que no puede) hacer ráfagas de lecturas seguidas (3,3,3,3,3...) dejaría en cada ciclo de lectura 1 ciclo libre.

La idea es esa. Otra cosa es que este algoritmo que he escrito ahora tenga algún fallo o haya que tener en cuenta alguna cosita más. Todo es cogerlo, describirlo en Verilog dentro del ISE y pasarlo por el analizador lógico iSIM para ver si ahay alguna colisión o alguna condición de carrera que no se haya tenido en cuenta.

[Joss]

(Perdón que me meta en la discusión de vez en cuando, sobre todo si son preguntas muy básicas..... )

Lo que contais de buffer multiplexado es algo que también tiene el Amstrad CPC por ejemplo?:


Amstrad_CPC_464 by JossLucas, on Flickr