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

[radastan]

Yo no dibujo, ni sé dibujar. De hecho te iba a pedir si tenías algún dibujo para probar el modo de 2bpp, pero como no sé si tendrías alguno a mano "ya", decidí usar algo que pudiera convertir por mi cuenta. Este que has puesto es muy chulo. Te lo cojo para las pruebas

Bonus track...

mcescher.png (10.54 KiB) Visto 8708 veces

Te digo yo que con este modo se pueden hacer cosas muy monas, mucho más sencillo que meter color y más fácilmente aprovechable.

[mcleod_ideafix]

Bonus track...

Oh! qué chulo! Como pantalla estática es muy bonita. Voy a usar de todas formas la del anime ya que tiene colores planos... Bueno, usaré las dos, porque los desplazamientos laterales a 2bpp se verán "mejor" con imágenes fotorealísticas, o al menos que tengan algo de grano, como ésta. Te aviso que la gestión de pantalla en este caso está siendo más ardua (cosa que me imaginaba) y los resultados, más leeeeeentos. Para empezar, he tenido que bajar el reloj de la CPU a 3.5MHz para quitarme parte de la contienda, y aún no me la he quitado del todo, así que he tenido que subir el reloj de la sección de video, para que este circuito tenga más oportunidades para "cazar" su siguiente byte de memoria antes de que la CPU vuelva a reclamarla.

Te digo yo que con este modo se pueden hacer cosas muy monas, mucho más sencillo que meter color y más fácilmente aprovechable.

Sí, pero a costa de enlentecer algunos procesos. El Z80 funciona muy bien con resoluciones de 1bpp y de 4bpp, porque para ambas tiene formas de trabajar (para 4bpp puedes usar muchas de las instrucciones de BCD para operar con píxeles individuales), pero para 2bpp lo único que puedes hacer es repetir dos veces lo que haces con 1bpp y eso es más lento sí o sí.

Para que te hagas una idea: este es el cuerpo del bucle que se repite 192 veces (una por cada scan de pantalla) para desplazarla 1 pixel a la derecha en el modo de 1bpp:

Código: Seleccionar todo

BucLinea                ld d,h
                        ld e,l
                        ld a,(hl)
                        rept 32
                             rr (hl)
                             inc hl
                        endm
                        rra
                        ld (de),a
                        djnz BucLinea


Como ves, es basicamente un bloque que se repite 32 veces (vamos, un bucle desenrrollado) y dentro del bucle lo que hay son dos instrucciones.

La misma rutina para 2bpp tiene que procesar no 32, sino 64 bytes por scan (el doble). Y esos 64 bytes han de desplazarse dos bits, no uno, así que no es el doble de trabajo, ¡es el cuádruple! Bueno, en realidad un poco más del cuádruple de tiempo, ya que dentro del bucle que da 64 vueltas (desenrrollado) hay más de dos instrucciones. Es así:

Código: Seleccionar todo

                        push hl
                        ld c,(hl)
                        rept 64
                             ld a,(hl)
                             rra
                             ld (de),a
                             inc hl
                             inc de
                        endm
                        ld a,c
                        rra
                        ld (Buffer),a
                        pop de
                        ld hl,Buffer
                        push de
                        ld c,(hl)
                        rept 64
                             ld a,(hl)
                             rra
                             ld (de),a
                             inc hl
                             inc de
                        endm
                        pop hl
                        ld a,c
                        rra
                        ld (hl),a
                        ex de,hl
                        dec b
                        jp nz,BucLinea


La complejidad extra (el uso de un buffer off-screen para rotar una línea de pantalla) es porque si hago la rotación directamente en la memoria de pantalla (como de hecho hago en el caso 1bpp), al ser esta rotación necesariamente de 1 bit cada vez, se verían artefactos extraños en la imagen en forma de píxeles con colores falseados, producto de haber desalineado los bits que componen un pixel. Leo de pantalla, voy rotando lo que leo, y lo guardo en el buffer. Luego leo el buffer, roto lo que voy leyendo, y guardo de nuevo en pantalla. De esa forma no hay píxeles equivocados.

Rotar este tipo de pantalla dos píxeles a izquierda o derecha sin embargo es más rápido que rotarla 1 pixel, ya que para rotar dos píxeles necesito rotar 4 bytes, y ahí ya puedo ayudarme del manejo BCD del Z80 (concretamente la instrucción RLD)

