Abro el hilo con la idea de introducir a los curiosos del Amiga que quieren conocer las tripas del cacharro, pero les da vertigo eso de bitplanes, data fetching, color subcarrier, ciclos, scanlines.....
Para poder empezar con el Ensamblador, hay que conocer el Hard por narices.
Me gustaria que fuese algo sencillo, que cualquiera pueda entenderlo . Sobre todo a los que se estan inciando pero creen que "bajar al cobre" es una odisea.
A los que ya dominan el tema, quiero que comprendan que la cantidad de burradas que puedan aparecer son para intentar explicar conceptos, sobre todo al principio.
Una de las razones de este hilo es quitarle el miedo a la gente. De paso aprovechar los comentarios de los foreros para refrescarnos cosas, aprender, compartir, quitarnos el oxido...
Vamos a empezar y perdon por las posibles patadas al diccionario.
Introduccion (Nuestra querida tele de tubo)
¿Y que importancia tiene el monitor para tener que empezar por aqui?
Pues resulta que la orquesta que marca el ritmo de trabajo del Amiga es la señal del rayo.
Seguro que todos hemos visto como funciona un monitor/tv de tubo.
Un "cañon" dispara hacia la pantalla y generamos las lineas de imagen, cuando termina vuelve a subir y repetimos la operacion.
Todos esos movimientos tienen unos tiempos estandarizados (los famosos PAL, NTSC,etc).
Teniendo eso claro, podemos ver como se plasma la imagen en pantalla.
Ese marco negro (overscan) tiene una razon de ser.
La tecnologia de tubo tiene muchos años... con tantos fabricantes y con mejores/peores tecnologias, no existian bordes homogeneos y se dejaba una zona de "seguridad" para no perder imagen. Asi podias ver la imagen aunque el tubo fuera casi redondo.
Ya sabemos como funciona un monitor. Ahora tenemos que alimentar esa señal.....
Racing the beam
Para poder dibujar en pantalla, hay que decirle a los electrones en que momento deben cambiar de color para que (linea tras linea) nos muestre la imagen deseada. Hoy en dia las gpu lo hacen sin que nos enteremos,sin necesidad de lineas, todo digital directo al LCD.
En tiempos donde la tecnologia (y sobre todo la memoria) era carisima, lo mas basico podria ser algo asi. Una CPU, algo de memoria y lo necesario para convertir de digital a analogico.
Con lo que sabemos podemos deducir que la CPU se dedica a pintar una imagen durante la parte visible, pero durante el overscan (y lo que tarda en volver a subir el rayo de electrones ) tenemos tiempo para exigirle trabajo.
¿Que pasa si aumentamos el presupuesto/tecnologia y ponemos hard dedicado y mas memoria?
Ya tenemos otro escenario. El procesador de video nos genera la imagen pero no es gratis.
Tenemos que tener datos en rom (caracteres, tiles de un cartucho, etc....) o gastar tiempo en llenar su ram. Ademas de eso, el vdp pide una serie de comandos para saber que hacer con los tiles/caracteres, como los tiene que ordenar, que paleta le asignamos, cuantos planos necesitamos.....
Al final ganamos una barbaridad de tiempo respecto a lo anterior, pero seguimos sin solventar el problema principal.... la CPU tiene que estar "achuchando" al VDP.
Y ahora viene el Amiga y te hace esto.
En ese momento te vienen dos cosas a la cabeza. La memoria del sistema la tiene el chipset, por lo que la imagen se puede independizar en el sentido moderno de la palabra. Pero, si estamos en la CPU.... ¿como entro en la ram? ¿Ahora tengo que pedir permiso?
Vamos a tener que empezar a ponernos las botas porque nos metemos en el fango.
La tecnica de usar el overscan para hacer el trabajo y usar la zona visible para "pintar" es pan comido para nosotros ¿verdad?. Pero cuando miramos la imagen de un A500 (por ejemplo) enchufado a un LCD o usamos algun emulador, pasa algo raro....
Si la imagen no está centrada podemos deducir que algo mantiene ocupado al amiga durante ese tiempo y no le deja dibujar.
Aqui viene la madre del cordero....
Por ahora no nos interesan los datos, solo entender la idea.
El dibujo es una "linea temporal" de lo que hace el chipset mientras el rayo va cruzando la pantalla de izda a dcha. Los cuadrados numerados 1/3/5/2/4/6 (tanto negros como blancos) son el tiempo en el que estamos pintando la imagen, asi que practicamente todo lo que no es pintar (audio, sprites,etc....) se hace al principio. Por eso la imagen sale desplazada.
¿por que es importante saber esto? porque el chipset es el que domina la ram (de ahi la famosa CHIP-RAM amiguera).
Obviamente los diseñadores no eran tontos y crearon una memoria "directa" a la CPU (FAST-RAM), pero ahora no interesa poque el A500 pelado no lleva fastram.
La razon por la que empiezo por el acceso a memoria (data fetching) es que despues es mas facil explicar los scroll, los sprites, los modulos, etc....
Vamos a simplificar la cosa con esta idea.
Esto es un DMA casero que nos hemos inventado, dividimos el tiempo de trabajo en Slots.
A su vez lo hemos superpuesto a la imagen de pantalla para saber que ocurre a medida que el rayo pasa por el monitor.
En el 0 vemos que nos toca el audio, el chipset deja pasar un word (16bits) de la ram al audio.
En el 1 hay un hueco para la CPU, ahi podemos meternos en la ram.
En el 2, el chipset pasa otro word para pintar los sprites.
En el 3 tenemos otro hueco para trabajar
4. otro word para sprites....
5. otro hueco para nosotros.....
6. Aqui empieza el jaleo. Bitplane 1
La imagen del Amiga es planar. Eso quiere decir que cada pixel es un bit, un word son 16 pixels,facil. ¿Como le damos color a esos puntos? Pues poniendo otro punto "encima" a modo de capa. Mas colores, mas capas.
Si tenemos tres planos, podemos hacer 3 capas.
1 capa/bitplane (0 o 1) -> 2 colores
2 capas/bitplanes (0/0 0/1 1/0 1/1) -> 4 colores
3 capas bitplanes (0/0/0 0/1/0 1/0/0 1/1/0 0/0/1 0/1/1 1/0/1 1/1/1) -> 8 colores
Si queremos los 8 colores, tenemos que decirle al chipset que mande las tres capas, asi que son tres slots en los que no podemos hacer nada.
7. Bitplane 2
8 bitplane 3
Si nos fijamos, al haber cargado los primeros 16 pixels de los bitplanes, se empieza a generar la imagen en pantalla.
9 Aqui volvemos a tener otro hueco.
10 Ser repite el ciclo, bitplane 1
11 bitplane 2
12 bitplane3
.
.
.
No parece tan dificil el concepto ¿no? Dividimos el trabajo en words y le damos a cada componente un hueco para meter lo suyo.
Si encima nuestro DMA nos deja modificar su rutina (hasta cierto punto), podemos hacer cosas como la de abajo, sacrificar los sprites a cambio de mas pantalla. O al reves, reducirla para tener mas hueco de trabajo.
Con estos ejemplos podemos hacernos una idea basica de como funciona los DMAs. para saber cuando podemos trabajar y cuando tenemos que hacer el amiga trabaje por nosotros.
Todo esto ha sido muy por encima pero podemos empezar a mirar la primera imagen con un poco menos de miedo.
Podemos ojear los slots para trabajar el disco, el audio, los sprites, los bitplanes..... No sigue el orden de nuestro ejemplo pero se puede intrepretar mejor que al principio.
Tenemos que saber lo que esta haciendo el cacharro para saber que podemos (o no) hacer nosotros desde la CPU. De nada nos vale hacer una rutina chula si el rayo de electrones nos adelanta porque nos hemos quedado sin tiempo.
Si alguno empieza a entender el "ritmo" del OCS despues de esta explicacion, se preguntara ¿por que la CPU tiene los huecos impares? o ¿por que los bitplanes van en ese orden y no en otro? La respuesta es sencilla....
Por temas de señal de video y de como se maneja el color del monitor, el chipset trabaja a 3.5Mhz +- y por consiguiente, el 68000 va a 7 Mhz +- (el doble). ¿Con esto que conseguimos? Muy sencillo.....
El micro tarda 4 ciclos en mover un dato, al ir el doble de rapido, esos 4 ciclos duran los que 2 ciclos/slots del DMA. Asi que aun teniendo todos los slots para mi, siempre voy a perder uno porque no me da tiempo a mover los datos, el rayo pasa y no se puede desperdiciar el tiempo. Ese hueco (los pares) los intenta aprovechar el chipset para hacer sus cosas (sprites, disco, audio....)
Y a medida que le exiges al amiga, vas perdiendo slots y no te interesa estar con los brazos cruzados sin poder acceder a memoria hasta que vuelves al overscan o al momento en el que rayo vuelve a subir, que es donde tienes que hacer todo lo que puedas porque los bitplanes estan apagados.
Todo se basa en meter words aqui y alla.
Como todos los cacharros de la epoca, si quieres hacer algo solo tienes que leer/escribir una direccion y listo.
Hay 2 zonas clave. La del OCS ($DFFxxx) y las CIAs ($BFExxx,$BFDxxx)
Un ejemplo tipico seria: Quiero cambiar el color de fondo, pues word que te pego a X direccion ($DFF180 en este caso) y voilá.
Para organizar todo este batiburrillo hay una parte de Agnus especializada en automatizar muchas de estas llamadas y que es indispensable para darle esa famosa indepencia del chipset,el COPPER. Que vendra a ser como una especie de "POKEador" de words que es capaz de saber en que posicion esta el rayo del monitor, con todo lo que eso trae.
¿Que quieres cambiar de color en la linea X? Nada de poner interrupciones... el lo hace donde quiera (o casi). ¿Que quiero abrir o cerrar bitplanes/dmas/etc en una parte de la pantalla para poder sacar unos slots extras? Sin problema... ¿Se me han acabado los sprites que se habian cargado al inicio de la linea? Los creo sobre la marcha....
Ese será el Capitulo 1, por ahora terminamos la introduccion.
Lo suyo es tener el manual de hardware a mano (pdf,web,papel...) y empezar a conocer las capacidades partiendo de esta idea de words, lineas, slots, etc...
En principio esto esta pensado para usar el A500 que muchos tenemos en casa, en mi caso con una gotek por comodidad. ASMTwo de Scoopex va de lujo.