En resumen: que para pantallas estáticas queda muy chulo, pero no sé yo si permitirá mover gráficos con soltura. Este nuevo circuito de video de 2bpp es más "memory-starving": necesita acceder a memoria el doble de veces que el original de 1bpp. Si subiendo el reloj de video a 14MHz no consigo mejorar la cosa (UPDATE: sí, mejora la cosa), creo que tiraré por la otra forma de hacer que la memoria dé datos más rápidamente: usar dos memorias en paralelo (con lo que doblo la anchura del bus de datos y consigo leer no uno sino dos bytes en el mismo ciclo de reloj, y de posiciones diferentes). Esto implica que la disposición de la pantalla ya no puede ser chunky, sino por bitplanes. De hecho, el invento de los bitplanes se hizo precisamente para poner cada uno en una memoria física diferente y así conseguir que el circuito de video tenga a su disposición un ancho de banda de memoria mayor que el de la CPU.

[Toniman]

Que chulo este proyecto chicos, estoy entusiasmado con el, animo y a ver si dentro de unos meses puedo tener una unidad de este ordenador en casa.

[mcleod_ideafix]

Que chulo este proyecto chicos, estoy entusiasmado con el, animo y a ver si dentro de unos meses puedo tener una unidad de este ordenador en casa.

Según especificaciones, el teclado será por PS/2... ¿podrás soportarlo?

-- 10 Oct 2012, 01:25 --

Hala! Aquí tienes una muestra de como se comporta este nuevo modo de video a 2bpp.


El video muestra la imagen anime que pusiste, y la desplaza 256 píxeles a la derecha, luego 192 píxeles hacia abajo, 256 a la izquierda, y por último 192 hacia arriba.

Las rutinas, como ya comenté antes, tardan más en hacer estas operaciones. El doble de tiempo para los scrolls verticales (porque hay que copiar 12288 bytes en lugar de 6144), y más del cuádruple del tiempo para scrolls horizontales, ya que hay que procesar dos veces el doble de bytes.

Piensa también en otra cosa: este bitmap ahora me ha ocupado casi toda la ROM (el programa está entero en ROM, vuelca la pantalla a RAM y a partir de ahí comienza la animación). Cualquier juego que se haga para esta máquina usará el doble de memoria para los gráficos que uno hecho para Spectrum. Con 48K de RAM te podrías, en algunos juegos te podrías quedar corto de memoria. Quizas sea conveniente plantearse que la máquina tenga un modo all-RAM, en donde a voluntad del programa, la ROM se desconecte y sea reemplazada automaticamente por RAM, al estilo del Amstrad, C64, (¿MSX?) o el Spectrum +2A.

[radastan]

Como diría Jason, el de Viernes 13, vamos por partes:

- Has puesto un caso extremo: scroll pixel a pixel, y no es que lo veo precisamente lento. Dudo que alguien haga una conversión del Sonic.
- Si realizas un scroll de dos en dos pixels sigue siendo suave y encima usas desplazamiento de 4 bits.
- Teniendo en cuenta que una memoria de 128K de SRAM cuesta prácticamente lo mismo que una de 32K algo de paginación vamos a meter.

De todas formas este modo lo veo más para juegos sin scroll o para mostrar cosas en pantalla con un poco de "salero". Es que el modo monocromo de 1 bit no siempre se ajusta bien para aplicaciones. Ni planteo sobre la mesa un modo de 512x192 pixels de 1 bit monocromo porque eso ya plantea cambiar muchas cosas para incluir ese tercer modo.

Este puente voy a probar a implementar el modo 256x192x1 y ver cómo meter el modo de 2 bits sin muchas circuitería extra.

EDITADO:

Dando vueltas al modo all-ram lo suyo sería que se pudiesen cambiar las páginas de RAM 0 y 1 (van en páginas de 16K y del 0 al 3). En cualquiera de las dos se podría ver cualquier página de 16K de los 128K que hubiera, así se podrían usar las rutinas de la ROM para cargar las cosas en memoria (recuerdo la interfaz SD/CF que meteremos) o no perder acceso a la pequeña biblioteca de rutinas que pretendo meterle (scroll, sprites, etc).

Pero eso cuando toque, ahora estamos con la gráfica que es lo más delicado.

EDITADO 2:

Alaaaaaa, acabo de pedir el resto de componentes que seguramente me hagan falta (y seguro que me olvido de alguno). Como siempre pido de más para tener un poco de todo en el "taller" me han soplado 50 euros con los gastos de envío. No os asustéis que ya os digo que he pedido de más (más del doble de lo necesario y muchas cosas que lo mismo no sirven para este proyecto pero si para otros).

Es el precio de experimentar, que se le va a hacer, para la siguiente vez me paso a los PLD's que la lógica discreta se está volviendo algo carilla.

-- 10 Oct 2012, 07:47 --

Tenéis intención de que sea compatible con el software existente para algunos de los sistemas de 8 bits, ya sea spectrum o amstrad o el que sea?
Posiblemente acabe de decir una barbaridad...

No, no será compatible con ningún ordenador, otra cosa es que pueda emularse un ZX81 e incluso una Gameboy en cierta medida (el modo de tonos de gris lo permite). Lo que si se ha cambiado es la estructura de memoria para facilitar que alguien pueda dar soporte CP/M a esta máquina de forma nativa y aprovechar todo el software que hay en ese sistema.

Esto está pensado más como "terreno virgen" para el que se quiera animar a programar. El Z80 es de sobra conocido, la máquina va a estar perfectamente documentada, y en la misma ROM quiero dejar rutinas genéricas para el que quiera animarse a programar tenga bastante trabajo realizado (rutinas de sprites, scroll, teclado, etc).

Aún así lo sigo viendo como un proyecto personal compartido (entre todos me vais dando ideas y corrigiendo errores), si sólo yo lo acabo montando y programando ya me doy por satisfecho.

[Toniman]

El scroll va muy bien, se ve genial, animo y seguid asi.

[mcleod_ideafix]

Ni planteo sobre la mesa un modo de 512x192 pixels de 1 bit monocromo porque eso ya plantea cambiar muchas cosas para incluir ese tercer modo.

En términos de lógica.... no mucho No si partimos del modo de 256x192x2bpp ya que los timmings son exactamente los mismos y el sistema de usar dos registros de desplazamiento también. Lo único que necesitas para mostrar un modo de 512x192x1bpp en lugar de 256x192x2bpp es que ahora la salida de ambos registros de desplazamiento irían a un multiplexor cuya entrada de selección sería el reloj de 7MHz: cuando el reloj está bajo se seleccionaría la salida de uno de los registros. Cuando está alto, la del otro. Ya tienes 512 puntos horizontales

Este puente voy a probar a implementar el modo 256x192x1 y ver cómo meter el modo de 2 bits sin muchas circuitería extra.

Entiendo que sólo vas a construir el circuito de video, sin procesador ni nada, ¿no?

Dando vueltas al modo all-ram lo suyo sería que se pudiesen cambiar las páginas de RAM 0 y 1 (van en páginas de 16K y del 0 al 3). En cualquiera de las dos se podría ver cualquier página de 16K de los 128K...

¿Y qué harás con la pantalla? ¿Vas a hacer que la pantalla pueda seguir mostrándose incluso si su parte de memoria no está paginada? (caso del Spectrum) ¿o estará la pantalla asociada siempre a una dirección de memoria del espacio de direcciones de la CPU aún cuando el contenido de esas direcciones cambie al cambiar de página la CPU?

Es el precio de experimentar, que se le va a hacer, para la siguiente vez me paso a los PLD's que la lógica discreta se está volviendo algo carilla.

¡ Cuanta razón tiene mc-leod sobre el hardware reconfigurable ! Me parece que solo queda levantar el zócalo y "reconfigurar" a manubrio todos los pines... y sin JTAG!!

Yo no es por malmeter pero es que basta con que alguien quiera ponerse un poco en serio (más allá de conjeturar o hacer dos dibujos en un papel) a diseñar algo de electrónica digital con una cierta complejidad, para que sufra de primera mano lo que es pelear contra molinos de viento. Aunque hayas estudiado, medido, dibujado, simulado en papel, etc, en definitiva, planificar todo lo planificable, luego surgen problemas que no tienen nada que ver con que hayas hecho un mal diseño, sino que son de malas conexiones, este cable que se me sale, que si resulta que he contado mal los pines y lo estaba mirando del revés, etc. Cuando eso pasa y uno se obceca ("pero si esto está bien conectado... ¿por qué no funciona?") ya no sabe si es que su diseño está mal desde el principio, o si alguno de los chips está quemado... y pierdes más el tiempo en cercionarte de que todo está bien sujeto que en comprobar realmente si tu diseño es correcto. Durante mucho tiempo yo también pasé por eso. Como dicen por ahí arriba: "nunca mais".

McLeod evangelizando

[radastan]

Ni planteo sobre la mesa un modo de 512x192 pixels de 1 bit monocromo porque eso ya plantea cambiar muchas cosas para incluir ese tercer modo.

En términos de lógica.... no mucho No si partimos del modo de 256x192x2bpp ya que los timmings son exactamente los mismos y el sistema de usar dos registros de desplazamiento también. Lo único que necesitas para mostrar un modo de 512x192x1bpp en lugar de 256x192x2bpp es que ahora la salida de ambos registros de desplazamiento irían a un multiplexor cuya entrada de selección sería el reloj de 7MHz: cuando el reloj está bajo se seleccionaría la salida de uno de los registros. Cuando está alto, la del otro. Ya tienes 512 puntos horizontales

Me lo pensaré, ya que uno mete la mano da igual pringarse el codo.

Este puente voy a probar a implementar el modo 256x192x1 y ver cómo meter el modo de 2 bits sin muchas circuitería extra.

Entiendo que sólo vas a construir el circuito de video, sin procesador ni nada, ¿no?

Efectivamente, simularé la VRAM con una EPROM. Cuando tenga los modos de vídeo funcionando iré a por la parte de contienda, pero para eso ya si usaré un Z80 a la velocidad que sea (cogeré un divisor que me venga bien).

Dando vueltas al modo all-ram lo suyo sería que se pudiesen cambiar las páginas de RAM 0 y 1 (van en páginas de 16K y del 0 al 3). En cualquiera de las dos se podría ver cualquier página de 16K de los 128K...

¿Y qué harás con la pantalla? ¿Vas a hacer que la pantalla pueda seguir mostrándose incluso si su parte de memoria no está paginada? (caso del Spectrum) ¿o estará la pantalla asociada siempre a una dirección de memoria del espacio de direcciones de la CPU aún cuando el contenido de esas direcciones cambie al cambiar de página la CPU?

La VRAM no forma parte de los 128K de RAM de usuario que podríamos meterle, estaría aparte y siempre accesible en el último bloque de 16K del mapa de memoria. Lo que pretendo es poder cambiar las páginas de la ROM y los primeros 16K de la RAM de usuario por otra página cualquiera de los 128K.

Si la memoria de 128K fuese lo suficientemente rápida entonces podríamos usar un bloque de 16K para la VRAM, unificando toda la memoria RAM en un único chip. Para ese caso el sistema de vídeo tendría que poder acceder a la VRAM de forma independiente al Z80 (que además es lo aconsejable para el tema de la contienda).

[mcleod_ideafix]

Si la memoria de 128K fuese lo suficientemente rápida entonces podríamos usar un bloque de 16K para la VRAM, unificando toda la memoria RAM en un único chip. Para ese caso el sistema de vídeo tendría que poder acceder a la VRAM de forma independiente al Z80 (que además es lo aconsejable para el tema de la contienda).

Sí. El pequeño esquema de bloques que puse hace ya tiempo permite que el sistema de video (lo que va dentro de la CPLD en ese dibujo) acceda a la VRAM sin molestar a la CPU, si ésta está haciendo otra cosa. De todas formas, el mecanismo de no-contienda que tengo hecho, si funciona al 100% que es algo que tendría que probar, te asegurará que cuando la VRAM acceda a memoria, es porque la CPU no está usando la memoria de video para nada. Aun así, las resistencias que aislan los buses permitirán a la CPU hacer E/S a otros chips, aun cuando el ciclo de bus de E/S se solape con un ciclo de memoria del sistema de video.

Digo lo de probarlo al 100% porque hasta ahora mis pruebas se han reducido a escribir y leer de pantalla, con el programa ejecutándose en ROM. Si he escogido la prueba del scroll de pantalla es porque tiene lecturas y escrituras masivas en toda el área de pantalla y si hay colisión entre los dos dispositivos (video y CPU) lo vería rápidamente en forma de "ULA snow". Me falta probar a que el programa se ejecute además en la misma zona de memoria que la pantalla, para que así los ciclos de búsqueda de instrucción, que son los que requieren un acceso más rápido y continuado a la memoria.

Puedo hacer una prueba rápida, sin tener que cambiar las rutinas para que se ejecuten en RAM, si cambio el mecanismo de no-contienda para que incluya cualquier acceso a memoria, aunque esté fuera del rango de la VRAM. Lo pruebo y cruzo los dedos...

[radastan]

Puedo hacer una prueba rápida, sin tener que cambiar las rutinas para que se ejecuten en RAM, si cambio el mecanismo de no-contienda para que incluya cualquier acceso a memoria, aunque esté fuera del rango de la VRAM. Lo pruebo y cruzo los dedos...

Como funciones habrá que ver como hacerlo con lógica discreta, porque como se complique mucho me veo pasando del tema en este formato y uniéndome al bando "PLD". Jepalza me mata, pero es que tampoco puedo complicarme la vida en exceso.